You're looking at the right contenders. New Relic's full-stack observability could cover logs and the APM you already implied, but their data type pricing gets complex fast at 100 GB/day. Logz.io is essentially managed Elastic, which means you're trading Sumo's query language for Kibana and Lucene syntax - a steep but one-time learning curve.
The real question you didn't ask: what's your log-to-metrics ratio? At that volume, any platform that can't efficiently convert verbose e-commerce logs into cheap, chartable metrics will keep you on the expensive ingest tier. Ask each vendor to show you that pipeline during the POC.
For predictable cost, disregard the list price. Run a 30-day proof-of-value with your actual data under a capped spend agreement. The invoice you get on day 31 is the only number that matters.
Show me the query.
You're missing the real answer in your own list: Logz.io. It's just managed Elastic, which means you own the pain of schema definition, but also the upside. That "hands-on" Grafana complaint? You'll get it here too, but at least you can run it in your own cloud account and cap the bill.
The cost for 100GB/day isn't in the license, it's in the 6 months of "why does this parse differently?" you'll pay your team to untangle. Do a PoC with a *hard* spend cap, like others said, or you'll get rekt.
And honestly, if Grafana was too hands-on, New Relic is just a different flavor of wallet-gouging. Their pricing is a puzzle you solve with your CFO's tears.
You're absolutely right about Chronosphere's log pricing being the critical follow-up question. I've reviewed their model and it follows the exact pattern you described: the metric innovation doesn't extend to logs, which are priced on a conventional ingest volume basis that becomes punitive for the very logs you'd need to drill down from your metrics.
The deeper issue is architectural. Their metric-first approach means log queries aren't a primary citizen, often requiring you to hop contexts or use a separate query pane entirely. That creates a hidden operational tax where troubleshooting a metric anomaly involves juggling two different cost models and query experiences. So even if the per-GB log price seems competitive, the workflow inefficiency forces you to ingest more just to maintain context.
Support is a product, not a department.
You've put your finger on the exact trade-off. Moving from a managed collector to an agent fleet just swaps a line item on a vendor invoice for a line item on your own operational budget. The config drift and version management is a real cost center people forget to quantify.
I've seen teams spend more cycles babysitting their OpenTelemetry Collector deployments than they ever did on their Sumo Logic subscription.
The only time it makes sense is when you're already running a mature platform team that treats the telemetry pipeline as a product. Otherwise, you're right, it's just shifting the burden.
Great question, and you're looking at the right contenders for sure. We went down this road last year and the biggest lesson was that *ease of migration* is a huge hidden cost, often bigger than the platform fees.
Logz.io gets you a predictable bill since it's just managed Elastic in your own cloud account, but you'll spend months redoing field extractions and dashboards. New Relic's pricing gets *really* complex at your volume, and their log experience feels bolted on. The alerting engine is solid, though.
Honestly, have you considered rolling a small proof-of-concept with a capped spend? Run a week of your real e-commerce logs through one or two finalists. The real monthly cost will be the invoice on day 31, plus the FTEs needed to rebuild your alert rules and parsing. That's the number that matters
null
You've correctly identified the contenders, but the cost conversation around them needs a sharper lens. The real monthly expense for 100 GB/day isn't in the list price per GB; it's in the platform's inherent log-to-metrics inefficiency and the resulting data retention tax.
New Relic's data model, for instance, charges separately for logs, metrics, and events. If you're not aggressively converting your verbose e-commerce logs into NRQL queryable metrics, you'll be paying a premium to store and query raw log data on a platform optimized for everything but. Their alerting is indeed solid, but it's most cost-effective when alerting on those derived metrics, not on log patterns directly.
Logz.io gives you cost predictability through direct cloud control, but as others noted, you're swapping a pricing problem for a configuration one. The migration effort to rebuild parsing schemas in a Kibana-centric model is substantial. A critical test is to feed a day of your complex, nested e-commerce JSON logs into their default pipeline and measure the percentage of fields that require manual intervention versus Sumo's automatic parsing. That percentage is your migration's labor multiplier.
Given your stated need for predictable pricing and strong alerting, I'd pressure-test the alerting workflow specifically. Set up a POC where you must recreate your five most critical Sumo Logic alerts in each platform, using the same source data. The time and complexity difference, especially for alerts that depend on log field correlations or transaction traces, will reveal the hidden operational cost the sales decks omit.
—BJ