-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[receiver/hostmetrics] add udp connections #11046
[receiver/hostmetrics] add udp connections #11046
Conversation
Since this is part of the specification https://github.com/open-telemetry/opentelemetry-specification/blob/7e35bec9401d9bc970a7107af45906c0890040b6/specification/metrics/semantic_conventions/system-metrics.md I believe we have to update the spec first. |
The spec defines |
receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper.go
Outdated
Show resolved
Hide resolved
2d6c179
to
385ea86
Compare
Yes I guess I was thinking about this in the context of the As a comparison point, the node exporter in Prometheus separates netstat metrics per protocol:
To be clear I don't have strong feelings one way or the other, just want to make sure we're doing the right thing for users. |
Ok. I still think sum aggregation over |
@dmitryax i'm ok with this proposal. i've added a question around protocol attribute to the spec PR for addressing Please take a look at this PR. A couple of questions:
|
I believe we shouldn't within scope of this change for consistency with TCP, we can revisit it later for both.
Sorry, I'm not sure I understand the question. Why do we need to omit any attribute? If an attribute is defined for a metric in metadata.yaml, it must be always emitted |
return fmt.Errorf("failed to read UDP connections: %w", err) | ||
} | ||
|
||
// TODO: state attribute should be omitted for UDP connections |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your second question now. I answered before looking at the code. This seems like a good reason to separate metrics. Attribute values should not be dependent on each other. Can you please bring this problem to the spec issue for separating the metric. Maybe we should wait until that spec issue is resolved before merging this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻 I'll see what the feedback from the spec to my question in this PR is open-telemetry/opentelemetry-specification#2617, please add yours there. I can open a separate issue if enough folks feel that separating the protocol makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just chiming in to say that I agree that the initial approach of recording these as separate metrics makes the most sense.
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
This change adds a metric for UDP connections. As part of this I've renamed `system.network.connections` to `system.network.tcp.connections` as it wasn't clear to me that UDP and TCP provide any value when combined. Additionally, the state attribute didn't make sense for UDP connections.
27d5874
to
3c08892
Compare
Updated the code to use a feature gate to help users migrate to the metric w/o a protocol attribute like we did for direction. This PR will wait for open-telemetry/opentelemetry-specification#2675 to be merged before moving forward. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
This change adds a metric for UDP connections
system.network.udp.connections
.As part of this I've renamed
system.network.connections
tosystem.network.tcp.connections
as it wasn't clear to me that UDP and TCP provide any value when combined. Additionally, the state attribute didn't make sense for UDP connections.