Skip to content
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

Closed
timwoj opened this issue Sep 11, 2023 · 6 comments
Closed

Instruments with same name but different attributes are lost #2305

timwoj opened this issue Sep 11, 2023 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@timwoj
Copy link
Contributor

timwoj commented Sep 11, 2023

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:

active_sessions{endpoint="",protocol="tcp"} 2 1694045963754
active_sessions{endpoint="",protocol="udp"} 1 1694045963754

While porting the code over to opentelemetry-cpp, only the udp protocol entry appears in the output from the metrics endpoint.

@timwoj timwoj added the bug Something isn't working label Sep 11, 2023
@github-actions github-actions bot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Sep 11, 2023
@lalitb
Copy link
Member

lalitb commented Sep 11, 2023

What is the expected behavior?
Both instruments appear in the output from the exporter, named the same but with different attributes.

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?

@lalitb lalitb self-assigned this Sep 11, 2023
@marcalff
Copy link
Member

@marcalff
Copy link
Member

In my understanding, in this case the instrumentation should:

  • create a unique instrument with a name, here active_sessions
  • report two distinct measurements from this instrument, with different attributes:
    • active_sessions{endpoint="",protocol="tcp"} 2 1694045963754
    • active_sessions{endpoint="",protocol="udp"} 1 1694045963754

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.

@lalitb
Copy link
Member

lalitb commented Sep 19, 2023

@timwoj - Do you have further questions on this ?

@marcalff
Copy link
Member

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.

@marcalff marcalff removed the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Sep 20, 2023
@timwoj
Copy link
Contributor Author

timwoj commented Sep 20, 2023

Agreed with the closure. That description got me sorted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants