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

1–10 of 15 posts

Re: An Update on PromQL Compatibility Across Vendors

#3

Post by jrv »

benraskin92 wrote: post #2

This is great -- thanks for putting it together! Will these be kept up-to-date? If so, what will the cadence be?

Hi! On the road right now, but back later :) There's no established cadence yet, but twice a year or so sounds like a reasonable update period to me.

Re: An Update on PromQL Compatibility Across Vendors

#5

Post by EdwardDiego »

shitloadofbooks wrote: post #4

Out of all the projects/products on this list, we've found Victoria Metrics to be by _far_ the best. This summary makes it seem like Victoria Metrics is barely compatible with Prometheus, but that can't be further from the truth in practice.

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.

Re: An Update on PromQL Compatibility Across Vendors

#7

Post by harkishen »

EdwardDiego wrote: post #5
shitloadofbooks wrote: post #4

Out of all the projects/products on this list, we've found Victoria Metrics to be by _far_ the best. This summary makes it seem like Victoria Metrics is barely compatible with Prometheus, but that can't be further from the truth in practice.

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.

High cardinality on Promscale is very efficient. I have been testing prom-migrator, migrating and ingesting 7 million+ samples a second, and till now, I have seen Promscale's memory usage to be the most efficient, along with a better CPU performance. I have tested Promscale, VictoriaMetrics, Thanos, M3, Cortex, and Promscale continues to lead in efficiency and performance. Also, the added advantage of native SQL support is a big bonus.

Re: An Update on PromQL Compatibility Across Vendors

#8

Post by shitloadofbooks »

EdwardDiego wrote: post #5
shitloadofbooks wrote: post #4

Out of all the projects/products on this list, we've found Victoria Metrics to be by _far_ the best. This summary makes it seem like Victoria Metrics is barely compatible with Prometheus, but that can't be further from the truth in practice.

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.

We went from Prometheus (bursting at the seams and begging to be scaled) -> a failed Cortex implementation -> a rock solid Victoria Metrics implementation.

We found Cortex to be extremely over-engineered, extremely hard to tune (because of multiple configuration/argument refactors with incomplete doc cleanups) and found that it would just fall over under load. (Though to be fair, there wasn't much in the way of first-party deployment tooling at the time, so it was a hand-rolled Helm chart and at least 50% of the issues were likely my config).

In comparison, the first-party Victoria Metrics Helm chart worked straight out of the box, the maintainers have fixed multiple small issues within hours of me reporting them and we've thrown an extremely large amount of metrics at it with zero problems.

Re: An Update on PromQL Compatibility Across Vendors

#9

Post by cevian »

EdwardDiego wrote: post #5
shitloadofbooks wrote: post #4

Out of all the projects/products on this list, we've found Victoria Metrics to be by _far_ the best. This summary makes it seem like Victoria Metrics is barely compatible with Prometheus, but that can't be further from the truth in practice.

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.

Re: An Update on PromQL Compatibility Across Vendors

#10

Post by PeterZaitsev »

shitloadofbooks wrote: post #4

Out of all the projects/products on this list, we've found Victoria Metrics to be by _far_ the best. This summary makes it seem like Victoria Metrics is barely compatible with Prometheus, but that can't be further from the truth in practice.

This is what is the problem with such compatibility tests... they tend to test full power of the language while you really may use quite small subset in your application, as such even solution which is "20% compatible" may well meet all your application needs.

I remember in its early days MySQL had pretty poor SQL support (if you think about full standard) which did not prevent it from having huge success.

Or more recent example ClickHouse which I think similar to VictoriaMetrics as it does not fully implement SQL, but also adds many convenient extensions which are not part of the standard.

Chances are if you chose VictoriaMetrics you will find a lot more utility in advanced features of MetricsQL than you loose from exact compatibility with PromQL

Post reply on HN