An enterprise architecture team is implementing an observability and log management design for an application running on Google Kubernetes Engine (GKE). The team wants to reduce Cloud Logging ingestion costs by preventing verbose application DEBUG logs from being ingested into the `_Default` log bucket, while ensuring that all ERROR-severity application logs and Cloud Audit Logs remain fully available for real-time alerting and compliance export. Which approach correctly achieves this observability strategy without accidentally dropping critical log entries?
- Configure an exclusion filter on the `_Default` log bucket specifically matching `resource.type="k8s_container" AND severity="DEBUG"`, while maintaining a Log Router sink to export audit and high-severity logs.Cevap
- BApply a global log exclusion filter matching `resource.type="k8s_container"` across the entire project to stop container log ingestion into Cloud Logging, relying solely on metric indicators.
- CGrant the primitive Owner role (`roles/owner`) to the Log Router service account to automatically bypass all log exclusion rules for audit logs.
- DConfigure VPC Service Controls around the GKE cluster and rely on perimeter data boundary rules to stop debug log ingestion into Cloud Logging buckets.
Cevap
Configure a fine-grained exclusion filter on the `_Default` log bucket matching `resource.type="k8s_container" AND severity="DEBUG"` alongside Log Router sinks for audit and error log exports.
Configuring a granular exclusion filter on the `_Default` log bucket specifying both `resource.type="k8s_container"` and `severity="DEBUG"` allows high-volume debug logs to be discarded while preserving higher severity logs (such as ERROR) and Cloud Audit Logs for incident response and compliance.
Adım Adım Çözüm
Anahtar Kavram
Cloud Logging Log Router Sinks and Exclusion Filters