-
Notifications
You must be signed in to change notification settings - Fork 488
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
Feature: Create a metrics view #1220
Comments
|
@olizilla @hacdias @lidel I'm probably going to be taking this on, so I would love to get a few ideas from those who are interested in such a view.
After loading up the Click to expand
Is there another method of consuming this data? |
My quick take is:
So in practice, we can't hardcode or assume too much:
|
On my way to work this morning I started day-dreaming about how nice it would be to get back to working on developer tools for IPFS & co. A dangerous move as I was riding my bike at the time, but lo! What serendipitous timing! I'd love to pitch in on this! That wall of text is the only format for getting that particular list of data points. It's intended for consumption by Prometheus, the timeseries db, but it's well standardised and much tooling exists for it. The numbers are all point-in-time measurements, intended to be scraped periodically, so it's not such a bad fit for a local dev tool that is already in the habit of polling the api for info. There are some useful metrics in there that we use all the time now, to check if a node is working well, things like bitswap queue length, but in general much of the metrics are super specific, and only really of use to a developer who is making specific changes to a specific subsystem, so we should build up a short list of metrics that are worth putting the spotlight on, and then give experts a way to get to the kitchen sink. |
background concern:
This is a very good place to start... I don't have the answers, but it will involve talking to users and seeing what problems they are hitting. In general, there is a need for high quality dev tooling for ipfs / libp2p / ipld ...when i proposed parsing info from Now I think we can use it to prototype something and get a feel for it, but we should be careful to not end up implementing an incidental subset of prometheus in js. Ideally we also use this work to improve the core ipfs diagnostic apis as well. I think as @SgtPooki is pointing to, parsing info from prometheus metrics for the web UI is not ideal. |
Highly relevant work is happening in:
When we have these go-libp2p improvements released and bubbled up to kubo (go-ipfs), ipfs-webui will be able to benefit from metrics and work done by Marco around fleshing out important metrics and ways to visualize them. |
There is a large amount of metrics things at https://github.com/protocol/metrics |
Hello! |
We want to display a metrics view/page in the IPFS desktop app and webui. Ideally, this view would allow users to view any/all metrics they need, without having to access the CLI or other tools. This view would not have tools or complicated features that would allow users to process those metrics. Instead, they would want to use the Diagnostics View.
Original issue description
Agreed upon metrics
These metrics are ones that we've decided we will implement.
Possible metrics
These metrics have strong arguments and use-cases and need to be discussed to decide whether they are useful enough to surface
const { dataReceived } = await getIpfs().stats.bitswap();
const { dataSent } = await getIpfs().stats.bitswap();
Disqualified metrics
These metrics will not be included in the metrics view for one reason or another.
Looking for community and IPFS Implementers' feedback on this issue.
Here are some questions to help get the ideas flowing.
Which metrics should we focus on?
What/Why/How
The text was updated successfully, but these errors were encountered: