You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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: