metric names - best practice

[antje-s]

In the last days I have learned something on best practice for metric names:

• general structure like lib_name_unit_suffix
• for unit: basic units like seconds/bytes
• suffix: to define the metric type, e.g. total, sum, time

For WMO metrics I would suppose to add unit, but only if not clear, and a suffix for example for gc metrics: wmo_wis2_gc_gb_connected --> wmo_wis2_gc_gb_connected_flag wmo_wis2_gc_gb_lastmessage --> wmo_wis2_gc_gb_lastmessage_seconds_timestamp wmo_wis2_gc_downloaded --> wmo_wis2_gc_downloaded_total wmo_wis2_gc_downloaded_errors --> wmo_wis2_gc_downloaded_errors_total wmo_wis2_gc_dataserver_status --> wmo_wis2_gc_dataserver_status_flag wmo_wis2_gc_dataserver_last_download --> wmo_wis2_gc_dataserver_last_download_seconds_timestamp

What is your opinion: Is such an extension useful or does it just increase the length of the metric names?

[golfvert]

Normally, each metrics must have a description. So, putting part of the description in the name of the metric itself looks redundant to me. What is the reference of "best practice" ?

[antje-s]

It was an external training, so I searched for an online source and found e.g. https://prometheus.io/docs/practices/naming/ https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#unit https://opentelemetry.io/docs/specs/otel/metrics/semantic_conventions/

[golfvert]

Interesting! Considering that we have decided to follow good practices as much as we can, I think we can rename the metrics with this logic.

[golfvert]

Do you want to update the current metrics en the CSV files to comply with those best practices ? I will then change the ones produced by the GB.

[kaiwirt]

csv updated

[golfvert]

Question on the "flag". In our case, it is to show if their is a connection to the remote broker. So, a kind of true/false. True/False doesn't exist in metrics. So, shall we say that false = 0 and true != 0 (let's go for 1 !) ??

[antje-s]

As we currently use 0 and 1, I am happy to agree. In general, I would be in favor of describing under Description in our csv tables what 0 and 1 stand for in each case (not just True/False), but specifically for each metric - for an example see wmo_wis2_gc_dataserver_status_flag in gc.csv

[6a6d74]

All agreed. Closing this issue.