Skip to content
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

misc/metrics: Expose bytes send/received per protocol #3262

Open
mxinden opened this issue Dec 19, 2022 · 3 comments
Open

misc/metrics: Expose bytes send/received per protocol #3262

mxinden opened this issue Dec 19, 2022 · 3 comments

Comments

@mxinden
Copy link
Member

mxinden commented Dec 19, 2022

Description

Expose Prometheus metrics counting the number of bytes send and received on streams per protocol.

Rough idea:

libp2p_bytes { direction = "in", protocol = "/ipfs/kad/1.0.0" } 42
libp2p_bytes { direction = "out", protocol = "/ipfs/kad/1.0.0" } 42

Motivation

Allows us to get an intuition of the bandwidth consumption of each of the libp2p protocols.

Requirements

  1. Use fix(libp2p): Don't specify monorepo dev dependencies by version #3261
  2. Implement Collector trait from src/collector: Introduce Collector abstraction prometheus/client_rust#82

Open questions

Are you planning to do it yourself in a pull request?

Not any time soon. Help is much appreciated.

@mxinden mxinden added difficulty:moderate help wanted getting-started Issues that can be tackled if you don't know the internals of libp2p very well labels Dec 19, 2022
@thomaseizinger
Copy link
Contributor

Do you have a vision for how to implement this without adding a dependency onto prometheus directly to libp2p-swarm?

@mxinden
Copy link
Member Author

mxinden commented Dec 30, 2022

We can use #3180 in combination with the upcoming Prometheus Collector abstraction prometheus/client_rust#82.

@thomaseizinger
Copy link
Contributor

#3180 did not introduce a separation per stream though only a sum across all streams. Also, I am not yet sure how we will be able to associate the protocol with the stream because that one is only available before we inject it into the ConnectionHandler at a point where the stream has already been handed off from the muxer.

@thomaseizinger thomaseizinger removed the getting-started Issues that can be tackled if you don't know the internals of libp2p very well label Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants