如何配置跨项目集中日志创建跨项目日志 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_project_id}中心项目 ID{source_project_id}源项目 ID每个源项目执行一次{source_organization_id}源组织 ID仅组织级 sink 使用{bucket_id}中心日志桶名称文档架构图中的示例名为central-logs-bucket{region}日志桶所在区域例如us-central1{retention_days}日志保留天数例如365单项目文档给出的示例值{sink_name}sink 名称源项目和中心项目的 sink 可以同名{test_log_id}验证用的测试日志 ID文档的架构图示例使用了central-logs-bucket位于us-central1作为中心桶可直接作为命名参考。第一步在中心项目创建中心日志桶创建自定义日志桶并启用 Log Analyticsgcloud 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 \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/access_transparency) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/access_transparency)项目级 sink每个源项目执行一次gcloud logging sinks create {sink_name} \ logging.googleapis.com/projects/{central_project_id} \ --project{source_project_id} \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/access_transparency) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/access_transparency)第四步授予 sink 写者身份 IAM 权限sink 由服务账号写日志必须把写者身份writer identity显式授权到中心项目否则日志不会落地。这一步会修改 IAM 访问控制策略文档将其列为安全敏感操作要求执行前向用户确认——在手动执行时同样适用先核对--member的账号和--project目标无误再运行。给源 sink 的写者身份授权先取出源 sink 的writerIdentitygcloud logging sinks describe {sink_name} \ --project{source_project_id} \ --formatvalue(writerIdentity)输出的serviceAccount:...值记为{source_writer_identity}然后在中心项目授予roles/logging.logWriter允许源 sink 把日志写入中心项目的路由器gcloud projects add-iam-policy-binding {central_project_id} \ --member{source_writer_identity} \ --roleroles/logging.logWriter给中心 sink 的写者身份授权取出中心项目里那个 sink 的writerIdentitygcloud logging sinks describe {central_sink_name} \ --project{central_project_id} \ --formatvalue(writerIdentity)这里{central_sink_name}就是第二步在中心项目创建的 sink 名称。输出的{central_writer_identity}用于授予roles/logging.bucketWriter允许它把日志写入中心日志桶gcloud projects add-iam-policy-binding {central_project_id} \ --member{central_writer_identity} \ --roleroles/logging.bucketWriter可选在中心桶上创建自定义 Log Views所有源日志最终都落在同一个中心桶里。如果需要按日志 ID 或来源项目做分区、或按视图收敛访问权限可以在中心桶上创建自定义 Log Views按日志 ID 过滤gcloud logging views create {view_id} \ --bucket{bucket_id} \ --location{region} \ --project{central_project_id} \ --log-filterLOG_ID({log_id})按来源项目过滤{view_id}是新建视图的 IDgcloud logging views create {view_id} \ --bucket{bucket_id} \ --location{region} \ --project{central_project_id} \ --log-filterproject_id{source_project_id}验证确认日志已路由到中心桶在源项目写一条测试日志gcloud logging write {test_log_id} Test log entry for verification \ --severityWARNING \ --project{source_project_id}从中心日志桶读取这条测试日志。对区域性日志桶必须带--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}如果这条测试日志能从中中心桶读出说明源项目到中心桶的路由链路已经打通。日志没有出现在中心桶时文档把排查收敛为两个检查点按顺序走核对源资源上 sink 的过滤条件。两个已知的坑标准过滤表达式如logName:abc或logNameprojects/{project_id}/logs/abc在 log sink 里可能匹配失败文档要求精确匹配时始终使用LOG_ID(abc)形式。检查排除过滤器exclusion是否意外把目标日志丢弃了。核对并补授写者身份权限——文档标注这是最常见的原因。源 sink 的写者身份服务账号必须显式获得中心资源上的权限先用上面的gcloud logging sinks describe ... --formatvalue(writerIdentity)拿到身份再对 Cloud Logging 桶授予roles/logging.bucketWritergcloud projects add-iam-policy-binding {central_project_id} \ --member{writer_identity} \ --roleroles/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何配置跨项目集中日志创建跨项目日志 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_project_id}中心项目 ID{source_project_id}源项目 ID每个源项目执行一次{source_organization_id}源组织 ID仅组织级 sink 使用{bucket_id}中心日志桶名称文档架构图中的示例名为central-logs-bucket{region}日志桶所在区域例如us-central1{retention_days}日志保留天数例如365单项目文档给出的示例值{sink_name}sink 名称源项目和中心项目的 sink 可以同名{test_log_id}验证用的测试日志 ID文档的架构图示例使用了central-logs-bucket位于us-central1作为中心桶可直接作为命名参考。第一步在中心项目创建中心日志桶创建自定义日志桶并启用 Log Analyticsgcloud 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 \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/access_transparency) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/access_transparency)项目级 sink每个源项目执行一次gcloud logging sinks create {sink_name} \ logging.googleapis.com/projects/{central_project_id} \ --project{source_project_id} \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/activity) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/system_event) \ --exclusionfilterLOG_ID(cloudaudit.googleapis.com/access_transparency) \ --exclusionfilterLOG_ID(externalaudit.googleapis.com/access_transparency)第四步授予 sink 写者身份 IAM 权限sink 由服务账号写日志必须把写者身份writer identity显式授权到中心项目否则日志不会落地。这一步会修改 IAM 访问控制策略文档将其列为安全敏感操作要求执行前向用户确认——在手动执行时同样适用先核对--member的账号和--project目标无误再运行。给源 sink 的写者身份授权先取出源 sink 的writerIdentitygcloud logging sinks describe {sink_name} \ --project{source_project_id} \ --formatvalue(writerIdentity)输出的serviceAccount:...值记为{source_writer_identity}然后在中心项目授予roles/logging.logWriter允许源 sink 把日志写入中心项目的路由器gcloud projects add-iam-policy-binding {central_project_id} \ --member{source_writer_identity} \ --roleroles/logging.logWriter给中心 sink 的写者身份授权取出中心项目里那个 sink 的writerIdentitygcloud logging sinks describe {central_sink_name} \ --project{central_project_id} \ --formatvalue(writerIdentity)这里{central_sink_name}就是第二步在中心项目创建的 sink 名称。输出的{central_writer_identity}用于授予roles/logging.bucketWriter允许它把日志写入中心日志桶gcloud projects add-iam-policy-binding {central_project_id} \ --member{central_writer_identity} \ --roleroles/logging.bucketWriter可选在中心桶上创建自定义 Log Views所有源日志最终都落在同一个中心桶里。如果需要按日志 ID 或来源项目做分区、或按视图收敛访问权限可以在中心桶上创建自定义 Log Views按日志 ID 过滤gcloud logging views create {view_id} \ --bucket{bucket_id} \ --location{region} \ --project{central_project_id} \ --log-filterLOG_ID({log_id})按来源项目过滤{view_id}是新建视图的 IDgcloud logging views create {view_id} \ --bucket{bucket_id} \ --location{region} \ --project{central_project_id} \ --log-filterproject_id{source_project_id}验证确认日志已路由到中心桶在源项目写一条测试日志gcloud logging write {test_log_id} Test log entry for verification \ --severityWARNING \ --project{source_project_id}从中心日志桶读取这条测试日志。对区域性日志桶必须带--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}如果这条测试日志能从中中心桶读出说明源项目到中心桶的路由链路已经打通。日志没有出现在中心桶时文档把排查收敛为两个检查点按顺序走核对源资源上 sink 的过滤条件。两个已知的坑标准过滤表达式如logName:abc或logNameprojects/{project_id}/logs/abc在 log sink 里可能匹配失败文档要求精确匹配时始终使用LOG_ID(abc)形式。检查排除过滤器exclusion是否意外把目标日志丢弃了。核对并补授写者身份权限——文档标注这是最常见的原因。源 sink 的写者身份服务账号必须显式获得中心资源上的权限先用上面的gcloud logging sinks describe ... --formatvalue(writerIdentity)拿到身份再对 Cloud Logging 桶授予roles/logging.bucketWritergcloud projects add-iam-policy-binding {central_project_id} \ --member{writer_identity} \ --roleroles/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
