4 ms·

I'm curious if any HNers have opinions on prometheus vs other time series databases like influxdb? I periodically consider a grafana & backend setup for when d

by chrsig 4y ago

I'm curious if any HNers have opinions on prometheus vs other time series databases like influxdb? I periodically consider a grafana & backend setup for when datadog becomes cost prohibitive for metrics with several tags.

firstSpeaker 4y ago
Go with Mimir. It is Prometheus compatible and horizontally scalable for read/write path separately. Mimir: https://github.com/grafana/mimir https://github.com/grafana/mimir
- deleted 4y ago
  [deleted]
- flyingsky 4y ago
  You did not answer OPs question tho'. prometheus vs influxDB.
beardedetim 4y ago
At $dayjob we're considering replacing DataDog with Grafana and friends, already using it elsewhere to great affect. Haven't used influxdb yet so can't speak as a comparison but from my usage, I'm sold on Grafana, Loki, Prometheus, and friends over DataDog. It mixed with OTel have been a real pleasure to use.
- therealdrag0 4y ago
  We’ve done that migration at $dayjob. Has taken a lot of getting used to. The data model is different (perhaps poor setting choices) causing some wacky query requirements for our charts which devs often don’t understand to misleading charts. We’re slowly switching to OTEL which should solve that problem. Otherwise there’s also much to be desired in how our grafana behaves interims of saving preferences (ours doesn’t; stateless head? I forget why) which is annoying. Also the tracing/APM is missing out of the box though some teams are working on getting that going too. So a classic build vs buy story I guess. Probably will pay less in the long run but for a worse and rocky road experience so far.
xiwenc 4y ago
We have been using prometheus at a client for little over a year now. Since we need to keep metrics for years, prometheus cannot seem to be able to deal with it well. One behavior we observed is it crashes consistently in k8s. We couldn’t pin down the root cause but suspect it’s the amount of metrics we collect continuously and keep (archive). Now we are considering to switch to thanos or mimir.

by chrsig 4y ago

firstSpeaker 4y ago

Go with Mimir. It is Prometheus compatible and horizontally scalable for read/write path separately. Mimir: https://github.com/grafana/mimir https://github.com/grafana/mimir

deleted 4y ago
[deleted]
flyingsky 4y ago
You did not answer OPs question tho'. prometheus vs influxDB.

beardedetim 4y ago

At $dayjob we're considering replacing DataDog with Grafana and friends, already using it elsewhere to great affect. Haven't used influxdb yet so can't speak as a comparison but from my usage, I'm sold on Grafana, Loki, Prometheus, and friends over DataDog. It mixed with OTel have been a real pleasure to use.

therealdrag0 4y ago
We’ve done that migration at $dayjob. Has taken a lot of getting used to. The data model is different (perhaps poor setting choices) causing some wacky query requirements for our charts which devs often don’t understand to misleading charts. We’re slowly switching to OTEL which should solve that problem. Otherwise there’s also much to be desired in how our grafana behaves interims of saving preferences (ours doesn’t; stateless head? I forget why) which is annoying. Also the tracing/APM is missing out of the box though some teams are working on getting that going too. So a classic build vs buy story I guess. Probably will pay less in the long run but for a worse and rocky road experience so far.

xiwenc 4y ago

We have been using prometheus at a client for little over a year now. Since we need to keep metrics for years, prometheus cannot seem to be able to deal with it well. One behavior we observed is it crashes consistently in k8s. We couldn’t pin down the root cause but suspect it’s the amount of metrics we collect continuously and keep (archive). Now we are considering to switch to thanos or mimir.