Observability Cost Control: Cardinality, Rollups, and What Actually Works

This guide folds in two earlier posts: 7 Ways to Reduce Observability Cost by Farnaz Erfan, and 5 Strategies to Slash Your Observability Bill.

While this article focuses primarily on metrics cardinality and rollups, where cost dynamics are most acute, cost control in practice spans logs, traces, and query activity as well. Kloudfuse provides rate control and governance across all telemetry streams, not just metrics.

Why can nobody explain the observability bill?

Every observability cost conversation starts the same way. Engineering leadership looks at the invoice, asks why it grew 40 percent in one quarter, and nobody can explain which teams, services, or decisions drove the increase. The platform team suspects cardinality. The vendor says the contract is usage-based. And the application teams who generated the telemetry have no visibility into what they are consuming.

This is not a pricing problem. It is a measurement problem. And most observability platforms are structurally unable to solve it, because they separate the act of generating telemetry from the act of paying for it.

Observability costs are driven by three things: the volume of data ingested, the cardinality of metrics generated, and the frequency and volume at which data is queried. Most cost discussions focus on the first — how many GBs of logs, how many spans, how many data points. But the second and third are where costs compound in ways that are difficult to predict and harder to control. This problem is about to get worse. AI-driven SRE workflows - MCP servers, agentic troubleshooting bots, copilot-style interfaces are changing what gets queried and how. Traditional dashboards and alerts run canned queries against known metrics with known label combinations. An AI agent investigating a latency spike runs exploratory, ad hoc queries across whatever metrics and labels exist, because it does not know in advance which series will be relevant to the investigation. That fundamentally changes the cost-control calculus.

Vendor approaches that manage cost by controlling what gets indexed and what gets dropped, selecting which tags to keep at ingestion time, assume someone knows in advance which labels matter. In a world where AI agents explore your telemetry dynamically during incident response, that assumption breaks down. You cannot drop the label that an AI agent will need tomorrow during a production incident you have not had yet. The shift from dashboard-driven to agent-driven observability makes cardinality governance and multi-resolution rollups more important, not less because the query patterns are no longer predictable.

Why do observability costs keep rising?

Five structural reasons sit under most of the growth. They come from our earlier post on slashing the observability bill, and each one maps onto a control described later in this guide.

Data Volume and Complexity: The rise of cloud-native technologies, microservices, and CI/CD pipelines has significantly amplified the volume of data produced by modern infrastructures. As a result, organizations need to analyze extensive amounts of data to effectively monitor, observe, analyze and enhance their application and infrastructure performance. This has led to increased storage, processing, and operational costs for SaaS observability vendors, which impacts their customers as well. Additionally, organizations face network egress fees to transfer data to these providers for analysis.

Observability Vendor Pricing Models: SaaS observability vendors commonly lock customers into annual contracts with hefty markups to offset their cloud operational costs for hosting and managing customer data. Additionally, some vendors use usage-based pricing models, which can lead to dramatic cost increases during high data production periods like seasonal peaks or detailed troubleshooting phases. As a result, many organizations struggle with unexpected overage charges due to the lack of control over data consumption.

Scalability and Customer Growth: As organizations scale their operations to meet the growing demands of their customers, they often encounter scalability and performance limitations with their existing observability solutions. In these cases, scaling up infrastructure and compute resources to accommodate increasing data volumes and user loads can lead to escalating costs.

Tool Proliferation: Organizations have acquired a multitude of observability tools and platforms to monitor different aspects of their environment. However, most observability platforms either excel or just focus on one area of observability, such as metrics, logs, traces, and events. Managing multiple tools has resulted in cumulative expenses ranging from different licenses, tool administration costs, costly integration efforts to unify data across platforms, and investments in training and skill development for engineering teams.

Long-Term Retention Policies: When it comes to Real User Monitoring or Security Observability, higher data retention rates are a common practice. Longer retention is also prominent in regulated industries, such as Financial Services and Healthcare, where years of data is needed for compliance reasons. Often, in the fear of not losing data, organizations end up keeping too much data, which can lead to additional costs.

What is cardinality and why does nobody manage it?

Cardinality is the number of unique time series generated by a metric. A metric named http_request_duration with labels for method, status_code, and endpoint might generate 50 time series. Add a label for user_id or request_id, and it generates 50,000. Add pod_name in a Kubernetes environment with rolling deployments, and it generates a new time series every time a pod restarts.

High cardinality is not inherently bad. Some analytical use cases require it. The problem is that most teams do not know they are generating it. An engineer adds a label to improve debugging, does not realize it creates 10,000 new time series, and the cost does not surface until the next billing cycle.

Here is how the major vendors handle this:

• Datadog's Metrics without Limits decouples ingested and indexed custom metrics. Per Datadog's billing documentation, ingested custom metrics exceeding the account allotment are billed at a per-100-metric rate, while indexed custom metric pricing depends on the customer's contract terms. The architecture gives teams more control over which tags are queryable, but it also requires ongoing tag-configuration discipline — teams must decide at ingestion time which labels to index, and that decision directly affects both cost and query capability.
• Grafana's Adaptive Metrics identifies underused telemetry and reduces metrics cost by aggregating or dropping low-value series. The approach works for telemetry optimization — reducing what you store when you know what you do not need. But it is still a telemetry-selection approach: it assumes someone (or something) can determine in advance which metrics and labels are low-value. In an environment where AI agents run exploratory queries during incident response, that assumption is harder to make confidently.
• Chronosphere treats cardinality as a governance problem. Its Control Plane and Metrics Quotas let platform teams allocate and limit persisted metric writes across pools that can map to services or teams. That is a strong framing for metrics governance. The quota model gives platform teams direct control over who can write how much — which is closer to the kind of operational control this article argues teams need. The limitation is that it remains metrics-centric rather than a unified cost-governance model across all telemetry streams.
• Elastic's 2026 observability research found that 96% of surveyed organizations are actively taking steps to reduce observability cost, with 51% consolidating existing toolsets (Source: Elastic, 2026 Global Observability Trends). The finding underscores how widespread cost pressure has become — and how most responses focus on toolset consolidation rather than platform-level cost governance.

How do Datadog, Grafana, Chronosphere and Kloudfuse compare on cost control?

How do multi-resolution rollups cut query cost?

Every time-series database supports some form of downsampling or rollup. Store raw data for recent queries, aggregate into lower-resolution data for longer time ranges. The concept is simple. The implementation is where vendors diverge.

Most platforms offer a single rollup tier, configured globally. Raw data for 15 days, 5-minute aggregates after that. This is a blunt instrument. A platform team managing 20 application teams has 20 different retention and resolution requirements. Some teams need raw data for 7 days. Others need 30. Some metrics require 1-minute resolution for real-time alerting. Others are fine at 1-hour resolution for capacity planning.

Kloudfuse supports multi-rollup resolution with automatic query selection. Metrics are stored at multiple resolutions simultaneously: raw, 5-minute, 1-hour, and custom rollups configurable by stream or label. When a user queries a 24-hour time range, the query engine automatically selects 5-minute rollups. A 7-day range uses hourly rollups. A 15-minute investigation uses raw data. The user does not choose. The platform optimizes based on the query.

This matters for cost because query cost is a function of the amount of data scanned. A 30-day dashboard query that scans raw data is 360 times more expensive in compute than the same query against hourly rollups. Most platforms force this tradeoff onto the user or the platform team. Kloudfuse makes it automatic.

How does ingestion rate control prevent cost surprises?

The most expensive observability cost is the one you did not see coming. An application team deploys a new service with high-cardinality labels. A log pipeline starts emitting debug-level messages in production. A trace instrumentation change captures every database query parameter. By the time anyone notices, the data is ingested, stored, indexed, and billed.

Cost cleanup is reactive. You find the waste, remove it, and negotiate a credit with the vendor if you are lucky. Cost prevention is architectural. You set boundaries at the ingestion layer so that cost surprises cannot happen.

Kloudfuse provides stream-level rate controls. Platform teams set per-stream ingestion limits for metrics, logs, traces, events, and RUM. Each stream type has independent thresholds. When an application team exceeds their allocation, the rate control activates: excess data is either dropped, sampled, or queued depending on the policy. The platform team gets notified. Other teams are unaffected.

This is fundamentally different from what hosted vendors offer. Datadog does not provide per-team ingestion limits. Grafana's cost controls operate after ingestion, recommending what to remove. New Relic's Compute Capacity Unit (CCU) model explicitly ties platform cost to actions such as queries, alert evaluations, API calls, and page loads. That makes query behavior a direct input to the cost model which is transparent, but also means that exploratory AI-driven queries during incident response contribute to cost in ways that are harder to predict or budget. The CCU model creates cost awareness, but does not by itself provide the kind of platform-level rate control and per-team isolation that this article argues platform engineering teams need to govern observability economics proactively. The rate control has to happen at the ingestion layer, before the data is stored and billed.

How do you see cardinality before you pay for it?

Most cardinality problems are invisible until the bill arrives. An engineer adds a label. A Helm chart change introduces a new tag. A migration generates temporary high-cardinality data. The platform team finds out 30 days later.

Kloudfuse's Metrics Cardinality Explorer is a real-time analytical interface that shows cardinality by metric name, by label, by service, and by team. Platform teams can see exactly which labels are driving cardinality growth, identify which team deployed the change, and decide whether to keep the label, aggregate it, or drop it — before the next billing cycle.

This is not a recommendation engine. It does not use machine learning to suggest what you might want to remove. It is a diagnostic tool that gives platform teams the same visibility into their observability costs that they have into their cloud compute costs. Exact numbers. Exact attribution. Real-time. This matters more in an agent-driven observability environment. When AI agents run ad hoc exploratory queries, they interact with whatever label combinations exist in the data. A cardinality problem that was invisible behind canned dashboards becomes a cost and performance problem the moment an agent starts traversing high-cardinality series during incident investigation. The Explorer gives platform teams the visibility to identify and resolve these issues before they affect both human and AI-driven query performance.

Why is Self-SaaS cheaper than hosted observability?

There is a structural cost difference between running observability in a vendor’s cloud and running it in your own VPC. Hosted observability pricing includes not only the underlying compute, storage, and network required to process your data, but also the vendor’s platform and service layer on top of that infrastructure. For high-volume environments, that additional cost layer can materially change total cost of ownership, especially when it scales with data volume regardless of how much of that data is actually useful.

Kloudfuse runs as Self-SaaS, our managed BYOC model, in your VPC on your cloud infrastructure. You pay cloud provider rates for compute and storage, plus the Kloudfuse software license. For organizations processing more than a few terabytes per day, the total cost of ownership difference is significant. The exact number depends on volume, but the structural economics are clear: removing the vendor's infrastructure margin changes the cost equation fundamentally.

This also eliminates a second hidden cost: data transfer. Hosted observability vendors require you to send all telemetry data out of your VPC to their infrastructure. At scale, egress charges are material. With Kloudfuse, data never leaves your VPC. Kloudfuse's architecture eliminates the recurring data-egress pattern associated with shipping observability data to a vendor-hosted platform. There is no per-GB charge for sending telemetry to a third party, the data moves within your infrastructure, governed by your own cloud networking costs.

Which five strategies cut the bill fastest?

These five strategies address the reasons listed above, and they work on any platform. The next section covers how Kloudfuse implements them.

Consolidate Your Observability Solutions

To reduce the complexity and cost, both from a licensing/pricing standpoint and from a manual integration and engineering standpoint, organizations are considering consolidating their observability tools.

Standardizing on a unified platform that provides comprehensive monitoring and troubleshooting capabilities across metrics, logs, traces, and events simplifies management, lowers licensing costs, and enhances engineering productivity.

Run Observability in Your Own VPC, Own the Savings

SaaS vendors often employ inflexible pricing models and charge for overages. Increased data volumes during ingest or intensive query analysis for diagnosis and troubleshooting can lead to significant spikes in costs. Additionally, network egress fees for transferring data from hosted applications and infrastructures to SaaS observability solutions further increase expenses.

In contrast, hosting observability platforms within Virtual Private Clouds (VPCs) allows organizations to gain control over their observability costs and resources while avoiding data transfer fees. In a VPC deployment, a two-tier architecture is used: a Data Plane for collecting and processing observability data and a Control Plane that oversees the “volume-to-cost” ratio. This setup allows organizations to adjust data ingestion and retention policies and modify infrastructure resources based on usage patterns, performance needs, and the level of detail required for thorough root cause analysis.

Invest in Open Source, The Right Way

Many organizations have learned valuable lessons from getting locked into proprietary tools. To stay adaptable, organizations should look for future-proof architectures. This includes open-source alternatives like OpenTelemetry (OTel), agent-free methods such as eBPF, and open query languages like PromQL, LogQL, TraceQL, GraphQL, and SQL for root cause analysis.

Although open-source solutions can cut licensing costs, they come with expenses for hosting, scaling, backup, and recovery and often lack support.

A better approach is to use a platform that integrates with open-source tools and provides robust management capabilities for cloud hosting, resource allocation, cost optimization, advanced features, and premium support beyond what basic open-source solutions offer.

Shape Your Data, Slash Your Costs

To manage the high volumes of high-cardinality data and mitigate associated costs, organizations should leverage advanced data shaping techniques. These techniques include comprehensive cardinality analysis for metrics, logs, and traces, which helps identify high-cardinality data early in the ingestion process. Techniques such as data aggregation, dynamic filtering, and mapping can convert high-cardinality data into lower-cardinality formats. This process eliminates irrelevant data points, reduces storage needs, improves query performance, and ultimately leads to significant cost savings.

Refine Retention and Storage Footprint

Observability solutions with fine-grained retention policies are able to classify data based on importance, lifespan, and compliance requirements. For instance, highly critical data (e.g., trace data from frequently accessed services like a payment service) will be retained for a longer period, while less crucial data (e.g., informational logs lacking errors or warnings) will be discarded. This approach ensures observability expenses are minimized by retaining only the most pertinent data.

Additionally, implementing deduplication and compression techniques on observability data can significantly reduce storage requirements, thereby lowering storage costs.

How does Kloudfuse lower the bill in practice?

Modern observability has turned into a cost crisis, with single-vendor bills reported at $65 million a year. We’ve created a smarter way to help companies take control of these costs. Here are seven key ways Kloudfuse empowers you to save on expenses while providing state-of-the-art observability.

1. Predictable Pricing on One Axis

SaaS observability vendors charge based on data volume and usage. Kloudfuse offers predictable pricing on one axis, terabytes ingested per day, eliminating unpredictable overage fees. There is no per-host charge, no per-seat tier and no cardinality premium. By deploying Kloudfuse as Self-SaaS in your Virtual Private Cloud (VPC), you maintain full control over costs and avoid month-end billing surprises.

2. Avoid Egress Fees

Egress fees, the cost of transferring data from your cloud to a vendor, can add up as you continuously monitor and collect data. You are constantly observing and racking up costs. Because Kloudfuse runs as Self-SaaS inside your own cloud account rather than in a vendor’s cloud, you avoid these fees: telemetry stays within your infrastructure, which saves significantly over time.

3. Unified Platform to Simplify Engineering

Kloudfuse consolidates metrics, logs, traces, and more into a single platform, eliminating the need for multiple tools. This unification reduces engineering time that would otherwise be spent on manual integration work, lowers the administrative overhead of managing various tools, and boosts overall productivity and cost-efficiency. Kloudfuse also supports open standards like OpenTelemetry and common query languages, so you can easily find engineers with the right skills without being tied to a specific vendor.

4. Leverage Your Cloud Credits and Discounts

Deploy Kloudfuse in your VPC to take full advantage of your cloud credits and discounts from providers like AWS, GCP, or Azure. SaaS vendors charge premiums for using their infrastructure, but Kloudfuse allows you to purchase cloud resources directly, helping you save significantly.

5. Better Resource Management

Kloudfuse provides a control plane that lets you manage the amount of data you collect and process, helping you control your cloud costs. You can capture everything for maximum troubleshooting accuracy or optimize for cost by adjusting data granularity and retention based on your needs, only paying for what's necessary.

6. Advanced Data Shaping and Transformation

Kloudfuse helps you reduce your data volumes using aggregations and data transformations. By focusing on storing and processing only the most valuable data critical to your troubleshooting and long-term compliance, you can significantly lower your overall costs.

7. Lower Storage Footprint with Deduplication and Compression

Observability data, especially logs, can consume vast amounts of storage. Kloudfuse minimizes this with deduplication and compression, powered by its Finger Printing technology. Compressed logs can be stored in cost-efficient solutions like S3, further reducing storage expenses.

Kloudfuse offers a smarter, cost-effective approach to observability. With predictable pricing on one axis, terabytes ingested per day, Self-SaaS deployment in your VPC, advanced data management tools, and a unified platform, it helps you manage observability costs predictably while delivering top-tier capabilities.

What should a platform team’s cost control checklist cover?

1. Do you know your current cardinality by team and by service? If not, you are optimizing blind.
2. Can you set per-team ingestion limits? If not, one team can spike the bill for everyone.
3. Are your dashboards using rollups automatically? If every query scans raw data, you are overpaying for compute.
4. Can you attribute cost by team, by stream, by time period? If not, you cannot have a productive conversation with engineering leadership about the budget. See building real-time cost visibility and chargeback models.
5. Does your data stay in your VPC? If not, you are paying a vendor margin plus egress charges on every byte of telemetry.

Cost control is not about spending less on observability. It is about knowing exactly what you spend, why you spend it, and having the architectural controls to make intentional decisions instead of reacting to bills.

Frequently Asked Questions

What is metrics cardinality and why does it drive observability cost?

Cardinality is the number of unique time series a metric generates. A metric with labels for method, status code and endpoint might produce 50 series; adding user_id or request_id can push it to 50,000, and pod_name in a Kubernetes cluster creates a new series on every restart. Each series is ingested, stored and indexed, so cardinality compounds cost in ways that rarely surface until the next billing cycle. Kloudfuse’s Metrics Cardinality Explorer shows cardinality by metric, label, service and team in real time so platform teams can act before the bill arrives.

How do multi-resolution rollups reduce observability cost?

Query cost is a function of the data scanned. Kloudfuse stores metrics at several resolutions at once, raw, 5-minute, 1-hour and custom rollups per stream or label, and the query engine picks the resolution automatically: raw for a 15-minute investigation, 5-minute rollups for a 24-hour range, hourly rollups for a 7-day range. A 30-day dashboard query against hourly rollups scans roughly 360 times less data than the same query against raw points, and the user never has to choose.

What is ingestion rate control and how is it different from cost cleanup?

Cost cleanup is reactive: you find waste after it has been ingested, stored, indexed and billed, then remove it. Rate control is preventive. Kloudfuse lets platform teams set per-stream ingestion limits for metrics, logs, traces, events and RUM, each with independent thresholds. When a team exceeds its allocation, excess data is dropped, sampled or queued according to policy, the platform team is notified, and other teams are unaffected. Because the control sits at the ingestion layer, cost surprises cannot reach the bill.

How does Kloudfuse price observability?

Kloudfuse offers predictable pricing on one axis, terabytes ingested per day. There is no per-host charge, no per-seat tier and no cardinality premium. Because the platform runs as Self-SaaS in your own cloud account, you pay cloud provider rates for compute and storage plus the Kloudfuse licence, and you can apply your existing cloud credits and discounts to that infrastructure.

Does running observability in your own VPC avoid egress fees?

Hosted observability vendors require telemetry to leave your VPC for their infrastructure, and cloud providers charge for that transfer, so at scale egress is a material line item. With Kloudfuse running as Self-SaaS inside your account, telemetry moves within your own cloud network, so the recurring per-GB transfer to a third party disappears. You still pay your cloud provider’s normal networking rates for traffic inside your environment.

Which cost-cutting strategy should a platform team start with?

Start with measurement, because every other strategy depends on it: know your cardinality by team and by service, and whether you can attribute cost by team, stream and time period. Then work through the five strategies in this guide in order of leverage: consolidate tools onto one platform, run observability in your own VPC, adopt open standards such as OpenTelemetry and PromQL, shape high-cardinality data at ingestion, and refine retention with deduplication and compression.