Documentation Grafana Cloud Monitor applications Application Observability Optimize costs

Optimize Application Observability costs

Application Observability bills on two dimensions: the host hours that send application telemetry, and the telemetry those hosts produce, such as metrics (active series), and traces, logs, and profiles (by volume). For the full billing model, refer to the host-hours pricing documentation.

This guide explains what drives those costs and how to reduce them without losing visibility. Most savings come from controlling metric cardinality—the number of unique active series your telemetry generates—and from sending only the telemetry that has observability value.

What drives cost

Why cardinality matters most

Application Observability derives its RED (Rate, Errors, Duration) metrics from your span data. The number of active series those metrics produce is roughly the product of the distinct values of each label—job × span_name × span_kind × status_code × each histogram bucket, and so on. A single label with thousands of distinct values multiplies your series count and therefore your metrics bill.

The span_name label is the most common offender. Span names group operations into categories (for example, GET /user/{id}), not individual requests (for example, GET /user/123). When span names embed IDs, timestamps, or query strings, cardinality explodes.

Reduce metric series

The following sections describe specific techniques to reduce active series and control metric costs.

Reduce high-cardinality span names

High-cardinality span names drive avoidable metrics cost and prevent Application Observability from grouping operations meaningfully. Use generic patterns such as GET /user/{id} instead of specific values like GET /user/123.

The Instrumentation Quality report highlights offending span names and suggests low-cardinality replacements. To fix them at the source, rewrite span names with a transform processor on your collector. For collector configuration examples, refer to Reduce high-cardinality span names.

Filter out spans that don’t add value

Some spans generate metrics and ingest volume without adding observability value—health checks, scrape endpoints, and static assets are common examples. Exclude them from metric generation with filter rules: in Application Observability, go to Configuration, select the Metrics tab, then Filter rules.

Common high-value exclusions:

• Health check endpoints—for example, span names matching .*/healthz.*
• Metrics scrape endpoints—for example, span names matching .*/metrics.*
• Static assets—for example, http.url matching .*\.(png|jpg|jpeg|gif|css|js|ico|svg|woff|woff2)$
• Favicon and robots.txt requests—automated, noise-only traffic

Filtering these spans reduces both metric cardinality and trace volume.

Configure metric generation dimensions

Each additional dimension (label) you generate metrics on multiplies the number of active series. In Configuration > Metrics > Dimensions, review which dimensions you configured for metric generation and keep only the labels you actually filter or group by in Application Observability. Removing an unused high-cardinality dimension can cut series counts substantially.

Disable the instance label when it’s high cardinality

When Application Observability generates metrics from traces, it automatically adds an instance label. The instance label is useful in most environments and should stay enabled. However, in environments where instances are short-lived or numerous—so the label has high cardinality and isn’t useful—you can disable it in Configuration > System to reduce series as a cost-saving measure.

Tune histogram buckets

Latency histograms emit one series per bucket boundary (le), so the number of buckets directly affects series count. Choose a bucket layout that matches the latency range you care about rather than keeping unnecessary fine-grained buckets across services. Coarser buckets mean fewer series.

If you use Grafana Cloud to generate span metrics from your traces, configure the bucket layout on the metric generation configuration page: in Application Observability, go to Configuration, select the Metrics tab, then Histogram buckets. If your metrics come from your collector or eBPF instead, set the buckets there.

Prefer native histograms

Where supported, prefer native histograms over classic histograms. A classic histogram emits a separate series for every bucket boundary (le) plus _sum and _count—10 or more series per histogram—whereas a native histogram represents the entire distribution as a single series, making it the most effective per-metric series reduction available.

Avoid duplicate span metrics

If a service produces span metrics from both eBPF instrumentation (Beyla) and Grafana Cloud generation from traces, you pay for the same series twice and see erroneous data. Generate the metric from one source only.

To exclude eBPF or Beyla traces from Grafana Cloud metric generation, add the span.metrics.skip=true resource attribute to that trace data. With standard OpenTelemetry instrumentation, set OTEL_RESOURCE_ATTRIBUTES="span.metrics.skip=true". Refer to Avoid duplicate span metrics.

Reduce trace, log, and profile volume

Application Observability bills traces, logs, and profiles by ingested volume. To reduce them:

• Sample your traces. Head and tail sampling reduce the cost of processing and storing large trace volumes while keeping representative traces and edge cases. Refer to the sampling documentation.
• Apply filter rules. Excluding noise-only spans (refer to Filter out spans that don’t add value) lowers trace volume as well as metric series.
• Send telemetry only from services you need to observe. Logs and profiles add value where you investigate. Scope collection to the services and environments that matter.

Control host hours

Application Observability bills host hours per host that sends telemetry. The most common source of unexpected host-hours cost is incorrect host identification, which causes Grafana Cloud to count more hosts than you actually run.

Common host identification issues

• On Kubernetes, set k8s.node.name on your telemetry. Without it, host.name resolves to the Pod name and every Pod counts as a separate host.
• Behind a passthrough gateway, set override: false on the gateway’s resourcedetection processor so it doesn’t overwrite the agent’s host attributes with its own identity, which leads to over-counting.
• Verify host identification for every environment that sends telemetry. The Instrumentation Quality report flags services with missing host identification.

For the full attribute priority and per-environment configuration, refer to the host-hours pricing documentation.

Use the Instrumentation Quality report

The Instrumentation Quality report finds cost problems for a specific service. Select the Quality report tab for a service. If there are issues, the tab shows how many. The report detects and links fixes for the issues most relevant to cost, including:

• High-cardinality span names
• Mixed histogram types
• Duplicate span metrics
• Missing host identification attributes

Refer to the Instrumentation quality documentation for the full list of checks.

Cost optimization checklist

• Review the Instrumentation Quality report for your highest-traffic services.
• Generalize high-cardinality span names (GET /user/{id}, not GET /user/123).
• Add filter rules to exclude health checks, scrape endpoints, static assets, and crawler traffic.
• Remove metric generation dimensions you don’t filter or group by.
• Disable the instance label where it’s high cardinality and not useful.
• Right-size histogram buckets and prefer native histograms.
• Prevent duplicate span metrics when using both eBPF and trace-based generation.
• Enable trace sampling to control trace, log, and profile volume.
• Confirm you identify hosts correctly so you aren’t over-counting host hours.

Disable Application Observability

If you no longer want to use Application Observability or incur any billing, you can disable it entirely. Note that you lose the visibility Application Observability provides. Refer to Disable Application Observability in Grafana Cloud.