You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding using a prefix for metric names the guidelines state:
The name is specific to your company and may be possibly used outside the company as well. To avoid clashes with names introduced by other companies (in a distributed system that uses applications from multiple vendors) it is recommended to prefix the new name by your company’s reverse domain name, e.g. com.acme.shopname.
here we might consider using a prefix like io.microprofile.fault_tolerance
While I can't find anywhere official that states that metric names must use snake case, that does appear to be the consistenly followed convention for metrics. Similarly, metric names in the semantic conventions never use upper case.
For each multi-word dot-delimited component of the attribute name separate the words by underscores (i.e. use snake_case). For example http.response.status_code denotes the status code in the http namespace.
While i'm pointing out some places where metric names and attributes from MP Fault Tolerance have not followed the guidance / semconv, I think it would be a mistake to replace the metric names/attribues (even in a future release) now that they have been released. Breaking backward compatibility is a much bigger problem than not following style guidelines since changing metric names/attributes across releases means users can't manage servers running with different releases using the same dashboards/alerts. The chance of name collisions for metric names is fairly small.
What I propose we do for future metrics/attributes:
use a prefix for metric names and attributes. I suggest io.microprofile. The one exception I would suggest is that we continue using ft. for any new fault tolerance metric names to be consistent.
use lower case / snake case for all metric names / attributes (as described in more detail in the OTel docs)
The text was updated successfully, but these errors were encountered:
We discussed at today's MP Telemetry call and suggested to add the new metric names and deprecate the old metric names. The metric names and attributes should start with io.microprofile.ft.*. The implementations can support both. @donbourne will talk with OTel to see whether they are interested in standardising the metrics names and attributes. If they do, we will wait for OTel to standardise the names/attributes.
The metric and attribute names used in MP Fault Tolerance 4.1 for OpenTelemetry metrics do not follow the OpenTelemetry guidelines for metric names.
Guidance for metric naming is described at https://opentelemetry.io/docs/specs/semconv/general/metrics/#general-guidelines
Regarding using a prefix for metric names the guidelines state:
here we might consider using a prefix like
io.microprofile.fault_tolerance
While I can't find anywhere official that states that metric names must use snake case, that does appear to be the consistenly followed convention for metrics. Similarly, metric names in the semantic conventions never use upper case.
Attribute naming guidelines are at https://opentelemetry.io/docs/specs/semconv/general/attribute-naming/
Where possible, we should use pre-existing attribute names that are marked "stable" from the attribute registry (https://opentelemetry.io/docs/specs/semconv/attributes-registry/)
For example, we could use
code.function
instead ofmethod
per https://opentelemetry.io/docs/specs/semconv/attributes-registry/code/While i'm pointing out some places where metric names and attributes from MP Fault Tolerance have not followed the guidance / semconv, I think it would be a mistake to replace the metric names/attribues (even in a future release) now that they have been released. Breaking backward compatibility is a much bigger problem than not following style guidelines since changing metric names/attributes across releases means users can't manage servers running with different releases using the same dashboards/alerts. The chance of name collisions for metric names is fairly small.
What I propose we do for future metrics/attributes:
io.microprofile
. The one exception I would suggest is that we continue usingft.
for any new fault tolerance metric names to be consistent.The text was updated successfully, but these errors were encountered: