Prometheus-monitor is a low-configuration web application. Run Prometheus-Monitor to inspect data from services which expose metrics in the Prometheus-format.



Add local storage.

The definitions of sources and pinned graph should persist across runs.

At the moment there is no way to namespace these sources but it will come eventually.


Revamp of the Web UI.

I’ve revamped the web interface with the wonderful Bulma CSS framework.


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?

Prometheus-Monitor is a JavaScript application running in a web-browser. As such the requirements on Prometheus-Monitor are pretty low. However, web-browsers are sanboxed and limit what queries a page can send. In our case, the caveat is that if the JavaScript runs in a web-page: HTTP GET queries to Prometheus endpoints are subject to CORS authorizations (this is the reason why I enable CORS on the /metrics endpoint of prodapi applications). The recommended way to circumvent CORS is to install the application as a browser extension.

note: I haven’t yet upgraded the extension to the new UI

You can install the Firefox extension. An icon appears in your extension toolbar, press-it and it will open a static HTML page with the application JavaScript.

Chrome extension

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.

Directly in the browser on localhost via a proxy

Albeit browsers typically disallow cross-origin calls on the Internet, you may get lucky with /metrics pages running on you localhost. Therefore: when developing locally you can use the web browser (my typical use case), or you can likely use install some form of proxy (running locally or allowing CORS).

Steal it and run the JS directly on your premises

I’ll let you come up with your own judgment whether or not you should, but if all of the above fails, a solution is to serve the JavaScript yourself.

I may not keep the instructions up to date but I’ll try keeping a mechanism with low-enough dependencies so that the JavaScript is still embeddable directly on your services pages.

  • HTML (optional): provide a div with id="spa"
  • HTML: insert the JavaScript source
  • CSS (optional but it will look ugly without): import the Bulma stylesheet
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bulma@1.0.0/css/bulma.min.css">
  <script src="/path/to/prometheus-monitor.js"></script>