-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguity interpreting keys and values from environment variables #501
Comments
Since I'd like to make progress on this, I'm gathering some links. Here are Datadog's guidelines on naming metrics and metric tags: https://docs.datadoghq.com/developers/guide/what-best-practices-are-recommended-for-naming-metrics-and-tags Metric names (which I'd argue are similar in function to Span names):
Metric labels:
And this is problematic. From Datadog's perspective, a metric label consists of both its key and value, so values are constrained not to contain certain characters. I am not advocating that we follow this path. Here are Prometheus' guidelines on naming metrics and tags: https://prometheus.io/docs/practices/naming/ Metric names:
Metric labels:
|
Discussion points in today's meeting: We don't want to impose an expensive sanitization step for metric names and label keys on all exporters. |
closing this as done because it is in the spec: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/sdk.md#specifying-resource-information-via-an-environment-variable |
From the specification SIG mtg today, a concern was raised interpreting keys and values:
Related issue in the golang SIG: open-telemetry/opentelemetry-go#332
Proposed solution from @jmacd : https://w3c.github.io/correlation-context/#value-format
The text was updated successfully, but these errors were encountered: