Not the events you need as evidence. Keep authentication, authorization, privilege and audit events in full. Sampling suits high volume, repetitive, healthy traffic such as successful health checks or debug traces. Decide per event class, document it, and make sure dropped data cannot be needed for an investigation.
What sampling means
OpenTelemetry defines sampling for traces and spans: a sampled item is processed and exported, and an unsampled one is not. The sampler chooses items that are representative of the whole population, which cuts cost while keeping analysis valid.
Two styles matter. Head sampling decides early, using something like the trace ID and a percentage. It is simple but cannot guarantee that every trace with an error is kept. Tail sampling decides after seeing most of a trace, so it can keep errors, slow requests or specific attributes. It is more powerful and harder to run.
OpenTelemetry's page covers traces. It does not discuss sampling for logs, so treat any log sampling as your own design with its own risks.
It also says not to sample when data volume is low, when you need only aggregates, or when regulations prohibit dropping data. That last point matters for audit trails.
Why security events are different
Representative samples answer questions about averages: how slow is the service, how often does it error. Security questions are about specific events. Did this account log in from that address on that day? A sample can drop the one line that answers it.
So the rule is to keep every event that could be evidence for one actor.
Keep, sample or drop
| Event class | Treatment |
|---|---|
| Authentication successes and failures | Keep all |
| Authorization failures | Keep all |
| Privilege, admin, export and configuration changes | Keep all, in an audit stream |
| Application errors | Keep all, deduplicate repeated stack traces |
| Successful health checks and static asset requests | Sample or drop |
| Routine successful read requests | Sample, keep a minimum of metadata |
| Debug level logs | Drop in production, enable per request when needed |
| Traces of healthy requests | Head sample, with tail rules to keep errors |
Deduplication is a safer form of reduction than sampling. See log an error once.
Cheaper ways to save
- Cut retention on low value streams while keeping audit streams longer. See retention by data class.
- Move older logs to cold storage rather than deleting them.
- Drop fields you never query, such as large headers.
- Fix chatty loggers that print inside loops.
- Route health checks away from the application log.
Steps if you must sample
- List event classes and mark which are evidence.
- Never sample the evidence classes.
- Record the sample rate in the event so you can scale counts correctly.
- Add a rule that keeps all events from an actor once a detection fires.
- Review the policy when a regulation or customer contract changes.
Quick check
Is it fine to sample successful logins?
Avoid it. Successful logins are the context for investigating a compromised account. Keep them, and manage cost with retention instead.
What is tail sampling good for?
Keeping whole traces that contain errors or slow requests, which head sampling can miss.
Safeguard's SBOM and dependency scanning is unrelated to log volume, but a free scan at gold.safeguard.sh/scan shows what you ship.
Sources
Last reviewed: 19 October 2026.
