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.
CERN swaps out databases to feed its petabyte-a-day habit
51–57 of 57 posts
Re: CERN swaps out databases to feed its petabyte-a-day habit
#52Re: CERN swaps out databases to feed its petabyte-a-day habit
#53Re: CERN swaps out databases to feed its petabyte-a-day habit
#54Earlier 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…
Re: CERN swaps out databases to feed its petabyte-a-day habit
#55Earlier 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.
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
#56I 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?
[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
#57I’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.