Add Linux distro meta-data to OS context.

[supervacuus]

Discussed in #942

^{Originally posted by tkatsoulas February 1, 2024}
Hello guys,

The current implementation to understand the host OS https://github.com/getsentry/sentry-native/blob/master/src/sentry_os.c provides poor information for any distro. Are there any plans to update them? For instance /etc/os-releases file is there for most* of the Linux distros and can provide detailed information about a host. The current mechanisms can be used as a fallback.

Thanks in advance,
Tasos.

CC: @kahest would be interesting if other SDKs already have a tag reserved for this information.

[kahest]

related: #467 (comment)

[supervacuus]

Hi @tkatsoulas, can I ask you: would you want to use this for searching and filtering issues (requiring us to index the field in the backend and consider cardinality), or would it suffice as an additional data item that you look up per event? Thx!

[tkatsoulas]

I think both. Your current pipelines will work if we just transform the current os and os.name to something more useful rather than

If more information about a distro (like OS: Linux OS.name: Fedora OS.version:38 and the kernel-name: ... seperately) can be indexed it will be much appreciated.

This can give you a concrete view of what distros are affected by the same/similar issue.

Didn't had the time to work on the open-source contribution but I think I can have a draft PR by Monday.

[supervacuus]

Hi @tkatsoulas, thanks. I expected that you want to be able to filter it; I just wanted to make sure.

Changing the meaning of existing os-context properties is not a good idea: it would immediately split existing events from future events, which currently would appear in the same filter results.

Some customers want to differentiate between broad OS categories (Win, macOS, Linux, etc.), and os.name is the right os-context key for this; changing its meaning would invalidate existing dashboards.

A new key (+ sub-keys?) for Linux distributions would be better, and we will talk about this internally with the ingest team about the right path.

Please wait with any time investment on your part until this is clarified since this isn't solely a client SDK issue.