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
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.
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: