Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[telemetry] emit metrics with _ instead of / #9775
[telemetry] emit metrics with _ instead of / #9775
Changes from 2 commits
f0e6c50
3a2c08f
2530f58
3ef2752
393538b
483643f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the SIG call, I suggested using
_
instead of.
until we stabilize the metrics. The reason is that AFAIK Prometheus is working on supporting dots. So once it's ready, it'll be another breaking change for all the users using Prometheus to scrape the internal metrics. Suddenly all the metrics will be converted fromotelcol_receiver_accepted_metric_points
tootelcol.receiver.accepted.metric_points
. If we adopt_
for now, I believe we can avoid that.I understand that
_
is not semantically correct from OTel's perspective, but we will have to make a big migration later anyway, so it might make sense to reduce the amount of breaking changes.I'm happy to hear other opinions. And I'm not sure about the timeline for dots support in Prometheus. Maybe it's much further away than new stable Collector metrics.
cc @open-telemetry/collector-approvers @open-telemetry/collector-contrib-approvers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise, once the dots are supported in Prometheus, we might need a config option to convert
.
->_
somewhere to preserve the behavior and avoid breaking the users. It can be even a Prometheus receiver config option. In that case, we should be good.@dashpole, maybe you have some ideas about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that use of dots vs underscores will be negotiated using headers, so users will be able to control it server-side: https://github.com/prometheus/proposals/blob/main/proposals/2023-08-21-utf8.md#query-time. If it is enabled by default at some point in the future, it might still be a surprise for users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmitryax the reason i went with
.
instead of_
is that other metrics (for example the grpc instrumentation) uses.
already when emitting OTLP. Having both separators, depending on the source of the metric, seemed confusing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification. Looks like, even if it is enabled by default, it won't happen any time soon. I assume the controlling headers will be exposed as a configuration in the Go OTel exporter as well as somewhere in service::telemetry::metrics` section of the collector config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
Check warning on line 31 in processor/processorhelper/obsreport.go
Codecov / codecov/patch
processor/processorhelper/obsreport.go#L31