search

IntersectMBO / cardano-node

The core component that is used to participate in a Cardano decentralised blockchain.
https://cardano.org
Apache License 2.0
3.05k stars 721 forks source link

[FR] - Query node for list of outgoing/incoming connections and its state #5914

Open Scitz0 opened 1 month ago

Scitz0 commented 1 month ago

Internal/External External

Area Other

Describe the feature you'd like When in P2P mode, we need a way to query the node for currently established incoming and outgoing connections with their state. State of connection should include hot/warm status for outgoing and uni-directional, bi-directional, duplex mode for all. The current metrics you can get from the node provide the numbers, but not specifically what IP has what state and if its incoming/outgoing. This could be included in Prometheus or EKG metrics, alternatively as a cardano-cli query.

This would be very beneficial when troubleshooting topology issues or just for general health checks that the node has connections to own nodes and in the preferred mode.

Describe alternatives you've considered Before P2P we could use system tooling to query for established incoming and outgoing connections as they where all uni directional. This is no longer possible with P2P enabled. You can only see 'active connections'.

rdlrt commented 1 month ago

This has been missing since introduction of P2P and raised unofficially across discord/tg channels. In absence of interest/plan to implement, we are forced to drop support for 'direction' on gLiveView peers section - but it is an important information for analyzing and monitoring peer behaviors connecting to the node

TrevorBenson commented 1 month ago

Additionally when an SPO uses containers that do not use --network host, and publishes the container ports, this can add additional complexity to confirming the state of node connectivity. Changes in various container network technologies (CNI vs. Aardvark, etc.) may also reduce the visibility of connectivity from the container host point of view, which adds additional complexity for stake pool operators.

While these issues are not limited to containers running a node, this request would provide a solution which could also address issues with limitations in the various technologies/architectures employed to run a node.

TrevorBenson commented 1 month ago

Additionally when an SPO uses containers that do not use --network host, and publishes the container ports, this can add additional complexity to confirming the state of node connectivity. Changes in various container network technologies (CNI vs. Aardvark, etc.) may also reduce the visibility of connectivity from the container host point of view, which adds additional complexity for stake pool operators.

While these issues are not limited to containers running a node, this request would provide a solution which could also address issues with limitations in the various technologies/architectures employed to run a node.

The issue I mentioned appears to have been resolved with recent updates. However, I'd still love to see this feature implemented as it provides a great amount of additional detail.

:pray:

github-actions[bot] commented 2 weeks ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

Scitz0 commented 2 weeks ago

Issue (feature request) is still highly requested by me and the broader community. A response for plan of implementation would be appreciated.