4 ms·

Well, they claim superior performance (which might be true), but the costs are high and include a small community, low quality APIs, best effort correctness/Pro

by uaas 2y ago

Well, they claim superior performance (which might be true), but the costs are high and include a small community, low quality APIs, best effort correctness/PromQL compatibility, and FUD marketing, so I decided to go with the de-facto standard without all of the issues above.

YZF 2y ago
No costs if you're hosting everything. It does scale better and has better performance. Used it and have nothing bad to say about it. For the most part a drop-in replacement that just performs better. Didn't run into PromQL compatibility issues with off-the-shelf Grafana dashboards.
valyala 2y ago
Could you provide more details regarding low quality APIs and PromQL compatibility issues? The following article explains "issues" with PromQL compatibility in VictoriaMetrics - https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e https://medium.com/@romanhavronenko/victoriametrics-promql-c... . See also https://docs.victoriametrics.com/metricsql/ https://docs.victoriametrics.com/metricsql/ . TL;DR: MetricsQL fixes PromQL issues with rate() and increase() functions. That's why it is "incompatible" with PromQL. Could you provide examples of FUD marketing from VictoriaMetrics?
- uaas 2y ago
  I am on mobile, so cannot really link GitHub for examples, but I'd recommend anyone considering using VM over Prometheus to take a cursory look into how similar things are implemented in both projects, and what shortcuts were made in the name of getting "better performance". Performance-wise e.g. VictoriaMetrics' prometheus-benchmark only covered instant queries without look back for example the last time I checked. Regarding FUD marketing: All Prometheus community channels (mailing lists, StackOverflow, Reddit, GitHub, etc.) are full of VM devs pushing VM, bashing everything from the ecosystem without mentioning any of the tradeoffs. I am also not aware of VictoriaMetrics giving back anything to the Prometheus ecosystem (can you maybe link some examples if I am wrong?) which is a very similar to Microsoft's embrace, extend, and extinguish strategy. As per recent actual examples, here's a 2 submission of the same post bashing project in the ecosystem: https://news.ycombinator.com/item?id=40838531 https://news.ycombinator.com/item?id=40838531, https://news.ycombinator.com/item?id=39391208 https://news.ycombinator.com/item?id=39391208, but it's really hard to avoid all the rest in the places mentioned above.
  - valyala 2y ago
    > Performance-wise e.g. VictoriaMetrics' prometheus-benchmark only covered instant queries without look back for example the last time I checked. prometheus-benchmark ( https://github.com/VictoriaMetrics/prometheus-benchmark https://github.com/VictoriaMetrics/prometheus-benchmark ) tests CPU usage, RAM usage and disk usage for typical alerting queries. It doesn't test the performance of queries used for building graphs in Grafana because the typical rate of alerting queries is multiple orders of magnitude bigger than the typical rate of queries for building graphs, e.g. alerting queries generate the most of load on CPU, RAM and disk IO in typical production workload. Please file a feature request at https://github.com/VictoriaMetrics/prometheus-benchmark/issues/new https://github.com/VictoriaMetrics/prometheus-benchmark/issu... to add the ability to test resource usage for typical queries for building Grafana graphs if you think this will be a good feature. > I am also not aware of VictoriaMetrics giving back anything to the Prometheus ecosystem (can you maybe link some examples if I am wrong?) Sure: - https://github.com/prometheus/prometheus/issues?q=author%3Avalyala https://github.com/prometheus/prometheus/issues?q=author%3Av... - https://github.com/prometheus/prometheus/issues?q=author%3Aloori-r https://github.com/prometheus/prometheus/issues?q=author%3Al... - https://github.com/prometheus/prometheus/issues?q=author%3Ahagen1778 https://github.com/prometheus/prometheus/issues?q=author%3Ah... > As per recent actual examples, here's a 2 submission of the same post bashing project in the ecosystem: https://news.ycombinator.com/item?id=40838531 https://news.ycombinator.com/item?id=40838531 This submission posts a link to the real-world experience of long-term user of Grafana Loki. This user points to various issues in applications he uses. For example: - Issues with Loki restarts - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiStartupWALReplayIssue https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with structured metadata in Loki 3.0 - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiStructuredMetadata https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with single-node Loki setup - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiSimpleNotRecommended https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with Loki logcli command - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiLogcliNotes https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with Grafana Loki data compaction - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiNoChunkCompaction https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Comparison of Grafana Loki vs traditional syslog server - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiAndCentralSyslogs https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... As you can see, this user shares his extensive experience with Grafana Loki, and continues using it despite the fact that there is much better solution exists, which is free from all the Loki issues - VictoriaLogs. This user isn't affiliated with VictoriaMetrics in any way.

by uaas 2y ago

YZF 2y ago

No costs if you're hosting everything. It does scale better and has better performance. Used it and have nothing bad to say about it. For the most part a drop-in replacement that just performs better. Didn't run into PromQL compatibility issues with off-the-shelf Grafana dashboards.

valyala 2y ago

Could you provide more details regarding low quality APIs and PromQL compatibility issues? The following article explains "issues" with PromQL compatibility in VictoriaMetrics - https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e https://medium.com/@romanhavronenko/victoriametrics-promql-c... . See also https://docs.victoriametrics.com/metricsql/ https://docs.victoriametrics.com/metricsql/ . TL;DR: MetricsQL fixes PromQL issues with rate() and increase() functions. That's why it is "incompatible" with PromQL. Could you provide examples of FUD marketing from VictoriaMetrics?

uaas 2y ago
I am on mobile, so cannot really link GitHub for examples, but I'd recommend anyone considering using VM over Prometheus to take a cursory look into how similar things are implemented in both projects, and what shortcuts were made in the name of getting "better performance". Performance-wise e.g. VictoriaMetrics' prometheus-benchmark only covered instant queries without look back for example the last time I checked. Regarding FUD marketing: All Prometheus community channels (mailing lists, StackOverflow, Reddit, GitHub, etc.) are full of VM devs pushing VM, bashing everything from the ecosystem without mentioning any of the tradeoffs. I am also not aware of VictoriaMetrics giving back anything to the Prometheus ecosystem (can you maybe link some examples if I am wrong?) which is a very similar to Microsoft's embrace, extend, and extinguish strategy. As per recent actual examples, here's a 2 submission of the same post bashing project in the ecosystem: https://news.ycombinator.com/item?id=40838531 https://news.ycombinator.com/item?id=40838531, https://news.ycombinator.com/item?id=39391208 https://news.ycombinator.com/item?id=39391208, but it's really hard to avoid all the rest in the places mentioned above.
- valyala 2y ago
  > Performance-wise e.g. VictoriaMetrics' prometheus-benchmark only covered instant queries without look back for example the last time I checked. prometheus-benchmark ( https://github.com/VictoriaMetrics/prometheus-benchmark https://github.com/VictoriaMetrics/prometheus-benchmark ) tests CPU usage, RAM usage and disk usage for typical alerting queries. It doesn't test the performance of queries used for building graphs in Grafana because the typical rate of alerting queries is multiple orders of magnitude bigger than the typical rate of queries for building graphs, e.g. alerting queries generate the most of load on CPU, RAM and disk IO in typical production workload. Please file a feature request at https://github.com/VictoriaMetrics/prometheus-benchmark/issues/new https://github.com/VictoriaMetrics/prometheus-benchmark/issu... to add the ability to test resource usage for typical queries for building Grafana graphs if you think this will be a good feature. > I am also not aware of VictoriaMetrics giving back anything to the Prometheus ecosystem (can you maybe link some examples if I am wrong?) Sure: - https://github.com/prometheus/prometheus/issues?q=author%3Avalyala https://github.com/prometheus/prometheus/issues?q=author%3Av... - https://github.com/prometheus/prometheus/issues?q=author%3Aloori-r https://github.com/prometheus/prometheus/issues?q=author%3Al... - https://github.com/prometheus/prometheus/issues?q=author%3Ahagen1778 https://github.com/prometheus/prometheus/issues?q=author%3Ah... > As per recent actual examples, here's a 2 submission of the same post bashing project in the ecosystem: https://news.ycombinator.com/item?id=40838531 https://news.ycombinator.com/item?id=40838531 This submission posts a link to the real-world experience of long-term user of Grafana Loki. This user points to various issues in applications he uses. For example: - Issues with Loki restarts - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiStartupWALReplayIssue https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with structured metadata in Loki 3.0 - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiStructuredMetadata https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with single-node Loki setup - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiSimpleNotRecommended https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with Loki logcli command - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiLogcliNotes https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Issues with Grafana Loki data compaction - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiNoChunkCompaction https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... - Comparison of Grafana Loki vs traditional syslog server - https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiAndCentralSyslogs https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLok... As you can see, this user shares his extensive experience with Grafana Loki, and continues using it despite the fact that there is much better solution exists, which is free from all the Loki issues - VictoriaLogs. This user isn't affiliated with VictoriaMetrics in any way.