-
Notifications
You must be signed in to change notification settings - Fork 257
Open
Description
I would like to add three new resource-level semantic conventions to the os.*
namespace that include information about the kernel used by the system. Roughly, they could be defined as follows:
Attribute | Type | Description | Examples | Requirement Level |
---|---|---|---|---|
os.kernel.name |
string | The kernel name, e.g. on a Unix system, the output of uname -s . |
Linux |
Recommended |
os.kernel.release |
string | The kernel release, e.g. on a Unix system, the output of uname -r |
5.19.0-42-generic |
Recommended |
os.kernel.version |
string | The kernel version, e.g. on a Unix system, the output of uname -v |
#43~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 21 16:51:08 UTC 2 |
Recommended |
These would be useful to identify a resource as coming from a machine with a specific kernel version, which can be useful in debugging and troubleshooting systems.
It's been a while since I have contributed to semantic conventions so I have a few open questions, please bear with me :)
Open questions
- Elastic Common Schema already defines
os.kernel
as "Operating system kernel version as a raw string." and gives4.4.0-112-generic
as an example value (so, effectively what I called hereos.kernel.release
). I think we should use the more specificos.kernel.release
for this instead, sinceos.kernel
seems more like a namespace to me, and there's several meanings for 'version'. Is that okay? - Should
os.kernel.name
have a pre-defined set of values? If so, what values are in scope? - Are the values as described sufficiently cross-platform? At a minimum, do they have a reasonable equivalent on Windows and macOS?
- Is the proposed description well-specified enough? Are
uname
output and flags consistent enough to use it as a standard? Based on the description ofhost.id
it sounds like it should be okay, but I am happy to consider a different definition if something is suggested.
joaopgrassi, arminru, rockdaboot and iblancasa
Metadata
Metadata
Assignees
Labels
No labels