Feature: Create a metrics view #1220
Labels
area/screen/metrics
Issues relating to the metrics screen
effort/days
Estimated to take multiple days, but less than a week
exp/intermediate
Prior experience is likely helpful
kind/discussion
Topical discussion; usually not changes to codebase
kind/enhancement
A net-new feature or improvement to an existing feature
need/analysis
Needs further analysis before proceeding
need/community-input
Needs input from the wider community
need/maintainers-input
Needs input from the current maintainer(s)
P3
Low: Not priority right now
status/deferred
Conscious decision to pause or backlog
topic/design-front-end
Front-end implementation of UX/UI work
topic/design-ux
UX strategy, research, not solely visual design
Milestone
Comments
jessicaschilling
added
exp/intermediate
|
SgtPooki
changed the title
SgtPooki
added
the
kind/discussion
|
@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 expandIs 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. |
SgtPooki
changed the title
SgtPooki
added
need/maintainers-input
|
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! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: