4 ms·

I really like VictoriaMetrics's architecture vmagent takes care of all the pesky edge things like emulating prometheus config parsing and various scraping bits

by ilyt 3y ago

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. Only thing that bothers me (compared to say, Elasticsearch), is that data can't migrate between nodes so you can't "just" start a new one and drain an old one, but a tiny bit ops work in rare cases is IMO price worth paying for straightforwardness of the stack.. PromQL compatibility is also great, tools like Grafana "just work" without anyone having to write support for it. We started migrating from InfluxDB at work, and on my private stuff I already did. Soo much less memory usage too.

theossuary 3y ago
What version of Influx were you running? I'm interested if v3 will be more competitive than v2.
- ilyt 3y ago
  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 examples in PromQL Flux is frankly hieroglyphs for people using it 20 minutes a month like our developers This is given example on how to raise value in Flux to power of two |> map(fn: (r) => ({ r with _value: r._value * r._value })) This is example of that in prometheus value ^ 2 This is example of calculating percentage in Flux (from their webpage) data |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> map( fn: (r) => ({ _time: r._time, _field: "used_percent", _value: float(v: r.used) / float(v: r.total) * 100.0, }), ) This is how you do it in PromQL space_used / space_total * 100 Flux is atrocious for "normal users".
  - everforward 3y ago
    Flux looks like it has the opposite design philosophy of PromQL: it makes simple things harder and hard things simpler. I probably wouldn't default to it, but I've had to solve some issues that were complicated in PromQL that would probably be easier here. E.g. I had to work on a Prometheus monitoring/alerting setup where metrics were all recorded in UTC, but alerts should only fire during local business hours. We ended up with something like a thousand character PromQL query that was utterly illegible (have pity on whatever poor soul has to update it when DST goes away). Flux looks like it would have a more legible solution to that, though at the cost of making simple analysis way more complicated than it probably needs to be.
  - coder543 3y ago
    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 nowadays, so I'm used to dealing with Prometheus, but I've found PromQL particularly unpleasant for any kind of complex aggregations. You may disagree, and that's okay. Regular SQL seems far nicer to me in comparison, so it's nice to see Influx v3 focusing on that. I wish Prometheus and VM would develop a standard SQL interface. VictoriaMetrics doesn't fully support PromQL either; its MetricsQL is only about 73% compatible according to this article[0] that the VM docs link to. I certainly hope that VM took this incompatibility and used it as an opportunity to make MetricsQL more enjoyable to use than PromQL. [0]: https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e https://medium.com/@romanhavronenko/victoriametrics-promql-c...
    - dengolius 3y ago
      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 ;)
  - Too 3y ago
Too 3y ago
Can you write alerting rules in Prometheus syntax also? And use with Prometheus alert manager?
- hagen1778 3y ago
  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 https://docs.victoriametrics.com/vmalert.html [1] https://docs.victoriametrics.com/vmalert.html#rules-backfilling https://docs.victoriametrics.com/vmalert.html#rules-backfill... [2] https://docs.victoriametrics.com/vmalert.html#never-firing-alerts https://docs.victoriametrics.com/vmalert.html#never-firing-a...

by ilyt 3y ago

theossuary 3y ago

What version of Influx were you running? I'm interested if v3 will be more competitive than v2.

ilyt 3y ago
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 examples in PromQL Flux is frankly hieroglyphs for people using it 20 minutes a month like our developers This is given example on how to raise value in Flux to power of two |> map(fn: (r) => ({ r with _value: r._value * r._value })) This is example of that in prometheus value ^ 2 This is example of calculating percentage in Flux (from their webpage) data |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> map( fn: (r) => ({ _time: r._time, _field: "used_percent", _value: float(v: r.used) / float(v: r.total) * 100.0, }), ) This is how you do it in PromQL space_used / space_total * 100 Flux is atrocious for "normal users".
- everforward 3y ago
  Flux looks like it has the opposite design philosophy of PromQL: it makes simple things harder and hard things simpler. I probably wouldn't default to it, but I've had to solve some issues that were complicated in PromQL that would probably be easier here. E.g. I had to work on a Prometheus monitoring/alerting setup where metrics were all recorded in UTC, but alerts should only fire during local business hours. We ended up with something like a thousand character PromQL query that was utterly illegible (have pity on whatever poor soul has to update it when DST goes away). Flux looks like it would have a more legible solution to that, though at the cost of making simple analysis way more complicated than it probably needs to be.
- coder543 3y ago
  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 nowadays, so I'm used to dealing with Prometheus, but I've found PromQL particularly unpleasant for any kind of complex aggregations. You may disagree, and that's okay. Regular SQL seems far nicer to me in comparison, so it's nice to see Influx v3 focusing on that. I wish Prometheus and VM would develop a standard SQL interface. VictoriaMetrics doesn't fully support PromQL either; its MetricsQL is only about 73% compatible according to this article[0] that the VM docs link to. I certainly hope that VM took this incompatibility and used it as an opportunity to make MetricsQL more enjoyable to use than PromQL. [0]: https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e https://medium.com/@romanhavronenko/victoriametrics-promql-c...
  - dengolius 3y ago
    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 ;)
- Too 3y ago

Too 3y ago

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

hagen1778 3y ago
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 https://docs.victoriametrics.com/vmalert.html [1] https://docs.victoriametrics.com/vmalert.html#rules-backfilling https://docs.victoriametrics.com/vmalert.html#rules-backfill... [2] https://docs.victoriametrics.com/vmalert.html#never-firing-alerts https://docs.victoriametrics.com/vmalert.html#never-firing-a...