Add `device.crash` event semantic convention by bidetofevil · Pull Request #1576 · open-telemetry/semantic-conventions

bidetofevil · 2024-11-13T23:07:04Z

Adding the definition for an Event that models a crash in the mobile app. There are still some open questions to be worked out regarding naming and the specific event attribute definitions, but I want to put the draft changes in a PR to get further feedback from a larger group, having done so already via a doc with some other folks in the mobile community.

The PR is not ready to merging right now. I will make it a non-draft when it is.

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]
schema-next.yaml updated with changes to existing conventions.

… crash-semconv

LikeTheSalad

Thank you 🙌 I think it's a great start.

LikeTheSalad · 2024-11-14T05:37:27Z

+      The event body fields MUST be used to describe the state of the application at the time of the crash, not when the event was actually
+      emitted, which could happen at a much later time (e.g. when the app next starts up).
+    body:
+      id: device_crash_state


nit: is it needed to wrap all the body fields within this map? Since it seems like this map is the only field at the root level of the body, I was wondering if we could instead define all of its children as independent fields.

LikeTheSalad · 2024-11-14T05:43:40Z

+            Supplements the `source` field that identifies the specific variation of it [2].
+          note: >
+            This version is specifically for the `source` field. It can be a well-defined version of some external format (e.g. Android 15
+            Application Exit Info), or some custom version number associated with the usage in this event (e.g. some custom JSON schema).


Based on this note it seems like the source_version data might come from different places depending on the case. Maybe there's something I'm missing, though since we're defining source as an enum, I think it would be better (if possible) to define the source_version format for each type of source to avoid potential ambiguity issues.

LikeTheSalad · 2024-11-14T06:07:45Z

