Intended use cases
Whether you are a developer running software locally or an #SRE investigating production hiccups, you sometimes need to inspect how a specific job behaves.
If you organization is mature, services probably provide logs and metrics that you collect and expose in a dashboard. In some situations, however, such platforms may feel too limited or too vast. In particular, monitoring platforms are meant to aggregate information across jobs and across time, thus if your problem is to identify how a single job operates at short time-scale you may feel limited or overwhelmed.
If you are a developer you likely find that configuring a whole metrics and dashboard infrastrucure is too much overhead for development purposes. As a results, counters rarely get added and low-hanging fruits around monitoring are missed. Rightfully, developers find a low return-on-efforts to pro-actively add metrics while developing new features.
Prometheus-monitor’s primary goal is to address such niche use cases where you
need or want to focus on individual jobs or individual metrics. In particular,
it is useful when your diagnostics have little repetition from one situation to
another: point it to
/metrics endpoints and you get some live graphs to see.
How to run it?
Firefox extension (recommended)
Directly in the browser
The submission and review process for Chrome is longer than for Firefox. My extension is currently in review. Once (if) approved, the usage will be the same as for Firefox.
- fix bug with zombie polling threads when we go ‘too fast’
- some tooltips on buttons
- prevent/highlight/keep-around exporter sources when the panel is removed and zoomed metric exist
- styling of labels
- group-rows by metric-name in previews
- add headers on ajax calls
- chart more than a timeseries on a panel
- add minimalistic functions that could translate to Prometheus (e.g., log, unit-changes)
The Prometheus project shows a DEMO instance , do not hammer it please.
‘Failed to fetch’ an URL that works from my browser, but gives CORS errors in the console
You may want to use a so-called ‘CORS-proxy’ (i.e., an HTTP web proxy that adds CORS-authorization headers).
modify your code
If you can mod the binary you are running, the easiest way likely is to set a CORS-header allowing this page to get data on the metrics endpoint you want to probe.
You may find open-proxies but you have no way to tell what they will do with your in-flight requests: cacheing, rate-limitations, data-collection. Plus open-proxies will only be able to access public endpoints (i.e., not for dev environments).
I’ve found the All Origins open proxy to work if you want to probe public endpoints (like the prometheus demo).
run the proxy locally
If you shop around on GitHub you will find some solutions. For instance I’ve
found GoBetween to work as claimed in the
README. If you manage to run this package locally on port
3000 you can try
serve the JS directly from your endpoint
This is the solution I take in
prodapi, just serve the
you serve as well. Optionally, the HTML can have a div with ID
select the script insertion place.
<div id="metrics"></div> <script src="/js/prometheus-monitor.js"></script>
You’ll need some CSS to style it, but this will come later (when I’m out of alpha mode).