Exception grouping

[LikeTheSalad]

Changes

Adding exception.group_id attribute for grouping structurally equivalent exceptions.

Motivation

In error tracking and observability, it is common for the same root-cause exception to produce slightly different messages (e.g., containing a variable). Without a grouping mechanism, each unique message creates a separate entry, making it difficult to assess the true frequency and impact of an issue. exception.group_id solves this by providing an identifier derived from the structural parts of the exception (type + stacktrace frames), ignoring high-cardinality fields like the message.

Examples

The following two Java exceptions differ only in their message but share the same type and stacktrace structure. They would produce the same exception.group_id:

Exception 1:

  java.io.FileNotFoundException: /data/reports/user_42/output.csv (No such file or directory)
      at java.io.FileInputStream.open0(Native Method)
      at java.io.FileInputStream.open(FileInputStream.java:195)
      at java.io.FileInputStream.<init>(FileInputStream.java:138)
      at com.example.ReportService.loadReport(ReportService.java:87)
      at com.example.ReportController.getReport(ReportController.java:34)

Exception 2:

  java.io.FileNotFoundException: /data/reports/user_1337/output.csv (No such file or directory)
      at java.io.FileInputStream.open0(Native Method)
      at java.io.FileInputStream.open(FileInputStream.java:195)
      at java.io.FileInputStream.<init>(FileInputStream.java:138)
      at com.example.ReportService.loadReport(ReportService.java:87)
      at com.example.ReportController.getReport(ReportController.java:34)

Both exceptions have the same exception.type (java.io.FileNotFoundException) and the same stacktrace structure (identical class names and method names, in the same order). The only difference is the file path in the message. An instrumentation computing exception.group_id from the type and frame structure would assign the same value (e.g., "518d34582b6189db69b36414336c47ec6e4144f8") to both, enabling them to be grouped as the same issue.

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[github-actions]

This PR contains changes to area(s) that do not have an active SIG/project and will be auto-closed:

• exceptions

Such changes may be rejected or put on hold until a new SIG/project is established.

Please refer to the Semantic Convention Areas
document to see the current active SIGs and also to learn how to kick start a new one.

[LikeTheSalad]

This PR contains changes to area(s) that do not have an active SIG/project and will be auto-closed:

• exceptions

Such changes may be rejected or put on hold until a new SIG/project is established.

Please refer to the Semantic Convention Areas document to see the current active SIGs and also to learn how to kick start a new one.

I don't understand why it is automatically closed. Isn't the exception component owned by @open-telemetry/semconv-log-approvers ?

[github-actions]

This PR contains changes to area(s) that do not have an active SIG/project and will be auto-closed:

• exceptions

Such changes may be rejected or put on hold until a new SIG/project is established.

Please refer to the Semantic Convention Areas
document to see the current active SIGs and also to learn how to kick start a new one.

[LikeTheSalad]

I'll follow the same steps done on this previous PR to avoid this PR from getting closed automatically because I think it might be a mistake from the CI tools, unless confirmed otherwise by @open-telemetry/semconv-log-approvers

[trask]

are you thinking of hashing the stack trace? hashing only a certain number of frames? or something else?

[LikeTheSalad]

For Java stacktraces, I'm planning to remove the messages and line numbers first, then hash everything else.

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.