+          brief: >
+            The format of the `data` field as defined by [RFC 2046](https://datatracker.ietf.org/doc/html/rfc2046).
+          note: >
+            This, combined with a priori knowledge of the structure of the blob, will allow Collectors to parse and process the `data` field.


I'd like to check this with an example just to make sure I got it properly.

Considering an event with source = jvm_exception. Let's say that this data_content_type field has application/json as its value. The collector in this case will be able to parse it as json, however, how can it know what fields to look for in that json? My question is mostly about ensuring that the UI can later display this data properly.

The current formats for crash report bodies seem insufficiently defined, particularly for crashes originating from various sources or those captured by different tools. Leaving the data opaque while concentrating on defining the common metadata in the other attributes strikes the right balance IMHO.

In many instances, the crash report cannot be effectively presented without backend post-processing and supplementary data from the application provider, which falls outside the scope of OTel.

jzwc

Thank you for your initiative.

I apologize for not attending the SIG calls where this may have been discussed, but I am curious if there is a proposal to include an additional attribute that would help identify the crash report format beyond just the MIME type. Specifically, on iOS, there are several well-known libraries that generate crash reports in their own, somewhat distinct formats. For instance, knowing that a crash report was generated using PLCrashReporter could enhance interoperability. While this information could be incorporated into the MIME type, it would require parsing it out, which introduces another potential source of incompatibility.

Never mind, this is indeed covered by the source attribute.

jzwc · 2024-11-19T17:33:55Z

+              brief: >
+                Crash in the native layer caught by a signal handler
+            - id: aei
+              value: 'aei'


I’m curious if the full name (application_exit_info) might be a better approach?

jzwc · 2024-11-19T17:36:51Z

+          type: string
+        - id: crashed_service_version
+          stability: experimental
+          requirement_level: recommended


The note reads "This is required"...

jzwc · 2024-11-19T17:37:11Z

+          type: string
+        - id: crashed_os_version
+          stability: experimental
+          requirement_level: recommended


The note reads "This is required"...

jzwc · 2024-11-19T17:43:38Z

+            This, combined with a priori knowledge of the structure of the blob, will allow Collectors to parse and process the `data` field.
+          examples: [ "application/json" ]
+          type: string
+        - id: crashed_service_version


I understand the intention to emphasize, but the crashed_ prefix appears unnecessary in this context, as the attribute is clearly defined within device.crash, isn't it? Ditto crashed_os_version.

jzwc · 2024-11-19T17:52:57Z

+          brief: >
+            The format of the `data` field as defined by [RFC 2046](https://datatracker.ietf.org/doc/html/rfc2046).
+          note: >
+            This, combined with a priori knowledge of the structure of the blob, will allow Collectors to parse and process the `data` field.


The current formats for crash report bodies seem insufficiently defined, particularly for crashes originating from various sources or those captured by different tools. Leaving the data opaque while concentrating on defining the common metadata in the other attributes strikes the right balance IMHO.

In many instances, the crash report cannot be effectively presented without backend post-processing and supplementary data from the application provider, which falls outside the scope of OTel.

lmolkova · 2024-11-19T19:12:59Z

/cc @open-telemetry/semconv-mobile-approvers

tonzhan2 · 2024-11-19T23:06:56Z

+          stability: experimental
+          requirement_level: required
+          brief: >
+            An ID that uniquely identifies the crash instance obtained from a specific `source`.


How would this be generated? From say, an Android device crash?

tonzhan2 · 2024-11-19T23:15:20Z

This looks like a great start. I'm curious as to what some examples of crashes could look like in this format. Such as an Android jvm crash. Obviously most of it will be in the body, so I guess of that format is still tbd. Could be useful nonetheless to have some examples of crashes that use this formatting

jzwc · 2024-11-25T15:03:10Z

+            Application Exit Info), or some custom version number associated with the usage in this event (e.g. some custom JSON schema).
+          examples: [ "1.0.0" ]
+          type: string
+        - id: data


Shouldn't this better be in the body (earlier payload) of the Event (https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-body)? This would also implicate the type any rather than string.

jzwc · 2024-12-07T15:56:16Z

Just another quick thought. It would be generally beneficial is app state / resource attributes like device.app.lifecycle would be allowed as the crash event attributes to pass the respective application and device state at the moment of the crash.

thompson-tomo · 2025-07-03T10:25:50Z

+            This, combined with a priori knowledge of the structure of the blob, will allow Collectors to parse and process the `data` field.
+          examples: [ "application/json" ]
+          type: string
+        - id: crashed_service_version


Use attribute field instead and use the corresponding pre-existing semconv attribute.

thompson-tomo · 2025-07-03T10:27:05Z

+            This is required so crashes can be aggregated by the version in which it occurred, not the one that emitted the event.
+          examples: [ "7.5.0" ]
+          type: string
+        - id: crashed_os_version


Use attribute field instead and use the corresponding pre-existing semconv attribute.

KalleOlaviNiemitalo · 2025-07-29T15:43:29Z

+      recorded as it is happening (e.g. through an UncaughtExceptionHandler), or after the fact, when a tombstone is detected
+      containing information about a previously terminated app instance that was caused by an unhandled error or exception.
+    note: >
+      The body fields of this event contain data and metadata about the crash tht can be used to classify and aggregate it with similar


Should be "about the crash that can be used".

breedx-splk · 2025-08-13T17:47:06Z

@bidetofevil Do you want to circle back on this? It's kinda stale and needs a rebase at the least. I'd love to see this work out. Thanks!

bidetofevil · 2025-08-15T14:52:24Z

@breedx-splk Yeah, I'm looking to get back on this soon. I put it aside when I got busy and, well, it's finall time to look at this again. Starting with getting it building and reviewing the comments.

github-actions · 2025-11-29T04:25:07Z

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 14 days.

LikeTheSalad · 2026-02-16T16:30:50Z

Just for the sake of using semantic conventions in OTel Android instrumentations, I've created this PR to add the device.crash event with minimal requirements (open to future enhancements).

bidetofevil and others added 2 commits November 12, 2024 21:08

device.crash event YAML definition

4c675d8

Merge branch 'open-telemetry:main' into crash-semconv

177575c

bidetofevil requested review from a team as code owners November 13, 2024 23:07

bidetofevil marked this pull request as draft November 13, 2024 23:07

bidetofevil added 2 commits November 13, 2024 15:08

Add changelog file to PR

f7aaec3

Merge remote-tracking branch 'refs/remotes/origin/crash-semconv' into…

dcc0aba

… crash-semconv

LikeTheSalad reviewed Nov 14, 2024

View reviewed changes

jzwc reviewed Nov 19, 2024

View reviewed changes

tonzhan2 reviewed Nov 19, 2024

View reviewed changes

jzwc reviewed Nov 25, 2024

View reviewed changes

lmolkova moved this from Untriaged to Draft in Semantic Conventions Triage May 4, 2025

thompson-tomo reviewed Jul 29, 2025

View reviewed changes

KalleOlaviNiemitalo reviewed Jul 29, 2025

View reviewed changes

github-actions Bot added the Stale label Nov 29, 2025

github-actions Bot closed this Dec 7, 2025

Conversation

bidetofevil commented Nov 13, 2024

Merge requirement checklist

Uh oh!

LikeTheSalad left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzwc Nov 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzwc left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzwc Nov 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lmolkova commented Nov 19, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tonzhan2 commented Nov 19, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzwc commented Dec 7, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

breedx-splk commented Aug 13, 2025

Uh oh!

bidetofevil commented Aug 15, 2025

Uh oh!

github-actions Bot commented Nov 29, 2025

Uh oh!

LikeTheSalad commented Feb 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

jzwc Nov 19, 2024 •

edited

Loading

jzwc left a comment •

edited

Loading

jzwc Nov 19, 2024 •

edited

Loading