feat(metrics)!: expose identify metrics for connected peers only #3325
Conversation
Previously we would increase a counter / gauge / histogram on each received identify information.
These metrics are missleading, as e.g. they depend on the identify interval and don't represent the
set of currently connected peers.
With this commit, identify information is tracked for the currently connected peers only. Instead of
an increase on each received identify information, metrics represent the status quo (Gauge).
Example:
```
\# HELP libp2p_libp2p_identify_remote_protocols Number of connected nodes supporting a specific protocol, with "unrecognized" for each peer supporting one or more unrecognized protocols...
\# TYPE libp2p_libp2p_identify_remote_protocols gauge
libp2p_libp2p_identify_remote_protocols_total{protocol="/ipfs/id/push/1.0.0"} 1
libp2p_libp2p_identify_remote_protocols_total{protocol="/ipfs/id/1.0.0"} 1
libp2p_libp2p_identify_remote_protocols_total{protocol="/ipfs/ping/1.0.0"} 1
libp2p_libp2p_identify_remote_protocols_total{protocol="unrecognized"} 1
\# HELP libp2p_libp2p_identify_remote_listen_addresses Number of connected nodes advertising a specific listen address...
\# TYPE libp2p_libp2p_identify_remote_listen_addresses gauge
libp2p_libp2p_identify_remote_listen_addresses_total{listen_address="/ip4/tcp"} 1
libp2p_libp2p_identify_remote_listen_addresses_total{listen_address="/ip4/udp/quic"} 1
\# HELP libp2p_libp2p_identify_local_observed_addresses Number of connected nodes observing the local node at a specific address...
\# TYPE libp2p_libp2p_identify_local_observed_addresses gauge
libp2p_libp2p_identify_local_observed_addresses_total{observed_address="/ip4/tcp"} 1
```
Setting to draft until ready for review. |
|
This pull request has merge conflicts. Could you please resolve them @mxinden? 🙏 |
…etrics-collector
|
@thomaseizinger can you give this pull request a review? It builds on top of prometheus/client_rust#82. prometheus/client_rust#82 has not yet been released. Would be good to get some input on a usage of prometheus/client_rust#82 before I release prometheus/client_rust#82. |
|
Looks fine to me. I am not fond of the name "collector". What about "static" or "const" metrics? |
The name is used across all Prometheus client libraries and well documented. I agree that it is not intuitive. That said, I think staying consistent is the better approach. |
misc/metrics/src/identify.rs
Outdated
| let mut protocols: Vec<_> = peer_info | ||
| .protocols | ||
| .iter() | ||
| .map(|p| { | ||
| if ALLOWED_PROTOCOLS.contains(&p.as_bytes()) { | ||
| p.to_string() | ||
| } else { | ||
| "unrecognized".to_string() | ||
| } | ||
| }) | ||
| .collect(); | ||
| protocols.sort(); | ||
| protocols.dedup(); |
There was a problem hiding this comment.
Could we extract this into a helper and thus make the loop a bit easier to read?
|
Note that this pull request now updates |
|
This pull request is ready to merge from my end. @thomaseizinger would you mind taking another look? |
misc/metrics/src/identify.rs
Outdated
| static PROTOCOLS_DESCRIPTOR: Lazy<Descriptor> = Lazy::new(|| { | ||
| Descriptor::new( | ||
| "remote_protocols", | ||
| "Number of connected nodes supporting a specific protocol, with \ |
There was a problem hiding this comment.
Use an r#""# string to avoid the escaping?
thomaseizinger
changed the title
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Description
Previously we would increase a counter / gauge / histogram on each received identify information. These metrics are missleading, as e.g. they depend on the identify interval and don't represent the set of currently connected peers.
With this commit, identify information is tracked for the currently connected peers only. Instead of an increase on each received identify information, metrics represent the status quo (Gauge).
Example:
Notes
Depends on new release of https://github.com/prometheus/client_rust that includes prometheus/client_rust#82.
Links to any relevant issues
Open Questions
Change checklist