5 ms·

It's not a drop-in replacement (even though it tries to sell itself as such), it's incompatible in a significant number of ways and throws away part of your dat

by jrv 6y ago

It's not a drop-in replacement (even though it tries to sell itself as such), it's incompatible in a significant number of ways and throws away part of your data.

SkyRocknRoll 6y ago
We use Victoria Metrics in Prod for more than 6 months. It is very reliable and scalable. Victoria metrics handles more than 2B+ series in our setup without breaking a sweat.
hagen1778 6y ago
VictoriaMetrics (VM) is incompatible with Prometheus only in things which seemed to be "wrong" or "not good enough" in original. There was a very very long discussion about rate/irate implementation in Prometheus long before VM existence, and VM just fixed that and a bunch of other things. And about "throws away part of your data" - let's be clear here. It is a precision loss while converting floating point numbers, not data dropping. Instead, user gets a superior compression and query performance which is a good trade off in my opinion. For those who are interested in details of comparison VM vs Prometheus pls read the following article https://valyala.medium.com/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87 https://valyala.medium.com/evaluating-performance-and-correc...
valyala 6y ago
VictoriaMetrics provides its own query lagnuage - MetricsQL. It is backwards compatible with PromQL with some exceptions. These exceptions are aimed towards solving practical issues experienced by users when working with PromQL. All these "incompatibilities" are well documented [1]. [1] https://victoriametrics.github.io/MetricsQL.html https://victoriametrics.github.io/MetricsQL.html
heliodor 6y ago
They made some pragmatic optimizations by dropping part of the data where it mostly doesn't matter. Who's actually affected by this? 0.01% of users?
pointestimate 6y ago
No, it's better. You can focus on the thing you're measuring rather than the bloody platform.

by jrv 6y ago

It's not a drop-in replacement (even though it tries to sell itself as such), it's incompatible in a significant number of ways and throws away part of your data.

SkyRocknRoll 6y ago

We use Victoria Metrics in Prod for more than 6 months. It is very reliable and scalable. Victoria metrics handles more than 2B+ series in our setup without breaking a sweat.

hagen1778 6y ago

VictoriaMetrics (VM) is incompatible with Prometheus only in things which seemed to be "wrong" or "not good enough" in original. There was a very very long discussion about rate/irate implementation in Prometheus long before VM existence, and VM just fixed that and a bunch of other things. And about "throws away part of your data" - let's be clear here. It is a precision loss while converting floating point numbers, not data dropping. Instead, user gets a superior compression and query performance which is a good trade off in my opinion. For those who are interested in details of comparison VM vs Prometheus pls read the following article https://valyala.medium.com/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87 https://valyala.medium.com/evaluating-performance-and-correc...

valyala 6y ago

VictoriaMetrics provides its own query lagnuage - MetricsQL. It is backwards compatible with PromQL with some exceptions. These exceptions are aimed towards solving practical issues experienced by users when working with PromQL. All these "incompatibilities" are well documented [1]. [1] https://victoriametrics.github.io/MetricsQL.html https://victoriametrics.github.io/MetricsQL.html

heliodor 6y ago

They made some pragmatic optimizations by dropping part of the data where it mostly doesn't matter. Who's actually affected by this? 0.01% of users?

pointestimate 6y ago

No, it's better. You can focus on the thing you're measuring rather than the bloody platform.