Just saw the announcement about Sumo Logic shifting from per-GB pricing to these new "Capacity Units" (CUs). As someone who's been using it for a few months to monitor some cloud apps, my first reaction was... confusion 😅. The per-GB model was straightforward, even if it could get pricey with spikes.
Has anyone dug into the practical impact yet? I'm trying to map my current usage—a mix of logs, metrics, and a bit of tracing—to these new CUs. The docs say it's based on "analyzed data," not just ingested volume, which seems to reward filtering and parsing at ingestion. My worry is that complex queries or dashboard refreshes might now have a more direct cost implication.
I set up a quick test to compare. With the old model, a noisy debug log blast was the main cost driver. Now, I'm wondering if I need to be more careful with my scheduled searches and alert queries. Anyone already tweaking their ingestion parsing or dashboard habits because of this?
```xml
# Example of a more aggressive pre-parse filter I'm testing
_sourceCategory=app/prod
| where !(log matches /DEBUG/)
| parse " * " as logLine
```
Is moving to CUs going to push us all to become experts at data minimization upfront, or is it roughly a wash for most workloads? Curious about your early calculations and any gotchas you've found.
It's not about becoming experts at data minimization, it's about becoming experts at predicting an opaque pricing model. That's the vendor's goal.
You're right to worry about queries and dashboards. With the old model, once you paid for the data it was in the lake. Now, every time someone opens a dashboard or runs an ad-hoc search, you're on the hook. It turns casual exploration by your team into a direct cost center.
Your filter is a good start, but wait until you get your first bill. The mapping from 'analyzed data' back to your actual activity is rarely clear. They're banking on that confusion.
Exactly. The goal is shifting the risk of unpredictable usage from their platform to your budget. It's a classic move from a mature vendor.
With the old model, a spike in logs was your problem. Now, a curious intern running broad queries becomes your CFO's problem. The invoice won't say "dashboard refresh by marketing," it'll just be a larger, unexplained CU charge.
They've turned your team's curiosity into a line item.
always check the last 6 months of reviews
Totally agree on the mapping being unclear. The real issue I've seen in early tests is that "analyzed data" isn't just about *what* you query, but *how* it's stored. A single parsed field from a log line, if it's a high cardinality value, can generate a surprising amount of "analyzed" data compared to a simple timestamp. The bill gives you a single number, but the work to reverse engineer it is now a new job for someone on the team.
It shifts the monitoring conversation from "are we collecting the right data?" to "did anyone run a new report this month?" That's a subtle but powerful change in team behavior.
I'm curious if anyone has found a reliable way to audit CU consumption per dashboard or user yet. Without that, you're flying blind.
Spreadsheets > marketing slides.
Your test with the filter is the right instinct, but you're focusing on the wrong layer. The shift to "analyzed data" fundamentally changes the cost calculus from infrastructure to application logic.
Your old cost driver was volume, a factor of your application's verbosity and scaling events. Now, your primary cost driver is *cardinality*. A single log line with a high-cardinality field like `transaction_id` or `user_id` that gets parsed and subsequently queried will generate far more analyzed data than your filtered-out DEBUG lines ever did. That pre-parse filter helps, but it's like saving on fuel while ignoring tire wear. You need to instrument your queries and understand the data shape you're analyzing.
The practical impact is that you must now treat your observability platform like a database, which it always was, but now the cost model exposes it. Scheduled searches and dashboard refreshes over high-cardinality dimensions are the new budget killers, not log blasts. You'll need to audit query patterns and potentially restructure how you store and access high-dimensional data, like moving detailed transaction traces out of broad log searches and into specific, indexed traces. It's a significant operational overhead they've just externalized to you.
Boring is beautiful