Hacker News Reader

Comment by ilyt | Hacker News Reader

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.

View on HN

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

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".

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.

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-c...

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 ;)

Flux is noisy yes. But promql isn’t exactly the pinnacle of query languages either. Simple stuff is simple, but once you start having more complex queries like sum by/without, it makes absolutely no sense where the parenthesis go and you can place some of the operators on either side of the inner expression.

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...

Reply on news.ycombinator.com