Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include "socket family" and/or OSI layer 3 "network type" in HTTP semconv? #3438

Closed
trask opened this issue Apr 24, 2023 · 4 comments · Fixed by #3426
Closed

Include "socket family" and/or OSI layer 3 "network type" in HTTP semconv? #3438

trask opened this issue Apr 24, 2023 · 4 comments · Fixed by #3426
Assignees
Labels
area:semantic-conventions Related to semantic conventions semconv:HTTP spec:trace Related to the specification/trace directory

Comments

@trask
Copy link
Member

trask commented Apr 24, 2023

from @AlexanderWert's #3371 (comment):

net.sock.family -> network.type: This sounds different from net.transport. It sounds like it would be set to LTE or Ethernet, etc (something currently stored in net.host.connection.type). Can we come up with a better name (network.sock_family)?

I think OTel's net.sock.family and ECS' network.type describe slightly different things (though related):

  • net.sock.family refers to Linux Address Families which is not tied to a specific OSI Model layer (e.g. IPv4 / IPV6 is OSI Layer 3, while Bluetooth is Layer 2).
  • network.type refers to the OSI Layer 3 explicitly as you can see in the ECS description.

So, as those are describing different things, how about having both (network.sock_family and network.type)?

Regarding the name network.type, actually, the name describes what it is: the type of the OSI network layer (Layer 3).

the question remains, do we want to include either or both network.type and network.socket.family in the HTTP semantic conventions as part of initial stability?

@lmolkova
Copy link
Contributor

lmolkova commented Apr 25, 2023

network.type and network.transport should be enough to cover HTTP cases, but not IPC communication (unix domain sockets, local IO, pipes, etc), or non-OSI stacks such as bluetooth.

I believe we should relax ECS definitions beyond OSI and extend network.transport and network.type enums.
The alternative is that we maintain different attribute sets for OSI protocols and others and then it'd be hard to consume and understand this telemetry.

Current net.transport OTel attribute already made an attempt there with pipe and inproc transports - we can keep extending it and define unix for local domains or rfcomm for bluetooth.
Python and JS instrumentations already use unix for net.transport.

With this correction, we can remove net.sock.family.

@lmolkova
Copy link
Contributor

Ah, and unix was in net.transport enum, until someone removed it in #2614 🤐

@Oberon00
Copy link
Member

Last time I checked net.transport was a closed enum with a value "other" that would cover "everything else"

@lmolkova
Copy link
Contributor

Last time I checked net.transport was a closed enum with a value "other" that would cover "everything else"

it'd still be nice to re-introduce unix (if we end up removing net.sock.family)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions semconv:HTTP spec:trace Related to the specification/trace directory
4 participants