&gt; Umm, yeah, but well, isn&#x27;t that the punchline of every monitoring project? ;-)<p>No actually :)<p>From reading countless websites for the multitude of monitoring solutions out there, the standard pitch is that they&#x27;ll make your operations more efficient, magically detect problems and give you new insights into your systems.<p>It&#x27;s actually really annoying, as you have to dig deep into their docs and squint at screenshots to figure out that actually it&#x27;s just another Nagios clone :)<p>&gt; I don&#x27;t understand. Isn&#x27;t that twitter blog essentially saying that they went from pull to push? Or is the main point here that they changed to have the agent on each host that collects everything on that host before transferring those metrics to the server (whether that&#x27;s push or pull)?<p>What I take from it was had they kept the same design and just changed to push, they&#x27;d have continued to have had the exact same problems. I&#x27;d view the addition of isolation and health information as what really solved the issue, and whether push or pull is better for that is a wash.<p>&gt; But I&#x27;m not sure Prometheus bends to this either, since IIUC each metric is stored in a separate file, and if we&#x27;d have a bunch of metrics for each job ID in the system, this wouldn&#x27;t really work out, would it?<p>I&#x27;d need a bit more detail to give an exact solution, but Prometheus should work fine for for this.<p>Metrics are fetched over HTTP by Prometheus, and they usually don&#x27;t come from files. You&#x27;d either have Prometheus scrape each job individually, or scrape your controller daemon that&#x27;d attach a labels indicating the job of each metric.