Add UDP drops collector

[nicolas-laduguie]

No description provided.

[cleeland]

IMHO, this should be named udp_stats and should serve as an umbrella under which to expose all relevant UDP-related stats--including those exposed by udp_queues. By doing that, you don't create a breaking change, but you do offer a place to extend udp-related stats exposition in the future, e.g., retransmits, without having to create yet another specific collector.

At some point you could deprecate udp_queues.

[nicolas-laduguie]

Thanks for the feedback @cleeland .
Just to make sure, are you talking about the collector name?
If so, the problem with this approach is the metrics naming then.
A the moment we have node_udp_queues metric which is served by udp_queues collector.
If we create a new collector called udp_stats, the metrics of that collector should be named differently than the ones of udp_queues and other collectors.
I feel the current name node_udp_queues is accurate and adding one more metric with less accurate name but with same value and same origin would be confusing IMHO.
Even if the amount of collector is significant, it allows very granular activation/deactivation of metric by the collectors.

[cleeland]

are you talking about the collector name?

Yes.

If we create a new collector called udp_stats, the metrics of that collector should be named differently than the ones of udp_queues and other collectors.

The way I was thinking out it, nothing would change under udp_queues. A new collector, udp_stats would look much like what I did in the original PR, except that the collector name would be udp_stats rather than simply udp. Thus, the metrics it would expose would be:

• node_udp_stats_queues {version, direction}
• node_udp_stats_drops { version }
• etc

As a user, I think it makes more sense for node_exporter to follow the structure of the kernel's stats as much as possible. It makes it easier for me to find things and make educated guesses at where to look.