如何实现GCP负载均衡HTTP日志在Cloud Logs Explorer与Cloud Trace集成

方案1：使用LB原生支持的采样识别特性（优先选择） #

这是当前成本最低、最稳定的解决方案，适配当前世代的Cloud Load Balancing产品：

• 首先确认你使用的不是已废弃的经典LB，当前世代的全球/区域内外LB均已支持该特性
• 确保所有进入LB的请求携带格式正确的X-Cloud-Trace-Context头，其中采样位（头字段值以/分割后的最后一位）设置为1，匹配你全量采样的业务规则
• 在LB的日志配置页面，开启「追踪字段包含」选项，开启后LB会自动识别请求中的采样标记，为符合要求的日志条目自动添加traceSampled属性，配置生效后新生成的LB日志就可以正常点击「显示trace详情」选项。

方案2：日志即时转换规则（轻量替代方案） #

如果你的LB版本暂不支持原生特性，可以使用Logging内置的日志入站转换功能，不需要额外部署服务，复杂度远低于你提到的兜底方案：

• 进入Cloud Logging的「日志路由器」页面，找到存储LB日志的对应sink（默认的_AllLogs sink即可，也可以单独为LB日志创建专用sink）
• 在sink配置中开启「在接收时修改日志条目」功能
• 添加如下转换规则：
  • 匹配条件：resource.type="http_load_balancer" AND trace!=""，筛选出存在trace字段的LB请求日志
  • 转换操作：entry.traceSampled = true，为匹配到的日志条目强制添加采样标记，如果你是部分采样场景，可以扩展匹配条件判断X-Cloud-Trace-Context头的采样位值，实现更精准的规则
• 保存配置后数分钟即可生效，新生成的LB日志会自动补全所需属性，没有额外的服务运维成本和链路延迟。

兜底方案 #

如果上述两个方案都无法适配你的场景，再考虑你提到的Logs Router投递到Pub/Sub + Cloud Function补全字段的方案，该方案适配性最高，但需要额外运维资源、产生额外服务成本，还会增加日志落盘的延迟。

内容的提问来源于stack exchange，提问作者Shabble