Summary
#11343 reported, and #11355 fixed, logging_sink_created false-failing for projects covered only by an org/folder-level aggregated sink (includeChildren=true). The same false-FAIL affects the sibling family — the nine logging_log_metric_filter_and_alert_for_* checks — which are still evaluated strictly per-project.
What
These checks PASS a project only if a matching log metric and alert exist in that project. But in the centralized topology #11343 describes — an org-level aggregated sink shipping every child project's logs into one bucket, with a single bucket-scoped metric + alert covering them all — every child project is reported FAIL, even though its admin/audit activity is fully metric-monitored and alerted.
Repro
A child project whose logs flow (via an org includeChildren sink) to a central bucket that has a matching bucket-scoped metric + alert is reported:
FAIL There are no log metric filters or alerts associated in project <child-project>.
(Reproduced as a unit test in the PR — RED→GREEN evidence attached.)
Why it matters
Same rationale as #11343: false positives on a Google-recommended centralized-logging architecture; users must otherwise duplicate a metric+alert in every project (defeating the aggregated sink) or mutelist the findings (masking real regressions).
Proposed fix (mirrors #11355)
- add
bucket_name to the Metric model and populate it from metric.bucketName;
- add a helper
get_projects_covered_by_aggregated_metric(...) mapping a bucket-scoped matching metric+alert → the covering org includeChildren sink (matched by destination bucket, so it never false-passes) → the covered projects;
- in each of the 9 checks, mark centrally-covered projects PASS instead of FAIL.
Affected checks (9)
audit_configuration_changes, bucket_permission_changes, compute_configuration_changes, custom_role_changes, project_ownership_changes, sql_instance_configuration_changes, vpc_firewall_rule_changes, vpc_network_changes, vpc_network_route_changes.
Natural follow-up to #11343 / #11355.
Summary
#11343 reported, and #11355 fixed,
logging_sink_createdfalse-failing for projects covered only by an org/folder-level aggregated sink (includeChildren=true). The same false-FAIL affects the sibling family — the ninelogging_log_metric_filter_and_alert_for_*checks — which are still evaluated strictly per-project.What
These checks PASS a project only if a matching log metric and alert exist in that project. But in the centralized topology #11343 describes — an org-level aggregated sink shipping every child project's logs into one bucket, with a single bucket-scoped metric + alert covering them all — every child project is reported FAIL, even though its admin/audit activity is fully metric-monitored and alerted.
Repro
A child project whose logs flow (via an org
includeChildrensink) to a central bucket that has a matching bucket-scoped metric + alert is reported:(Reproduced as a unit test in the PR — RED→GREEN evidence attached.)
Why it matters
Same rationale as #11343: false positives on a Google-recommended centralized-logging architecture; users must otherwise duplicate a metric+alert in every project (defeating the aggregated sink) or mutelist the findings (masking real regressions).
Proposed fix (mirrors #11355)
bucket_nameto theMetricmodel and populate it frommetric.bucketName;get_projects_covered_by_aggregated_metric(...)mapping a bucket-scoped matching metric+alert → the covering orgincludeChildrensink (matched by destination bucket, so it never false-passes) → the covered projects;Affected checks (9)
audit_configuration_changes,bucket_permission_changes,compute_configuration_changes,custom_role_changes,project_ownership_changes,sql_instance_configuration_changes,vpc_firewall_rule_changes,vpc_network_changes,vpc_network_route_changes.Natural follow-up to #11343 / #11355.