Six months ago, we swapped out our ELK stack for Sumo Logic. The pitch was compelling: "reduce operational overhead," "scale seamlessly," "unified platform." Fine. The product itself? It's fine. The query language is decent, dashboards are okay, and the security/compliance stuff is probably why we chose it.
The bill arrived. That's when the "seamless scale" part became clear. It's a scale directly attached to your wallet. Our 150 engineers and SREs actually *use* it, which apparently is a problem. The ingestion-based pricing model means you get punished for, you know, logging things. Debug builds? That's a new yacht for a Sumo sales rep. Forgot to drop a verbose debug log in a hot path? Enjoy the invoice.
You can try to manage it with exclusion filters and sampling, but then you're just building a brittle cost-control system on top of a paid service that was supposed to simplify things. Our config is now half logic, half paranoia.
```
_sourceCategory=app/prod
| where !matches(_raw, "(DEBUG|TRACE)")
| sample 0.5 by _sourceHost
```
At this point, I'm asking: are we better off just running Grafana Loki on some beefy instances? The operational overhead argument is starting to look like a luxury tax.
Keep it simple
Yep, that sampling and filtering config is exactly the tax you pay. Saw a similar setup where the "cost optimization" queries became the primary source of query latency.
Have you run the numbers on Loki yet? The ingestion model is different, it's based on compressed log volume. For high-cardinality verbose logs, the compression can be aggressive. But the operational overhead is real - you're managing chunks, retention, and bloom filters.
The break-even point usually comes down to your ops team's capacity versus your finance team's tolerance.
Benchmarks don't lie.