-
Notifications
You must be signed in to change notification settings - Fork 752
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
Meter name not in Prometheus scraper output? #4424
Comments
As far as I know the meter name should be set as Reference to the OTel specification: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#instrumentation-scope |
My situation is neither OTel converted to Prometheus or Prometheus converted to OTel. These are custom meters and counters created using System.Diagnostics.Metrics. |
Are you not exporting the metrics using an Prometheus exporter (e.g. like this one)? I added wrong hyperlink. It should be https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#instrumentation-scope-1 (same header just further in docs). |
Yes, I'm using the Prometheus scraping endpoint in that package. This is the output when I visit
|
I think it is a bug per https://github.com/open-telemetry/opentelemetry-specification/blob/773ee656f92c7f591f2fd9c38df82c264a15184d/specification/compatibility/prometheus_and_openmetrics.md?plain=1#L260-L262:
|
This part of the spec is relatively new to the spec itself, and is not yet implemented. I'd mark this as enhancement to Prometheus exporter, not a bug. |
I don't think prometheus-net and OTel Prometheus exporters will produce exact same output. OTel Exporters follow the OTel mapping (from OTLP -> OpenMetrics/Prometheus), and MeterName's are not prefixed to form the metric name in that spec. |
I think part of the problem here is that OTEL thinks it's the only game in town, and assumes that everything exposed via it will follow its patterns. This is potentially a problem with scenarios like .NET where we are mapping existing technologies into OTEL. Can there be an option (probably defaulting to on) to include the metric as part of the meter name in OTEL. Its only in cases like the OTEL instrumentation libraries where they are mapping to names in the OTEL spec that not including the prefix makes sense. |
See the OTel -> Prometheus mapping spec. We'd need to be adhering to that. If that mapping is not sufficient, we should raise an issue in the spec, as this is not just a .NET only issue, any other languages using prometheus clients are affected. |
Can we revisit this issue? I noticed that both the OTEL exporter and the Prometheus exporter don't add Edit: Just noticed this issue, is this the same thing? #4563 |
There is an issue for adding I'll close this issue as the question has been answered. |
I'm testing out System.Diaganostics.Metrics with prometheus-net and opentelemetry-dotnet.
There is a difference in the metrics names in the Prometheus scraping endpoint:
microsoft_aspnetcore_servers_kestrel_current_connections{endpoint="[::1]:7269"} 1
current_connections{endpoint="[::1]:7269"} 1
It seems wrong that these are inconsistent. Grafana dashboards expecting names that include the meter name will fail if it's missing, or vice versa.
The prometheus-net approach is more verbose, but it won't fail if counters with the same name are created by different meters? For example, ASP.NET Core is going to have
current_connections
in two meters:Microsoft.AspNetCore.Servers.Kestrel
andMicrosoft.AspNetCore.Http.Connections
.The text was updated successfully, but these errors were encountered: