Add .NET network + HTTP connection spans #1192
Conversation
| Span name SHOULD be `DNS {dns.question.name}`. | ||
| Span kind SHOULD be `CLIENT` | ||
|
|
||
| Corresponding `Activity.OperationName` is `System.Net.NameResolution.DnsLookup`, `ActivitySource` name - `System.Net.NameResolution`. |
There was a problem hiding this comment.
Should a future custom DNS resolver, emit the same span? Should it come from the same activity source?
There was a problem hiding this comment.
@lmolkova actually, this is even more tricky. The current System.Net.Dns telemetry (including the dns.lookup.duration metric) covers protocol-independent lookup methods (eg. reverse lookup).
It would make sense to include those in our spans as well. We have to figure out our naming strategy. We can keep everything under the dns* terminology but document that it may cover more, or find an alternative term, like resolver.
There was a problem hiding this comment.
I updated the description, could you please check if it's addressed now?
(also would appreciate span names suggestions) for forward/reverse lookup.
lmolkova
force-pushed
the
dotnet-http-connection-spans
branch
from
7d7c232
to
9a4ba14
Compare
lmolkova
force-pushed
the
dotnet-http-connection-spans
branch
from
9a4ba14
to
eb80b71
Compare
lmolkova
force-pushed
the
dotnet-http-connection-spans
branch
from
f6f4a99
to
0e56f65
Compare
lmolkova
changed the title
docs/dotnet/dotnet-network-traces.md
Outdated
| | [`error.type`](/docs/attributes-registry/error.md) | string | Socket error code. [1] | `connection_refused`; `address_not_available` | `Conditionally Required` if and only if an error has occurred. |  | | ||
| | [`network.peer.address`](/docs/attributes-registry/network.md) | string | Peer address of the network connection - IP address or Unix domain socket name. | `10.1.2.80`; `/tmp/my.sock` | `Recommended` |  | | ||
| | [`network.peer.port`](/docs/attributes-registry/network.md) | int | Peer port number of the network connection. | `65123` | `Recommended` |  | | ||
| | [`network.type`](/docs/attributes-registry/network.md) | string | [OSI network layer](https://osi-model.com/network-layer/) or non-OSI equivalent. [2] | `ipv4`; `ipv6` | `Recommended` |  | |
There was a problem hiding this comment.
Similarly, needs a comment that this is IP-only.
It's unclear what should we report for UDS from the network.* attribute list.
There was a problem hiding this comment.
we should report network.transport for unix domain sockets. Could we return it (report it if it's not TCP)?
There was a problem hiding this comment.
Replied in dotnet/runtime#103922 (comment) so networking folks can see the discussion.
lmolkova
force-pushed
the
dotnet-http-connection-spans
branch
from
ae799fd
to
46d772f
Compare
| Span name SHOULD be `TLS client handshake {server.address}` when authenticating on the client side and `TLS server handshake` when authenticating the server. | ||
| Span kind SHOULD be `INTERNAL` in both cases. | ||
|
|
||
| When *TLS* span is reported for client-side authentication along with *HTTP connection setup* and *Socket connect* span, the *TLS* span becomes a child of *HTTP connection setup*. |
There was a problem hiding this comment.
If I'm not mistaken, isn't the TLS handshake part of the socket creation process? If that's the case, should it be the child of that span if it exists?
There was a problem hiding this comment.
No, System.Net.Sockets.Socket is a thin wrapper over OS sockets, which do not do encryption.
There was a problem hiding this comment.
But you can't write to a secure socket until the TLS handshake is done, right? I suppose if you're modelling the socket span as being representative of the creation of the socket but before protocol configuration is done, thus allowing it to be used to transmit data, this makes sense.
I suppose my world view is influenced by how OkHttp's lifecycle events model this, bundling the configuration with the creation given a secure socket isn't truly ready to go until the TLS handshake is done.
If this makes more sense for the .NET, fair enough 😅
There was a problem hiding this comment.
bundling the configuration with the creation given a secure socket isn't truly ready to go until the TLS handshake is done.
We model the creation period with the new spans, or in our terminology, "connection setup".
There is no such thing as "secure socket" in lower level layers. The counterpart that best matches the "creation of a secure socket" is our "HTTP connection_setup" span:
Note: TLS client has been renamed to TLS client handshake since I took that screenshot.
|
@trustin @swankjesse @minwoox I know this is a tall order, but I'll ask anyway since years ago you all had helped with this and led to zipkin annotations or otherwise. Do you have some cycles to review otel semantics (aka data recording conventions like tag names which are called attributes in otelngish)? I know you have all very deep work in interception and lifecycle of HTTP and there are some subtleties here which are more than meets the eye 🤖 |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
* Remove absolute links where possible. * Work around semantic conventions. * Docfx. * Fix YAML. * More docfx.
* Remove absolute links where possible. * Work around semantic conventions. * Docfx. * Fix YAML. * More docfx.
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
@antonfirsov could you please review and approve if it aligns with the implementation? Thanks! |
This PR introduces additional network-level spans to-be emitted by .NET 9 🤞
Related to #454, #1226
In particular:
On .NET every
ActivitySource(aka tracer) is opt-in, so users have full control over what they are enabling.The volume of new telemetry is expected to be low (with caveats):
Overall, the feature is intended to help debug issues like: