Google Cloud Logging API 100%错误率与Log Explorer日志不匹配问题排查

先定位请求发起者 #

因为Log Explorer里没显示这些google.logging.v2.LoggingServiceV2.WriteLogEntries的403请求，得先找到是谁在发这些请求：

• 打开Cloud Monitoring的Metrics Explorer，选logging.googleapis.com/api/request_count指标，添加auth.principal和resource.type维度，就能看到发起请求的主体（服务账号、用户）和对应的资源类型。
• 去Cloud Audit Logs的Data Access日志里，过滤方法名等于google.logging.v2.LoggingServiceV2.WriteLogEntries、状态码403的条目，这里能看到请求的详细信息，包括发起者、目标资源、具体错误原因。

分析403的核心原因 #

常见的触发原因有这几种：

• 发起请求的身份（服务账号/用户）没有logging.logEntries.create权限，或者没有目标日志桶的写入权限。
• 尝试跨项目写入日志，但目标项目没给对应身份授权。
• 启用了VPC Service Controls，请求来自边界外且没配置允许规则。

针对性修复 #

• 权限不足：给发起请求的身份添加Logs Writer角色（roles/logging.logWriter），或者更细粒度的logging.logEntries.create权限，注意要把权限绑定到目标日志项目或日志桶上。
• 跨项目写入问题：要么给目标项目的身份授权，要么调整请求的目标项目到正确的项目下。
• VPC Service Controls限制：检查访问边界的规则，把发起请求的资源或身份加入允许列表，或者确保请求在VPC边界内发起。

清理无效请求 #

• 如果这些请求来自配置错误的服务（比如旧的Cloud Function、闲置VM），直接停用服务或者修复日志写入配置。
• 如果是异常请求，可通过IAM条件限制允许发起请求的IP范围，或者删除不必要的身份密钥。

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