Issues: error tracking

Issues (/telemetry/issues, a tab of Telemetry) groups your app’s errors. Every exception recorded on a span (the exception event every OpenTelemetry SDK writes, including Shield360’s) and every log record at error or above becomes part of an issue within about a minute.

How errors are grouped

Errors with the same fingerprint are one issue. The fingerprint is the exception type, the normalized message and the top three stack frames:

• The message is normalized: numbers, UUIDs, hex ids, email addresses, URL query strings and quoted values become placeholders, so order 123 and order 456 group together. Only the normalized message is stored.
• Frames lose line and column numbers, so a deploy that moves code keeps its issues. JavaScript, Python, Java, .NET and Go stack traces are read.
• An error log with no exception type or stack groups by its normalized message and its logger name.

What an issue shows

The title (type and message), the service, the number of events, when it was first and last seen, the releases it appeared in (the service.version resource attribute), the top of the stack, and links to the last trace and its logs.

Triage

Status	Meaning
Open	Needs attention.
Resolved	Fixed. If the error happens again, the issue reopens and a regression alert is raised.
Ignored	Counted, but never alerts.

Changing an issue’s status needs the Manage alerts permission and is recorded in the audit log.

Alerts

Alert kind	When
issue.new	An error with a new fingerprint appears (at most 10 per data source a minute, so a bad release raises a handful)
issue.regression	A resolved issue is seen again

Route them with an event alert rule, or open incidents with an escalation policy.

Details

• Issues belong to a project’s data source (environment). Resolved and ignored issues not seen for 90 days are deleted.
• The scanner reads the newest minute or so of spans and logs each minute, at most the last 15 minutes when it falls behind. ISSUES_SCAN_SCHEDULE=off turns it off on a deployment.