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

Rename net peer/host attributes to align with ECS #3199

Closed
Tracked by #1012
trask opened this issue Feb 9, 2023 · 1 comment · Fixed by #3402
Closed
Tracked by #1012

Rename net peer/host attributes to align with ECS #3199

trask opened this issue Feb 9, 2023 · 1 comment · Fixed by #3402
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 Feb 9, 2023

What are you trying to achieve?

Rename net.* attributes to the corresponding ECS names under client.* and server.* (see open-telemetry/oteps#222 for motivation).

HTTP client attributes:

  • net.peer.name -> server.address
  • net.peer.port -> server.port
  • net.sock.peer.name
    • when it represents a proxy -> server.nat.address (as a new field in ECS)
    • (is there any other case?)
  • net.sock.peer.addr
    • when it represents the ip address of the server.address -> server.ip
    • when it represents a proxy -> server.nat.ip
    • when it represents a unix socket -> server.socket.address (as a new field in ECS)
    • (is there any other case?)
  • net.sock.peer.port

HTTP server attributes:

  • net.host.name -> server.address
  • net.host.port -> server.port
  • net.sock.host.addr -> server.socket.ip (as a new field in ECS)
    • when it represents a unix socket -> server.socket.address (as a new field in ECS)
  • net.sock.host.port -> server.socket.port (as a new field in ECS)
  • net.sock.peer.name -> (remove from OTel, not needed)
  • net.sock.peer.addr -> client.ip
    • when it represents a unix socket -> client.socket.address (as a new field in ECS)
  • net.sock.peer.port -> client.port
@trask trask added area:semantic-conventions Related to semantic conventions spec:trace Related to the specification/trace directory semconv:HTTP labels Feb 9, 2023
@trask trask self-assigned this Feb 9, 2023
@trask
Copy link
Member Author

trask commented Feb 10, 2023

We discussed in HTTP semconv stability WG today that the nat field create some difficulty for observability where some instrumentation (e.g. Java's netty) may not be aware of whether its talking to a proxy or not.

And it seems confusing to use nat namespace when we aren't sure we're talking to a proxy/intermediary.

So here's an alternate proposal to the above:

HTTP client attributes:

  • net.peer.name -> server.address
  • net.peer.port -> server.port
  • net.sock.peer.name -> server.socket.address (new field in ECS)
  • net.sock.peer.addr -> server.socket.ip (new field in ECS)
    • when it represents a unix socket -> server.socket.address (new field in ECS)
  • net.sock.peer.port -> server.socket.port (new field in ECS)

HTTP server attributes:

  • net.host.name -> server.address
  • net.host.port -> server.port
  • net.sock.host.addr -> server.socket.ip (new field in ECS)
    • when it represents a unix socket -> server.socket.address (new field in ECS)
  • net.sock.host.port -> server.socket.port (new field in ECS)
  • net.sock.peer.name -> (remove from OTel, not needed)
    • if needed -> client.socket.address (new field in ECS)
  • net.sock.peer.addr -> client.ip
    • when it represents a unix socket -> client.socket.address (new field in ECS)
  • net.sock.peer.port -> client.port

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
2 participants