-
Notifications
You must be signed in to change notification settings - Fork 440
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
Instruments with same name but different attributes are lost #2305
Comments
Need to check this further, but don't think this should be expected behavior. Rather than allowing the creation of multiple instruments with the same name, the SDK should ideally return a reference to the instrument that has already been created. Given that the existing API returns a unique_ptr to the instrument, this may not be feasible. An alternative approach could be to return a no-op instrument while also logging a warning for trying to create duplicate instrument. I may not have understood your use case, but can't you use the same instrument to record these values? |
In my understanding, in this case the instrumentation should:
Creating two instruments with the same name is an error (see #2099). It is not handled correctly right now so only the last instrument is used, but the application should nevertheless not create duplicate instruments. |
@timwoj - Do you have further questions on this ? |
Closing. As indicated, the proper way to instrument is to have only one metric, and report multiple measurements with different attributes using the unique metric. |
Agreed with the closure. That description got me sorted. |
Describe your environment This happens on both macOS and ubuntu 22.04. I'm building against opentelemetry-cpp v1.11.0.
Steps to reproduce
Create two instruments the same name, but with different attributes stored in a KeyValueIterableView.
What is the expected behavior?
Both instruments appear in the output from the exporter, named the same but with different attributes.
What is the actual behavior?
Only the last instrument created shows in the output. I tested this with both the Prometheus and ostream exporters.
What did you see instead?
Additional context
I noticed this originally with the Prometheus exporter, because this is definitely a supported feature there. We have an existing metrics implementation that outputs something like this to Prometheus:
While porting the code over to opentelemetry-cpp, only the
udp
protocol entry appears in the output from the metrics endpoint.The text was updated successfully, but these errors were encountered: