> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Control telemetry volume and cost

> Measure where the bytes come from, drop what nobody reads before it is stored, keep data only as long as it is used, and keep metric series and queries bounded.

Telemetry grows faster than the questions it answers. A debug log left on, a label with a user ID, or a
health check logged every second can double storage without making any incident easier to solve. Cut
volume where it is useless, and keep what investigations need.

## Measure first

Find the streams that carry the volume before changing anything.

| Where | What it shows |
| - | - |
| [Home](https://docs.molesignal.com/en-US/home.md#intake-verdict-and-key-figures) | **Raw intake volume** and **Compressed data size** of the workspace, and how much smaller storage is than intake. |
| [Streams](https://docs.molesignal.com/en-US/streams.md#the-stream-list) | Per stream: compressed data in the period, **Collected size** before transformations, **Stored size**, **Index size**, and **Records**. Compare them to find the largest. |
| [Metrics](https://docs.molesignal.com/en-US/metrics.md#analyze-the-result) | **Cardinality** of a metric, its active series. |
| [Mole Agent usage](https://docs.molesignal.com/en-US/agent#usage-and-budget) | Model tokens by source and by day, and the daily budget. |

Write down the numbers of the largest streams. They are the baseline to judge each change against.

## Drop what nobody reads before it is stored

The cheapest byte is the one that is never stored. For logs, a realtime
[pipeline](https://docs.molesignal.com/en-US/pipelines#realtime-pipelines) runs during intake, before storage:

* **Filter events** drops health checks, readiness probes, and debug lines that no one reads in
  production.
* **Sample** keeps a share of a noisy but useful event type. With **Sample by field**, the events that
  share a value, such as one request ID, are kept or dropped together.
* **Remove fields** drops large fields that no query uses, such as full request bodies.

Change the sender first when possible: a log level of `info` in production, or a collector processor
that drops noise, saves the network as well. Dropped events are gone for good; sample only what is
repeated, never errors.

Trace volume is best reduced at the source or in the OpenTelemetry Collector. Keep every span of a
trace together, and remember that APM figures and SLOs count only the spans that arrive. For RUM, set
[session sampling](https://docs.molesignal.com/en-US/rum/sampling.md) per application.

## Keep data only as long as it is used

| Data | Retention | How |
| - | - | - |
| Debug and verbose logs | Days | A stream of their own with a short **Data retention (days)**. |
| Application and access logs | Weeks | The [platform default](https://docs.molesignal.com/en-US/settings/platform.md#data-retention), 30 days, or a per-stream value. |
| Audit and compliance logs | Months or years | A stream with a long retention and narrow access. |
| Metrics | Months | **Downsample older samples** on the **Retention** tab of the metrics stream: old samples roll up into time buckets and long-range queries read far less. |

Set retention from how long investigations really look back, and leave margin for slow discoveries.
Shortening retention deletes the data that is then past it in the next cleanup, and downsampling
deletes the original samples: both cannot be undone. Keep **Merge small files by day** on for logs and
traces, so queries over many days open fewer files.

## Keep metric series bounded

Each distinct combination of label values is a series. Labels with unbounded values, such as user IDs,
request IDs, or raw URLs, create series without limit, and the
[cardinality limits](https://docs.molesignal.com/en-US/settings/platform.md#metric-cardinality) then refuse new series for the whole
organization.

* Check **Cardinality** on Metrics after adding a label.
* Replace raw paths with route templates, and IDs with classes such as plan or region.
* Put per-request detail in logs or spans, which cost nothing per value.

## Keep queries cheap

| Habit | Effect |
| - | - |
| Set **Max query range (hours)** on large streams | A mistaken "last 90 days" is refused instead of scanning everything. |
| Index the fields that dashboards filter on | Filters skip files instead of reading them. See [Design streams and fields](https://docs.molesignal.com/en-US/best-practices/stream-design.md#index-what-is-filtered). |
| Start with the smallest time range | Narrow first, widen only when needed. |
| Run long scans as [search jobs](https://docs.molesignal.com/en-US/streams.md#search-jobs) | The query runs in the background and keeps its result, instead of holding a page open. |
| Refresh dashboards only as often as people look | **Auto** refresh adapts to the time range; avoid short intervals on wall screens with heavy panels. |

## Acceptance criteria

* The five largest streams are known, with their daily volume before and after the changes.
* No stream stores health checks, readiness probes, or production debug logs by accident.
* Each stream has a retention set on purpose, and long-lived metrics are downsampled.
* Metric series counts are stable from week to week and far below the limits.
* Large streams have a maximum query range, and their common filters are indexed.

## Related guides

* [Pipelines](https://docs.molesignal.com/en-US/pipelines)
* [Streams](https://docs.molesignal.com/en-US/streams.md)
* [Platform settings](https://docs.molesignal.com/en-US/settings/platform.md)
* [Design streams and fields that stay useful](https://docs.molesignal.com/en-US/best-practices/stream-design.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.