Sumo Logic alternatives that are not Datadog or Grafana?

Everyone always overlooks the self-hosted route until the bills hit. You mentioned avoiding things that are "too hands-on," but rolling your own can be way more predictable cost-wise, if you've got the capacity.

New Relic, Logz.io, Humio... you're just picking a different flavor of the same VC-funded, usage-metered model. They'll all find a way to nickel and dime you on ingest or retention. Have you considered the Graylog open-source version? Stick it on a beefy VM or a k8s cluster you control. The initial setup is a weekend, sure, but then your only real variable is storage cost. Alerting and dashboards are solid, and you'll never get a surprise invoice because someone left debug logging on.

Also, 100 GB/day is the sweet spot where cloud providers start to see dollar signs. Do the math on your own object storage backend for logs versus what any of those services quote you. The delta might fund a part-time sysadmin.

Yeah, that's a really good point about the self-hosted route being predictable. I've helped set up Graylog for a few smaller teams, and once it's running, the cost stability is a huge relief.

But that line about "if you've got the capacity" is the real catch, isn't it? Not every place has a spare weekend of engineering time to dedicate to setup and ongoing care, even if the long-term math works out. It's a tough trade-off.

New Relic's "reasonable" pricing vanishes the second you need log retention over a week. Splunk Cloud's new tiers are just clever bundling, you'll still get gouged on data egress.

Logz.io and Humio are the same SaaS hamster wheel you're trying to escape. The math never works at 100 GB/day unless you're a startup burning VC cash.

Forget vendor whispers. Look at Chronosphere or Coralogix if you must stay hosted. They at least try different pricing angles.

You're spot on about the capacity trade-off. It's like the classic CRM debate - a self-hosted Odoo install gives you total control and predictable cost, but you're now in the software maintenance business.

I've seen teams commit to the Graylog path, only to realize their "spare weekend" turns into a part-time sysadmin role for someone. That's an ongoing labor cost that never shows up on the vendor invoice, but it's very real.

Makes you wonder if the real middle ground is a managed service with a truly flat fee, not usage-based. Those are just painfully hard to find in observability.

New Relic's pricing for logs at that volume will shock you. It's easy to migrate into, but the meter runs fast. Splunk Cloud's newer tiers are indeed more competitive than their old model, but they're still fundamentally priced on ingest, which is exactly what you're trying to avoid.

Logz.io and Humio fit your feature list well, but you're just swapping one usage-based model for another. The predictability might be a little better month-to-month, but the cost trajectory as you scale is the same curve.

Have you looked at Elastic Cloud? You get the full ELK stack as a service, and their pricing offers a compute+storage model separate from ingest. It can be more predictable for a stable data shape. Alerting and dashboards are top-tier. The migration effort from Sumo would be similar to moving to any other platform - you're reconfiguring your forwarders and dashboards regardless.

Oh, that's a great callout about Elastic Cloud. I was actually just reading about their pricing model being separate for compute and storage. It sounds like it could be way more predictable if your data volume is steady, like you said.

But I'm a bit new to this side of things, so maybe you can clarify. When people say the migration effort is similar to any platform, does that mean the real work is in rebuilding all your dashboards and alert rules, no matter where you go? That seems like the hidden cost that's easy to underestimate.

Exactly. The "spare weekend" is the biggest lie we tell ourselves in tech. It's never just the setup. It's the quarterly upgrades, the security patches, the storage alerts at 3 AM when the retention policy glitches.

I've seen teams budget for the VM cost and call it a win, only to burn 50k a year in lost engineering productivity babysitting the thing. That labor cost makes even pricey SaaS look reasonable.

The real question is whether your team's core business is running software or selling products. If it's the latter, that sysadmin tax is a brutal distraction.

Your question about migration effort cuts to the core of the evaluation. The dashboard and alert rebuild is indeed the universal hidden cost, but the data pipeline itself is the variable that matters for latency and maintenance.

You can templatize dashboards, but you cannot templatize the parsing, enrichment, and indexing logic. Sumo's query language and field extraction rules don't translate 1:1 to any other platform. A move to Elastic Cloud means reworking ingest pipelines, possibly with Logstash or vector.dev. A move to something like Coralogix means adapting to their schema-on-write approach. That pipeline work, not the dashboards, is where the real engineering weeks hide. For 100 GB/day, a misconfigured parser becomes a performance and cost liability almost immediately.

Have you considered running a dual-write POC for a week? Sending a sample subset to a finalist candidate while keeping Sumo live. You'll get hard data on ingestion quirks and query performance for your specific log shapes, which is the only way to accurately forecast the migration timeline.

Elastic Cloud is a solid suggestion from user264, especially if you can nail down a stable data shape. I've helped migrate a Salesforce integration pipeline from Sumo to Elastic Cloud, and the predictable compute+storage model did simplify budgeting.

But you're right about the hidden migration work. Rebuilding dashboards is one thing, but the real time-sink is translating your Sumo queries and field extractions into Elastic's query DSL and ingest pipelines. For an e-commerce stack, your cart abandonment or checkout error alerts are probably tied to specific log patterns - those parsing rules need a careful rewrite.

Have you checked the ingestion methods each platform supports? That's another piece of the puzzle. If your current setup uses Sumo Collectors, you'll need to swap those out for something like Filebeat or OpenTelemetry, which can add a layer of config work across your servers.

Elastic's "predictable" compute+storage model is just locking you into their estimates. Their cost calculator is an aspirational fiction until you run the workload for a month. And good luck with a "stable data shape" when a new service deployment inevitably changes your log schema.

> swapping those out for something like Filebeat or OpenTelemetry

And now you're managing an agent fleet instead of a collector. Another layer, another config drift problem. You've traded one vendor's black box for your own homegrown ops burden. The labor cost you're trying to avoid just got shifted, not eliminated.

The hidden labor tax around parsing and pipeline rework is the most critical point, and I think it gets underestimated because teams benchmark dashboards, not data transformation. You've listed Logz.io and Humio, which are essentially hosted wrappers around Elastic and their own engine respectively. That puts you right back in the parsing rule rewrite trap user112 mentioned.

For a mid-market e-commerce stack at 100 GB/day, I'd suggest a two-step evaluation. First, take a representative slice of your logs, maybe 10 GB, and actually write the ingest pipelines and parsing rules for a target platform on a free trial. That exercise will expose the true migration weeks. Second, if predictable cost is the primary driver, look at Coralogix's tiered storage model or Chronosphere's metric-focused pricing. They're structurally different from ingest-based models and can offer more predictability if your query patterns are well-defined. New Relic and Splunk Cloud will still punish you on volume, just with different levers.

Coralogix's tiered storage and Chronosphere's metric-first approach are indeed different angles, but they're still angles designed to make their unit economics work, not yours. They just move the cost from ingest to another dimension you'll eventually scale into.

The real question no one's asking about Chronosphere: when you inevitably need logs alongside those metrics, what's their log pricing model? I've yet to see a vendor that's truly innovative on one front not to have a conventional, punitive model on the other.

Great thread, lots of good points on hidden costs. On your question about real-world costs for ~100GB/day, I've seen Logz.io come in around 20-30% less than Sumo for that range, but the parsing rule rework was a solid two-week project. Their support was helpful though.

New Relic could surprise you on logs - their newer data plus pricing might be worth a quick quote if you're already using them for APM. But the lock-in is real. Honestly, for an e-commerce stack, the dashboard rebuild for your key user journeys is the non-negotiable time investment no matter what you pick.

>the parsing rule rework was a solid two-week project.

This is what I'm scared of. Two weeks is a lot of lost time when you're just trying to get to the same baseline. Is that two weeks for one engineer, or a whole team?