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

Add 'severityLevel' dimension to built-in ExceptionMetrics #2787

Open
tesueret-msft opened this issue Jun 7, 2023 · 3 comments
Open

Add 'severityLevel' dimension to built-in ExceptionMetrics #2787

tesueret-msft opened this issue Jun 7, 2023 · 3 comments

Comments

@tesueret-msft
Copy link

Is your feature request related to a problem? Kind-of :)

Some of my team's services have recently triggered Exception-based alarms from, what turned out to be, not-actually-important exceptions. We've found that some external code is emitting exception telemetry with non-Error severityLevels (Warning, or even Info).

This makes Exception alerting noisier than we'd like, as these non-Error "exceptions" don't actually require operator action.

However, our Azure Alert Rules cannot simply filter the Exceptions metric by severityLevel because ... the severityLevel dimension isn't included in that metric.

https://github.com/microsoft/ApplicationInsights-dotnet/blob/main/BASE/src/Microsoft.ApplicationInsights/Metrics/Implementation/AutocollectedMetricsExtraction/ExceptionMetricsExtractor.cs

(As of writing, the metric includes only CloudRoleName and CloudRoleInstance dimensions.)

Describe the solution you'd like.

A built-in metric dimension for severityLevel would make it easy for our Alert Rules to ignore "informational exceptions" if and when they occur.

Trace metrics include this dimension already: https://github.com/microsoft/ApplicationInsights-dotnet/blob/main/BASE/src/Microsoft.ApplicationInsights/Metrics/Implementation/AutocollectedMetricsExtraction/TraceExtractor/TraceSeverityLevelDimensionExtractor.cs

Describe alternatives you've considered.

Unfortunately as this "informational exception" code is running totally outside our own process, our only alternative for "fixing" the emitted metric (either customizing the event, or suppressing low-severity events outright) is by following up with other product teams.

Meanwhile our operators will just recognize that some service exceptions are, uh, less exceptional than others. :)

Additional context. n/a

@cijothomas
Copy link
Contributor

This requires changes in the backend/product itself, not just the SDK. The dimensions are pre-defined in Azure Monitor for these "standard metrics": https://learn.microsoft.com/en-us/azure/azure-monitor/app/standard-metrics#exceptions-exceptionscount, so sending any dimension (like severity) not defined here already will be simply ignored by backend.

@cijothomas
Copy link
Contributor

Would be good to use this forum to share this feedback/feature request: https://feedback.azure.com/d365community/forum/3887dc70-2025-ec11-b6e6-000d3a4f09d0

@tesueret-msft
Copy link
Author

@cijothomas Thank you for the pointer down this rabbit-hole. :D

Azure Monitor suggestion: https://feedback.azure.com/d365community/idea/21971a8b-6905-ee11-a81c-6045bdbc2a74

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants