如何配置跨项目集中日志：创建跨项目日志 sink 并将多项目日志路由到中心存储桶

如何配置跨项目集中日志：创建跨项目日志 sink 并将多项目日志路由到中心存储桶

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills

这篇文章解决的任务是：把多个源项目（source project）产生的日志统一路由到一个中心项目（central project）中的日志存储桶（log bucket），让所有日志无论从哪个项目产生，都存在同一个地方、可以用同一条查询路径读取。文中所有命令来自 skills 仓库的 跨项目日志配置文档，使用gcloudCLI 完成配置，并用测试日志验证路由是否生效。

该文档给出了两种跨项目日志架构：集中存储（Centralized Storage，即日志路由，本文主题）和读取时聚合（Read-Time Aggregation，基于 Log Scopes）。文档的决策矩阵指出：集中存储可扩展到数千个项目规模，日志集中在单个 log bucket 中，便于通过 Observability Analytics 做统一 SQL 分析，访问控制通过中心 bucket 上的 Log Views 收敛；代价是如果没配置排除规则，可能出现日志重复存储的成本。读取时聚合则适合 375 个项目以下的规模。如果你要的是"日志真正落到一个中心存储桶"，就走本文的日志路由路径。

准备条件

• 已安装gcloudCLI 并完成认证。仓库的 单项目日志配置文档 指出：如果缺少gcloud可执行文件，需要先按 Google Cloud CLI 安装指南安装。
• 确定两个角色：存放中心日志桶的中心项目，以及一个或多个要路由日志的源项目。
• 以下命令中的花括号占位符需要替换为你自己的资源值，文档不提供默认值：

文档的架构图示例使用了central-logs-bucket（位于us-central1）作为中心桶，可直接作为命名参考。

第一步：在中心项目创建中心日志桶

创建自定义日志桶并启用 Log Analytics：

gcloud logging buckets create {bucket_id} \ --project={central_project_id} \ --location={region} \ --retention-days={retention_days} \ --enable-analytics

两个约束需要注意：

• 必须使用区域性日志桶，例如把--location设为us-central1，不要用global。文档说明这是为了兼容 Observability Analytics 和 SQL 查询。
• 仓库的单项目日志文档同时指出：日志桶在被 sink 路由进日志之前不产生存储或摄入费用。

创建后可以查看桶配置来核对位置、保留天数等设置是否正确：

gcloud logging buckets describe {bucket_id} \ --location={region} \ --project={central_project_id}

第二步：在中心项目创建指向中心桶的 sink

在中心项目创建一个项目级 sink，指向刚建的中心日志桶。这个 sink 负责把落到中心项目日志路由器（log router）的日志写入中心桶：

gcloud logging sinks create {sink_name} \ logging.googleapis.com/projects/{central_project_id}/locations/{region}/buckets/{bucket_id} \ --project={central_project_id}

第三步：在每个源资源创建跨项目 sink

要路由日志，必须在每个源组织、文件夹或项目上创建一个指向中心项目的 sink。

文档的推荐做法是：用排除规则过滤掉审计日志，把所有非审计日志路由到中心项目，然后到目的地用自定义 Log Views 分区或限制访问，而不是在 sink 上按业务细粒度过滤。sink 也支持用--log-filter参数只路由日志的一个子集，文档将其作为可选手段。

组织级 sink（用--include-children覆盖组织及其子资源下的日志）：

gcloud logging sinks create {sink_name} \ logging.googleapis.com/projects/{central_project_id} \ --organization={source_organization_id} \ --include-children \ --exclusion=filter='LOG_ID("cloudaudit.googleapis.com/activity")' \ --exclusion=filter='LOG_ID("externalaudit.googleapis.com/activity")' \ --exclusion=filter='LOG_ID("cloudaudit.googleapis.com/system_event")' \ --exclusion=filter='LOG_ID("externalaudit.googleapis.com/system_event")' \ --exclusion=filter='LOG_ID("cloudaudit.googleapis.com/access_transparency")' \ --exclusion=filter='LOG_ID("externalaudit.googleapis.com/access_transparency")'

项目级 sink（每个源项目执行一次）：

gcloud logging sinks create {sink_name} \ logging.googleapis.com/projects/{central_project_id} \ --project={source_project_id} \ --exclusion=filter='LOG_ID("cloudaudit.googleapis.com/activity")' \ --exclusion=filter='LOG_ID("externalaudit.googleapis.com/activity")' \ --exclusion=filter='LOG_ID("cloudaudit.googleapis.com/system_event")' \ --exclusion=filter='LOG_ID("externalaudit.googleapis.com/system_event")' \ --exclusion=filter='LOG_ID("cloudaudit.googleapis.com/access_transparency")' \ --exclusion=filter='LOG_ID("externalaudit.googleapis.com/access_transparency")'

第四步：授予 sink 写者身份 IAM 权限

sink 由服务账号写日志，必须把写者身份（writer identity）显式授权到中心项目，否则日志不会落地。这一步会修改 IAM 访问控制策略，文档将其列为安全敏感操作，要求执行前向用户确认——在手动执行时同样适用：先核对--member的账号和--project目标无误再运行。

1. 给源 sink 的写者身份授权：先取出源 sink 的writerIdentity：

   gcloud logging sinks describe {sink_name} \ --project={source_project_id} \ --format="value(writerIdentity)"

   输出的serviceAccount:...值记为{source_writer_identity}，然后在中心项目授予roles/logging.logWriter，允许源 sink 把日志写入中心项目的路由器：

   gcloud projects add-iam-policy-binding {central_project_id} \ --member={source_writer_identity} \ --role=roles/logging.logWriter

2. 给中心 sink 的写者身份授权：取出中心项目里那个 sink 的writerIdentity：

   gcloud logging sinks describe {central_sink_name} \ --project={central_project_id} \ --format="value(writerIdentity)"

   这里{central_sink_name}就是第二步在中心项目创建的 sink 名称。输出的{central_writer_identity}用于授予roles/logging.bucketWriter，允许它把日志写入中心日志桶：

   gcloud projects add-iam-policy-binding {central_project_id} \ --member={central_writer_identity} \ --role=roles/logging.bucketWriter

可选：在中心桶上创建自定义 Log Views

所有源日志最终都落在同一个中心桶里。如果需要按日志 ID 或来源项目做分区、或按视图收敛访问权限，可以在中心桶上创建自定义 Log Views：

按日志 ID 过滤：

gcloud logging views create {view_id} \ --bucket={bucket_id} \ --location={region} \ --project={central_project_id} \ --log-filter='LOG_ID("{log_id}")'

按来源项目过滤（{view_id}是新建视图的 ID）：

gcloud logging views create {view_id} \ --bucket={bucket_id} \ --location={region} \ --project={central_project_id} \ --log-filter='project_id="{source_project_id}"'

验证：确认日志已路由到中心桶

1. 在源项目写一条测试日志：

   gcloud logging write {test_log_id} "Test log entry for verification" \ --severity=WARNING \ --project={source_project_id}

2. 从中心日志桶读取这条测试日志。对区域性日志桶，必须带--view参数：默认的_Default视图只包含匹配默认过滤器的日志，应查询中心桶的_AllLogs视图或你刚创建的自定义视图：

   gcloud logging read 'logName:"projects/{source_project_id}/logs/{test_log_id}"' \ --bucket={bucket_id} \ --location={region} \ --view=_AllLogs \ --project={central_project_id}

   如果这条测试日志能从中中心桶读出，说明源项目到中心桶的路由链路已经打通。

日志没有出现在中心桶时

文档把排查收敛为两个检查点，按顺序走：

1. 核对源资源上 sink 的过滤条件。两个已知的坑：

   • 标准过滤表达式如logName:abc或logName="projects/{project_id}/logs/abc"在 log sink 里可能匹配失败，文档要求精确匹配时始终使用LOG_ID("abc")形式。
   • 检查排除过滤器（exclusion）是否意外把目标日志丢弃了。

2. 核对并补授写者身份权限——文档标注这是最常见的原因。源 sink 的写者身份服务账号必须显式获得中心资源上的权限：先用上面的gcloud logging sinks describe ... --format="value(writerIdentity)"拿到身份，再对 Cloud Logging 桶授予roles/logging.bucketWriter：

   gcloud projects add-iam-policy-binding {central_project_id} \ --member={writer_identity} \ --role=roles/logging.bucketWriter

   文档同时列出其他目的地类型的对应角色（GCS 桶为roles/storage.objectCreator、Pub/Sub 主题为roles/pubsub.publisher、BigQuery 数据集为roles/bigquery.dataEditor）；本文的路由目标是 Cloud Logging 桶，只需bucketWriter。

完成路由之后，文档的决策矩阵给出的延伸方向是：中心桶启用了 Log Analytics，可以通过 Observability Analytics 对集中存储的日志做统一的 SQL 查询；如果不希望日志在中心桶和项目默认桶中重复存储（这是集中存储方案的主要成本项），可以回头在源 sink 上收紧排除规则，但注意排除规则会直接丢弃匹配的日志，属于不可逆操作。

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills