Exclusion and retention act at different boundaries
Cloud Logging routes log entries through configured sinks. An exclusion filter controls which entries a particular sink routes under its supported configuration. Retention describes how long entries already stored in a destination remain available. Changing one boundary does not automatically establish the behavior of the other.
This distinction is important when reducing noisy logs or investigating an unexpected storage bill. The same entry can have more than one routing destination. An exclusion applied to one sink should not be described as proof that no copy reaches another bucket or export service.
Setup: inventory the routing graph
Record the source project or higher-level scope, sink identities, inclusion and exclusion filters, destinations and writer identities. Include aggregated sinks and any organization or folder policy affecting routing. Distinguish editable sinks from required system behavior documented by the platform.
For each destination, identify its owner, retention settings, access policy and business purpose. Mark logs needed for incident response, security investigation or an agreed operational requirement. The owner should approve a deliberate evidence reduction rather than discovering it during the next outage.
Inspect a proposed exclusion
- Select representative log entries with stable identifying fields. Record the resource type, log name, severity and structured fields that the filter is intended to match.
- Test the filter against both intended noise and essential negative cases. Broad text matching can capture important entries when application messages change.
- Walk the entry through each sink in the relevant routing scope. Check inclusion, exclusion and destination configuration separately; a successful match on one sink does not explain every destination.
- After an approved pilot change, generate or observe fresh representative events and query each intended destination. Preserve timestamps and account for normal routing delay before declaring a copy absent.
Illustrative incident: one bucket shrinks while another keeps growing
In this illustrative scenario, a team excludes verbose application entries from a project sink and expects all related storage to stop increasing. A separate aggregated sink still routes the same entries to another destination whose owner was not included in the change.
The operators map the full routing graph, reconcile each destination's purpose and approve scope-specific filters. They also retain a tested route for essential diagnostic events. The example explains destination ownership and is not a measured cost-saving case study.
Diagnostic table
| Observation | Evidence | Boundary |
|---|---|---|
| Entry is absent from one bucket | Sink filters and fresh event | Routing to that destination |
| Another destination still receives it | Other project or aggregated sinks | Independent route |
| Historical data remains after exclusion | Stored entry age and retention | Existing destination data |
| Incident evidence disappears | Negative-case filter tests | Overbroad exclusion |
Correct and verify the change
Refine the evidenced sink filter instead of disabling all application logging. Review destination-specific retention and pricing separately using current provider documentation and actual usage data. An exclusion is not a universal promise of zero ingestion, storage or downstream processing cost.
Verify that required error, authentication and change events still arrive with useful fields and access controls. Check any dependent alerting or metrics according to their own documented evaluation scope. Keep the previous filter so the routing change can be reversed without reconstructing it from memory.
Monitoring and SOP
Record the exclusion owner, purpose, sample events, destinations reviewed and post-change checks. Monitor log freshness for critical event families and review filter changes when the application logging schema changes. The SOP should connect cost decisions to the evidence the team needs to diagnose failures, with an explicit owner for every retained or excluded destination.
See Clouvenix observability monitoring for implementation and operational handover.
Technical reference
Official reference 1. Documentation checked 20 October 2026; confirm behavior for your deployed edition and version.