-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
MetricEventSource value published events don't unambiguously resolve which Meter and Instrument tags they are refering to #93767
Comments
I dropped a comment over here: #102678 (comment) Just wondering if we could have events on the sources (metrics and tracing) for Meter\ActivitySource published. What I would like to do is be able to listen to those, capture all the static data into a dictionary, and then when individual measurements happen or activities start/stop I could look up the data. That way we don't need to mirror everything for all the individual events. Key could be a hash or just some id/count that is auto-assigned to Meter/ActivitySource and present on the events 🤷 |
Similar to #93097, ambiguity also occurs for meter scoped tags and instrument scoped tags. .NET allows creating new Meter and Instrument objects that differ from existing Meters/Instruments only by their tags. This isn't recommended usage and within the domain of OTel SDK specification it is an error for Meters to differ by tags only. However given that .NET API doesn't block it then we should be consistent and have MetricsEventSource should report it unambiguously. The simplest way to eliminate the ambiguity would be for value published events to include meter tags, instrument tags, and scope hash (#93097) in addition to the information that is currently reported.
Repro
Expected behavior
MetricsEventSource value publishing events can associate each reported value 1,2,3,4 with the correct Meter and Instrument tags
Actual behavior
MetricsEventSource value publishing events will report each value publishing event only including the names which will be the same each time, leaving it ambiguous which tags go with which measurement.
The text was updated successfully, but these errors were encountered: