5 ms·

Prometheus developer here, what do you feel it's missing? Telegraf can both read and produce Prometheus metrics, which is something I've worked on as I believe

• lobster_johnson 11y ago
  There's a bunch of things. First, Prometheus prefers that you create an HTTP API for metrics. This means having to manage running daemons, set aside ports, and so on. The fact that it's not pluggable leads to an ecosystem where every "exporter" is HTTP-based and needs to be run and maintained this way. It's not lightweight or ops-friendly. So for our own stuff, we built a single pluggable collector that simply emits text files (scheduled via cron), and uses prometheus-node-exporter's "textfile directory" support to export the data. It's not ideal. And since it's a kind of mini-framework itself, that doesn't follow any community-defined plugin system, we can't easily open-source the bits we think would be useful to others (we have some nice metrics for RabbitMQ, ElasticSearch, PostgreSQL, etc.) because people would have to buy into our little plugin system. I'd much rather that the exporter was pluggable, and was capable of spawning subprocesses. Prometheus also works very poorly/not at all with existing web frameworks such as Ruby's Unicorn and Node.js's cluster module, where there isn't a single process that can track metrics. So far, the attempts to accomplish this with Unicorn, for example, seem unsatisfactory.