Nowadays an application, running directly on a bare metal machine is nearly unheard of. Often an application runs in a container that runs in some container orchestration which sometimes runs on a VM which ultimately runs on a physical machine. Bonus fact: VMs may be moved across physical machines during their lifetime.
The host resource has a quite vague description "A host is defined as a general computing instance." so it seems like it could apply to all of machine/VM/container, which is generally good.
As brought up in #1841 (comment), it is unclear what to actually report now on this host resource, since there can only be one.
There are separate resources to describe containers and pods, but these (should) only contain attribute keys which are specific to these kinds of resources.
I think this is quite a spec deficit we have here. Some suggestions:
-
Host should apply to the "innermost" thing the app is running on. E.g. the container if running inside one,
otherwise the VM if running inside one, otherwise of course the physical machine. I think this is usually also the
only thing that is implementable on the agent/instrumentation side. Information about the outer layers would often
have to be added by an external observer.
I think this point should be added to the spec rather soon, as more or less a clarification/bugfix.
-
If we want to allow reporting multiple layers, we should add some prefix to the attribute names. E.g. report the VM's hostname in host.outer.vm.name. There can be complex situations with nested virtualization/containerization. If we want to represent these, more thinking and careful design is needed.
Nowadays an application, running directly on a bare metal machine is nearly unheard of. Often an application runs in a container that runs in some container orchestration which sometimes runs on a VM which ultimately runs on a physical machine. Bonus fact: VMs may be moved across physical machines during their lifetime.
The host resource has a quite vague description "A host is defined as a general computing instance." so it seems like it could apply to all of machine/VM/container, which is generally good.
As brought up in #1841 (comment), it is unclear what to actually report now on this host resource, since there can only be one.
There are separate resources to describe containers and pods, but these (should) only contain attribute keys which are specific to these kinds of resources.
I think this is quite a spec deficit we have here. Some suggestions:
Host should apply to the "innermost" thing the app is running on. E.g. the container if running inside one,
otherwise the VM if running inside one, otherwise of course the physical machine. I think this is usually also the
only thing that is implementable on the agent/instrumentation side. Information about the outer layers would often
have to be added by an external observer.
I think this point should be added to the spec rather soon, as more or less a clarification/bugfix.
If we want to allow reporting multiple layers, we should add some prefix to the attribute names. E.g. report the VM's hostname in
host.outer.vm.name. There can be complex situations with nested virtualization/containerization. If we want to represent these, more thinking and careful design is needed.