VictoriaMetrics Support (VMRule)

[kaitimmer]

This PR enables the capability of setting --victoria-metrics-mode=true so that pyrra generates VMRules instead of PrometheusRules or ConfigMaps.

As far as I know, VictoriaMetrics understands the same query language as Prometheus, so I use the same rule generation logic and just change the metadata so that VictoriaMetrics understands them.

[metalmatze]

Thanks!
This great!

It needs rebase.

As far as I know, VictoriaMetrics understands the same query language as Prometheus, so I use the same rule generation logic and just change the metadata so that VictoriaMetrics understands them.

Did you actually try the generated rules with VictoriaMetrics? It would be great to do that.
Additionally, if we accept this into Pyrra, it would be great to have a small testing stack available to spin up VictoricaMetrics and test new features, bug etc against with.
Something along the lines of https://github.com/pyrra-dev/pyrra/tree/main/examples/openshift, https://github.com/pyrra-dev/pyrra/tree/main/examples/mimir or https://github.com/pyrra-dev/pyrra/tree/main/examples/docker-compose. Thanks!

[kaitimmer]

Did you actually try the generated rules with VictoriaMetrics? It would be great to do that.

Yes, I did, and it worked fine.

The VictoriaMetrics Docs state:
https://docs.victoriametrics.com/victoriametrics/metricsql/

MetricsQL is backwards-compatible with PromQL, so Grafana dashboards backed by Prometheus datasource should work the same after switching from Prometheus to VictoriaMetrics. However, there are some intentional differences between these two languages.

Additionally, if we accept this into Pyrra, it would be great to have a small testing stack available to spin up VictoricaMetrics and test new features, bug etc against with. Something along the lines of main/examples/openshift, main/examples/mimir or main/examples/docker-compose. Thanks!

I'll look into it!

[kaitimmer]

When running Pyrra with VictoriaMetrics, we saw bizarre behaviour in the generic rules. This seems to be related to the recording rule chaining and to this issue. Adding the eval_offset fixed the metrics for us.

However, I'm a bit unsure about doing the -generic string comparison, but I could also not think of a better and still easy way to handle this.

This should not be needed for the other groups, as they do not depend on each other.