-
Notifications
You must be signed in to change notification settings - Fork 747
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
Fix peer count metrics #5404
Fix peer count metrics #5404
Changes from all commits
b64b7b3
2f83cdd
56d6708
6897ef7
8ceb702
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,7 +4,7 @@ use std::net::IpAddr; | |
use std::task::{Context, Poll}; | ||
|
||
use futures::StreamExt; | ||
use libp2p::core::{multiaddr, ConnectedPoint}; | ||
use libp2p::core::ConnectedPoint; | ||
use libp2p::identity::PeerId; | ||
use libp2p::swarm::behaviour::{ConnectionClosed, ConnectionEstablished, DialFailure, FromSwarm}; | ||
use libp2p::swarm::dial_opts::{DialOpts, PeerCondition}; | ||
|
@@ -243,35 +243,11 @@ impl<TSpec: EthSpec> PeerManager<TSpec> { | |
self.events.push(PeerManagerEvent::MetaData(peer_id)); | ||
} | ||
|
||
// increment prometheus metrics | ||
// Update the prometheus metrics | ||
if self.metrics_enabled { | ||
let remote_addr = endpoint.get_remote_address(); | ||
let direction = if endpoint.is_dialer() { | ||
"outbound" | ||
} else { | ||
"inbound" | ||
}; | ||
|
||
match remote_addr.iter().find(|proto| { | ||
matches!( | ||
proto, | ||
multiaddr::Protocol::QuicV1 | multiaddr::Protocol::Tcp(_) | ||
) | ||
}) { | ||
Some(multiaddr::Protocol::QuicV1) => { | ||
metrics::inc_gauge_vec(&metrics::PEERS_CONNECTED_MULTI, &[direction, "quic"]); | ||
} | ||
Some(multiaddr::Protocol::Tcp(_)) => { | ||
metrics::inc_gauge_vec(&metrics::PEERS_CONNECTED_MULTI, &[direction, "tcp"]); | ||
} | ||
Some(_) => unreachable!(), | ||
None => { | ||
error!(self.log, "Connection established via unknown transport"; "addr" => %remote_addr) | ||
} | ||
}; | ||
|
||
metrics::inc_gauge(&metrics::PEERS_CONNECTED); | ||
metrics::inc_counter(&metrics::PEER_CONNECT_EVENT_COUNT); | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. since we need to revert back into iterating all the connected peers, as @AgeManning suggested let's have all the client metrics updates in the same place, i.e. remove the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jxs Thanks for your comment, that makes sense. I will make an update. |
||
self.update_peer_count_metrics(); | ||
} | ||
|
||
// Count dialing peers in the limit if the peer dialed us. | ||
|
@@ -309,7 +285,7 @@ impl<TSpec: EthSpec> PeerManager<TSpec> { | |
fn on_connection_closed( | ||
&mut self, | ||
peer_id: PeerId, | ||
endpoint: &ConnectedPoint, | ||
_endpoint: &ConnectedPoint, | ||
remaining_established: usize, | ||
) { | ||
if remaining_established > 0 { | ||
|
@@ -337,33 +313,12 @@ impl<TSpec: EthSpec> PeerManager<TSpec> { | |
// reference so that peer manager can track this peer. | ||
self.inject_disconnect(&peer_id); | ||
|
||
let remote_addr = endpoint.get_remote_address(); | ||
// Update the prometheus metrics | ||
if self.metrics_enabled { | ||
let direction = if endpoint.is_dialer() { | ||
"outbound" | ||
} else { | ||
"inbound" | ||
}; | ||
|
||
match remote_addr.iter().find(|proto| { | ||
matches!( | ||
proto, | ||
multiaddr::Protocol::QuicV1 | multiaddr::Protocol::Tcp(_) | ||
) | ||
}) { | ||
Some(multiaddr::Protocol::QuicV1) => { | ||
metrics::dec_gauge_vec(&metrics::PEERS_CONNECTED_MULTI, &[direction, "quic"]); | ||
} | ||
Some(multiaddr::Protocol::Tcp(_)) => { | ||
metrics::dec_gauge_vec(&metrics::PEERS_CONNECTED_MULTI, &[direction, "tcp"]); | ||
} | ||
// If it's an unknown protocol we already logged when connection was established. | ||
_ => {} | ||
}; | ||
// Legacy standard metrics. | ||
metrics::dec_gauge(&metrics::PEERS_CONNECTED); | ||
metrics::inc_counter(&metrics::PEER_DISCONNECT_EVENT_COUNT); | ||
|
||
self.update_peer_count_metrics(); | ||
} | ||
} | ||
|
||
|
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.
thanks for researching this Akihito! But since we get the Multiaddress as soon as the peer connects, can't we add it immediately? Don't worry doesn't need to be address in this PR, I think I plan to submit a subsequent PR cause we also know the direction as soon as the peer connects, so it doesn't make sense
connection_direction()
beNone
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.
Yes, I believe we can do that, but I'm not very familiar with PeerDB. However I've delved a little into the PeerDB implementation recently. During this exploration, I discovered that the Multiaddress obtained when a peer connects is stored in
PeerInfo::seen_multiaddrs
. Theseen_multiaddrs
is stored into PeerInfo here.lighthouse/beacon_node/lighthouse_network/src/peer_manager/peerdb/peer_info.rs
Lines 32 to 34 in d36241b
Given this understanding, would it be appropriate to iterate over
seen_multiaddrs
in cases wherelistening_addresses()
returns empty? This approach could potentially ensure that we always have an address, even immediately after a peer connects.cc @AgeManning