Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Update on PromQL Compatibility Across Vendors

promlabs.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: An Update on PromQL Compatibility Across Vendors

#11

Post by valyala »

VictoriaMetrics CTO here.

These tests are great, because they spotted a few minor bugs in our PromQL implementation and these bugs were fixed quickly. See https://victoriametrics.github.io/CHANGELOG.html .

The majority of failed tests for VictoriaMetrics cannot be "fixed" due to deliberate choice made when designing MetricsQL: to rethink and to fix the most annoying and confusing parts of PromQL, while providing drop-in PromQL replacement for the majority of practical cases. See more details at https://victoriametrics.github.io/MetricsQL.html .

Re: An Update on PromQL Compatibility Across Vendors

#12

Post by valyala »

cevian wrote: post #9
EdwardDiego wrote: post #5

Earlier quoted context omitted.

Did you start with Victoria directly? Or move to it from Prometheus? Keen to hear your experiences. We're currently running Prometheus + Thanos, and high cardinality timeseries are a real issue, which Victoria claims to be good at.

(Promscale Team Lead Here) Promscale, which connects Prometheus to TimescaleDB also handles high-cardinality well and allows you to use both PromQL and SQL for data analysis. I'd humbly suggest taking a look. Plus our PromQL implementation is 100% standards compliant.

It would be great conducting a benchmark between Promscale and VictoriaMetrics similar to this one - https://valyala.medium.com/prometheus-vs-victoriametrics-ben... . It differs from TSBS in the following aspects:

* It is based on real-world data instead of synthetic data.

* It measures resources usage (RAM, CPU, disk IO, disk space) during production-like load instead of measuring peak performance under the maximum synthetic load.

Re: An Update on PromQL Compatibility Across Vendors

#14

Post by pointestimate »

valyala wrote: post #12
cevian wrote: post #9

Earlier quoted context omitted.

(Promscale Team Lead Here) Promscale, which connects Prometheus to TimescaleDB also handles high-cardinality well and allows you to use both PromQL and SQL for data analysis. I'd humbly suggest taking a look. Plus our PromQL implementation is 100% standards compliant.

It would be great conducting a benchmark between Promscale and VictoriaMetrics similar to this one - https://valyala.medium.com/prometheus-vs-victoriametrics-ben... . It differs from TSBS in the following aspects: * It is based on real-world data instead of synthetic data. * It measures resources usage (RAM, CPU, disk IO, disk space) during production-like load instead of measuring peak performance under the maximum…

I would love to have some kind of integration between Victoria Metrics and Promscale, using VM for ingest from things like InfluxDB and Promscale for SQL queries on stable data.

Re: An Update on PromQL Compatibility Across Vendors

#15

Post by valyala »

pointestimate wrote: post #14
valyala wrote: post #12

Earlier quoted context omitted.

It would be great conducting a benchmark between Promscale and VictoriaMetrics similar to this one - https://valyala.medium.com/prometheus-vs-victoriametrics-ben... . It differs from TSBS in the following aspects: * It is based on real-world data instead of synthetic data. * It measures resources usage (RAM, CPU, disk IO, disk space) during production-like load instead of measuring peak performance under the maximum…

I would love to have some kind of integration between Victoria Metrics and Promscale, using VM for ingest from things like InfluxDB and Promscale for SQL queries on stable data.

This should be already possible - just collect Influx line protocol data with vmagent [1] and write it to Promscale.

[1] https://victoriametrics.github.io/vmagent.html

Post reply on HN