Why Grammarly chose the VictoriaMetrics stack from a large list of modern products for monitoring and observability

> Our proof-of-concept trial showed dramatically reduced compute and storage costs, translating into a 10x lower AWS bill

VictoriaMetrics + VictoriaLogs as prometheus + loki replacement, best choice

As one of the maintainers of go-graphite stack, I'd really like to know more about what didn't work for Gramnarly. Based on values they've provided I can deduce that it was carbonapi + go-carbon, though I wonder if they've considered migrating to graphite-clickhouse. I understand that now it is too late, but maybe more details would help to fix same problem for other people.

P.S. It is also nice to see that feature that I've added long time ago just to have simpler dev setup for myself (vm-backend support) is actually used by people, even though it required few fixes :) (or to be precise - used at least at some point, it is not very clear if they've migrated to built-in one)

As I know, Grammarly migrated to Graphite implementation built into VictoriaMetrics [1]

[1] https://docs.victoriametrics.com/#graphite-api-usage

I use VictoriaMetrics as remoteWrite for prometheus. It is popular.

moved all my monitoring system to VM + VMLogs instead of ELK and loki. Boss said "thanks" cos I saved a lot of money. High performance with low resource usage.