Open rogercoll opened 3 months ago
I'm in favour of this attribute being under the linux
namespace.
Hey @rogercoll, don't you think process will be better option for it? I know it's specific to linux, but process is common for all OS. I think the important namespace here is process
and not the linux
@mjwolf what do you think?
I think this would be better under process
as well. There are already OS specific attributes in process
; process.owner
is Windows specific while process.user.id
and process.group.id
. #1329 will also add another one with gnu.build_id
. So I don't see a problem with adding process.cgroup
, and it seems like a more natural location to me.
don't you think process will be better option for it?
I don't have a strong opinion about it, given that we already have OS specific attributes without the OS namespace it might make sense to have a unified approach (without OS).
We discussed this naming issue during today's system SIG and we notice that some attributes contain the OS while others don't, I think we should agree on the structure and fix these nuances. https://github.com/open-telemetry/semantic-conventions/issues/1403
Area(s)
area:system
Is your change request related to a problem? Please describe.
The
hostmetrics
receiver is currently reporting theprocess.cgroup
attribute: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/processscraper/metadata.yaml#L49This attribute is really helpful as it can be used to extract containerization information like the K8s pod UID and/or the container ID which the process is running on.
Describe the solution you'd like
Standardize the
process.cgroup
attribute.Describe alternatives you've considered
As
cgroups
being a Linux only technology, would it make sense to add the attribute under thelinux
namespace (e.glinux.process.cgroup
)?Additional context
No response