adding mtu and speed tags to interfaces that support it#18819
Conversation
iliakur
left a comment
There was a problem hiding this comment.
Thanks for the contribution @ocient-cliimatta!
Do I understand correctly that this will only work on linux?
Could you add a changelog entry and fix the formatting?
Here are some links to get you started:
- https://datadoghq.dev/integrations-core/setup/
- https://datadoghq.dev/integrations-core/guidelines/pr/
- https://datadoghq.dev/integrations-core/testing/#usage
To clarify, the changes proposed here will only affect Linux systems, since the network check files are split out by major OS distribution name. My change only modifies check_linux.py, so it won't even run on any other OS types |
|
@ocient-cliimatta any tips for how to add unit tests for this? I'll do that as a follow-up, but would appreciate pointers when it comes to the data that's necessary. |
|
@iliakur This integration is a bit strange, it seems that some of the metrics are emitted when running My change uses the _read_int_file() method to return the contents of mtu and speed under That test already covers opening the mtu file since it's used as the value of I would suggest adding a test for that path, usually interface speeds would be one of 10/100/1000/10000/100000 And test for an "invalid" adapter name I can't tell if any of the tests assert that tag values are set, but if such a thing exists, the metrics listed here should all include something like Looks like the metrics themselves are checked here |
What does this PR do?
This PR will add two new tags (mtu and speed) to any network device that supports that information out of /sys/class/net/
If the data cannot be determined it is skipped (for example, the
lointerface has no speed).The following
system.netmetrics will receive the new tags:Motivation
It's currently not possible to build host network device dashboards grouped by speed, unless you manually define which interfaces are which speed (this can be different between OS flavors, or just different server configurations).
There is an existing metric named
system.net.iface.mtuwhich is tagged byiface, but in my opinionmtumakes more sense to be in a tag, MTU does not change often (or ever) in a server's lifetime. Graphing MTU in a timeseries is not very useful.With this change, you could build dashboards where you can differentiate between your 1Gb interfaces vs. your 10Gb interfaces like this:
avg:system.net.bytes_rcvd{host:$host, speed:10000} by {device}or
avg:system.net.bytes_rcvd{host:$host} by {device,speed}Additional Notes
This change is only tested on linux, but could be extended to the other OS specific network check files
Review checklist (to be filled by reviewers)
qa/skip-qalabel if the PR doesn't need to be tested during QA.backport/<branch-name>label to the PR and it will automatically open a backport PR once this one is merged