Skip to content
This repository has been archived by the owner on Nov 28, 2022. It is now read-only.

appmetrics- and javametrics-dash to monitor metrics by polling /metrics #514

Closed
mattcolegate opened this issue Sep 23, 2019 · 4 comments
Closed

Comments

@mattcolegate
Copy link
Contributor

Codewind version: vNext
OS: All

Che version: N/A
IDE extension version: N/A
IDE version: N/A
Kubernetes cluster: N/a

Description of the enhancement:

This is step 1 in a multi step process to improve the performance dashboard to automatically pick up and display metrics broadcast on a /metrics endpoint. This work will cover appmetrics-dash and javametrics-dash gaining code to poll a /metrics endpoint on localhost every 10 seconds and to display the data retrieved in as simple a form as possible, in order to prove the concept.

Proposed solution:

Bare bones spec:

  • Dashboard will poll http(s)://localhost/metrics every 10 seconds
  • Dashboard shows data retrieved - block of text or table

@mattcolegate to cover Javametrics, @rwalle61 covers Appmetrics.

Use Prometheus-enabled application as our test app.

cc @tobespc

@deboer-tim
Copy link
Contributor

What's the main difference between appmetrics-dash and javametrics-dash today? I think one of the goals of this would be to have a single dash that can poll any container's /metrics, possibly with some detection to graph specifics for different languages or frameworks based on what's in the feed.

@mattcolegate
Copy link
Contributor Author

The main difference is in the type of metrics exposed that are language-specific - Node, for example, has the Event Loop Latency that is useful for asymmetric programs to monitor to see when their next portion of code will be executed, something that Java doesn't have.
Most of the dashboard's functional backends come from the same common codestream https://github.com/runtimetools/graphmetrics so it's absolutely feasible to aim for more commonality. As stated in the description though, this is step 1 of a larger item that will span several issues, so I'm more interested in keeping this particular issue quite tightly defined. Ordinarily I would have raised an Epic to tie the multiple forthcoming issues together, but I couldn't see a way of doing that :-)

@rwalle61
Copy link
Contributor

rwalle61 commented Nov 6, 2019

@mattcolegate
Copy link
Contributor Author

This work has been delivered.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants