Permit non-alphabetic characters as the 1st character in metric names

[heyams]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-name-syntax

We are looking to start using a dotnet OpenTelemetry distribution. Unfortunately, our metric names begin with a '-' character, which is not allowed as the first character.

Changing the metric names is not a feasible option for us due to the high cost and the potential invalidation of numerous queries accumulated across various tools, dashboards, and users. Therefore, we hope that a feature request could be considered to allow non-alphabetic characters as the first character of metric names. This would enable us to fully utilize the features and benefits provided by OpenTelemetry metrics.

Thanks,
Helen

[regexrowboat]

👍

[svrnm]

hey thanks for your proposal, this needs a broader discussion, I recommend that you attend the SIG meeting to get some feedback: https://github.com/open-telemetry/community/?tab=readme-ov-file#specification-sigs

[cijothomas]

Previous relevant Issue/PR that removed some restriction on metric name : #3422

This keeps coming up. "/" is now allowed, but there are asks to support longer-than-63 length, ":", " " (space), "\" (back slash) And this issue which is asking to relax 1st character restriction.

Will join the next Spec SIG meeting to discuss how to unblock users.

[cijothomas]

Spec meeting (Jan 28) notes:

1. How would this affect Prometheus? Need to see if this is possible to be escaped in the prometheus mapping.
2. We could add escaping rules to the spec to allow spl. chars. There is a concern about how would existing backends know if the name is escaped or not? Potentially leverage an attribute (name.escaped=true/similar) , scope attribute or metadata.
3. Alternate maybe to use OTel compliant name and store the legacy name elsewhere (like in scope/metadata/attributes), and have the backend use the name from the "elsewhere" - TDB where that is.
4. Explore if we can make this work with existing Prometheus (https://github.com/open-telemetry/opentelemetry-specification/blob/3b037be082915f29766a87c01141c72fb0fb5f1b/specification/compatibility/prometheus_and_openmetrics.md#metric-metadata-1) mapping.

@dashpole can help with questions related to Prometheus compatibility.

[dashpole]

How would this affect Prometheus? Need to see if this is possible to be escaped in the prometheus mapping.

Prometheus' standard restrictions prevent metric names from starting with a number, and the character restrictions only otherwise allow letters and underscores. With prometheus' UTF-8 support that is rolling out, any valid UTF-8 names can be used. It does mean a different query syntax is needed (but this is needed for most names anyways):

• standard: my_metric_foo{}
• With UTF-8 support:{"%my_metric_foo"}

We don't currently have an escaping strategy specified for metric names, but for labels names, we prepend key_ to the label name if it starts with an invalid characters. We could do something similar for metric names, but it seems better to just direct users to enable UTF-8 for metric names that aren't allowed today.

We could add escaping rules to the spec to allow spl. chars. There is a concern about how would existing backends know if the name is escaped or not? Potentially leverage an attribute (name.escaped=true/similar) , scope attribute or metadata.

Based on prometheus' experience with escaping mechanisms, I would oppose doing any escaping by default in the SDK. It has led to a significant amount of user confusion, and is taking a long time to undo. IMO, it is better for exporters that can't accept the name fail and to direct users to "fix" metric naming issues using views than to automatically rename metrics.

Alternate maybe to use OTel compliant name and store the legacy name elsewhere (like in scope/metadata/attributes), and have the backend use the name from the "elsewhere" - TDB where that is.

The right place seems to be metric.metadata: https://github.com/open-telemetry/opentelemetry-proto/blob/ffade295895a2be5a6e7931eb0cda1c72bc4c0f6/opentelemetry/proto/metrics/v1/metrics.proto#L218. However, I don't believe this can be set from any SDKs today, so that would require additional spec changes.