Live data from Hacker News

CERN swaps out databases to feed its petabyte-a-day habit

theregister.com

51–57 of 57 posts

Re: CERN swaps out databases to feed its petabyte-a-day habit

#51
post #47

Earlier quoted context omitted.

Honestly the database isn't half as useful as the tool they wrote to grab the metrics. At least I think telegraf was written by the same people? It seems to have the exact opposite design philosophy.

Yup, telegraf is what keeps me with InfluxDB, even if I couldn't care less about the database or the pain in the ass it is to operate.

VictoriaMetrics does claim to be compatible with the inline format, which makes me wonder if it is possible to keep using telegraf with it.

Re: CERN swaps out databases to feed its petabyte-a-day habit

#54
post #21

Earlier quoted context omitted.

1.8, migration path to 2.0 was a no-no. Don't remember exact reasons back then but we decided to have wait-and-see approach and see how alternatives grow up as our data generally grows in predictable rate Also frankly Prometheus support is a massive positive. For better or worse industry standarized on apps using Prometheus as ingest for metrics, and also most of the materials related to that will of course give exam…

The original comment mentioned Influx v3, which doesn't support Flux at all but uses standard SQL instead. Influx v2 still supported InfluxQL from v1, so Flux wasn't essential there either. Flux doesn't seem worth focusing on here. I've personally found InfluxDB more user-friendly than Prometheus for metrics work, since I've used both at scale and compared my own experiences. The industry leans towards Prometheus now…

AFAIK its not a serious issue for many users and companies who sucssesfuly migrated from prometheus/thanos/influxdb/opentsdb/graphite or even cortex to VictoriaMetrics stack. Think about it ;)

Re: CERN swaps out databases to feed its petabyte-a-day habit

#55
post #47

Earlier quoted context omitted.

Yup, telegraf is what keeps me with InfluxDB, even if I couldn't care less about the database or the pain in the ass it is to operate.

VictoriaMetrics does claim to be compatible with the inline format, which makes me wonder if it is possible to keep using telegraf with it.

You can.

I also use Telegraf with TimescaleDB.

Telegraf actually made interop with their competitors super easy

Re: CERN swaps out databases to feed its petabyte-a-day habit

#56
post #49
post #10

I really like VictoriaMetrics's architecture vmagent takes care of all the pesky edge things like emulating prometheus config parsing and various scraping bits. It also does buffering in case you lose network connection for a while, and accept vast spread of different protocols vminsert/vmselect scale separately from eachother and your queries don't bother your ingest all that much. vmstorage does just that, storage.…

Can you write alerting rules in Prometheus syntax also? And use with Prometheus alert manager?

Yes! Alerting and recording rules are supported by vmalert [0]. vmalert then integrates with alertmanager for sending alerts, and alertmanager then dispatches notifications. Besides this, vmalert has features of retro-active rules evaluation [1] (both alerting and recording) and detection of useless alerting rules [2].

[0] https://docs.victoriametrics.com/vmalert.html [1] https://docs.victoriametrics.com/vmalert.html#rules-backfill... [2] https://docs.victoriametrics.com/vmalert.html#never-firing-a...

Re: CERN swaps out databases to feed its petabyte-a-day habit

#57

I’m surprised nobody has mentioned grafana mimir yet. You get all the niceties of the prometheus ecosystem with a backend which can scale into the billions of metric streams.

Grafana Mimir is a great product, but it also has some rough edges - https://victoriametrics.com/blog/mimir-benchmark/
Post reply on HN