3 ms·

If you’re looking into time-series based monitoring/alerting, I’ve been delighted with http://prometheus.io/ http://prometheus.io/. I’m mentioning this because

by secure 11y ago

If you’re looking into time-series based monitoring/alerting, I’ve been delighted with http://prometheus.io/ http://prometheus.io/. I’m mentioning this because I previously tried to use OpenTSDB for monitoring (back when prometheus and others didn’t exist), and found it too cumbersome to run (not packaged in Debian, requires an underlying HBase instance, etc.) for my taste. Many more recently created projects, such as Prometheus, come pre-packaged in a Docker container and can run on a single host — often they’re even a single binary.

krenoten 11y ago
Prometheus is for smaller problems. You have to manage your own sharding with prometheus, so it doesn't work for handling large volumes of data unless you are willing to do complex automation for a large number of disparate replication topologies. This works fine at Soundcloud, where it came from, because the teams there like keeping their monitoring systems isolated from each other because they don't trust each other. For problems where you require a single source of truth for high volumes of data, you can't really justify that kind of effort for the data management when distributed databases have been created to solve this problem. Prometheus is nice and featureful, but it makes me laugh when the proponents (usually [ex-]soundcloud folks) brag about how scalable it is. Side note: they love to say that because it's pull based, that magically makes it more scalable. This is a crock of shit. Push vs Pull doesn't get you out of capacity planning, and from this perspective they are identical in terms of throughput requirements. Pull means you need a single source to know about a ton of endpoints. Push means you need a ton of sources to know about a single endpoint. Which one is simpler to operate? They say it's more scalable because when they failed to properly do capacity planning, it hid their dropped data more effectively and their dashboards kept running, oblivious to the degredation.
- nanoojaboo 11y ago
  I always see Prometheus/SoundCloud developers on here or elsewhere promoting their free product. What benefit do they get if not financial? (modest fame, self-satisfaction that their product's being used etc)

by secure 11y ago

krenoten 11y ago

Prometheus is for smaller problems. You have to manage your own sharding with prometheus, so it doesn't work for handling large volumes of data unless you are willing to do complex automation for a large number of disparate replication topologies. This works fine at Soundcloud, where it came from, because the teams there like keeping their monitoring systems isolated from each other because they don't trust each other. For problems where you require a single source of truth for high volumes of data, you can't really justify that kind of effort for the data management when distributed databases have been created to solve this problem. Prometheus is nice and featureful, but it makes me laugh when the proponents (usually [ex-]soundcloud folks) brag about how scalable it is. Side note: they love to say that because it's pull based, that magically makes it more scalable. This is a crock of shit. Push vs Pull doesn't get you out of capacity planning, and from this perspective they are identical in terms of throughput requirements. Pull means you need a single source to know about a ton of endpoints. Push means you need a ton of sources to know about a single endpoint. Which one is simpler to operate? They say it's more scalable because when they failed to properly do capacity planning, it hid their dropped data more effectively and their dashboards kept running, oblivious to the degredation.

nanoojaboo 11y ago
I always see Prometheus/SoundCloud developers on here or elsewhere promoting their free product. What benefit do they get if not financial? (modest fame, self-satisfaction that their product's being used etc)