Add mobile crash data model spec

[tonzhan2]

Tentative draft for mobile crashes reflected as standalone event logs. Not sure if added in the right place, and a little unfamiliar with formatting so any input is appreciated

[AlexanderWert]

cc @open-telemetry/semconv-mobile-approvers

[tonzhan2]

@tonzhan2 I added a bunch of review comments / proposals on how to refactor the yaml file to be consistent with other semantic conventions.

Apart from that, there are two major things left:

1. Can you add a readme file (in semantic-conventions/docs/mobile) that would describe the semantic conventions and generate the attributes table in there (see other markdown files for reference).

   • you'll need the <!-- semconv [SEMCONV_ID_GOES_HERE]--> ... <!-- endsemconv --> comments
   • and then run make table-generation

2. Currently the payload for Android crashes is in exception.* and thread.* attributes, while for iOS it's a single field where the crash content goes in. It might be fine as the data is conceptually different for those systems, but I'd like to here more opinions from @open-telemetry/semconv-mobile-approvers

Will do.
I would defer any questions about the iOS crash payload in the single field, as well as details pertaining to the iOS formatting to my colleague @SMickelsn

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[joaopgrassi]

CC @marandaneto

[marandaneto]

Would be possible to make the reporter agnostic?
In case I use KSCrash, I'd like to use the very same data model.
Maybe introducing a new property that tells what's the reporter format, such as KSCrash, PLCrashReporter or anything else.

[marandaneto]

Maybe we should just call it state and allow the OS name to be set such as ios or android, at least is flexible enough in case a new OS appears rather than introducing attributes for every OS.

[marandaneto]

ios is specifically for iPhone, macOS is for MacBook and friends.
Maybe we call it apple instead? since the crash reports share the same format on all Apple platforms.

[marandaneto]

event.name should allow something different than crash - or make it more generic.
crash means the application exited, but this format should allow swallowed errors - but captured as well which is technically not a crash but rather an error/exception.

[scheler]

The current thinking is that we will model a separate event type for non-fatal errors/exceptions. There is already an event type called exception in the spec but that's more for span events, that is, errors occuring in the context of a span, but we will need to model a similar event for a more generic usecase.

[marandaneto]

any reason to make that a different event type? the only difference between a crash and an error is its severity, the metadata is 100% the same.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.