如何查找Storage API中HTTP Batch使用及捕获废弃API调用日志？

我之前也碰到过类似的麻烦，当Google宣布废弃Global Batch Endpoints时，面对一堆存储桶和五花八门的访问工具，排查起来确实有点头大。下面是我亲测有效的方法，帮你定位废弃调用并揪出源头：

1. 从现有存储桶日志里区分批量请求 #

你已经开了存储桶日志，其实里面藏着区分批量和单请求的关键特征，只是需要针对性过滤：

• 看request_url：Global Batch Endpoint的请求路径必然包含/batch/storage/v1，这是最直接的标识；
• 查请求头：批量请求的Content-Type一定是multipart/mixed; boundary=xxx，可以在日志的request_headers字段里找到这个信息；
• 找响应警告：废弃端点返回的响应通常会带Warning头，比如Warning: 299 - "Deprecated API: This endpoint is deprecated and will be removed in the future."，在response_headers里能看到这个提示。

用Cloud Logging的过滤器快速筛选这些请求：

resource.type="gcs_bucket"
(protoPayload.requestUrl:"/batch/storage/v1" OR protoPayload.responseHeaders.Warning:"Deprecated")

2. 精准定位调用来源 #

找到批量请求后，下一步就是追踪是哪个工具在发起：

• 看身份信息：日志里的protoPayload.authenticationInfo.principalEmail会显示发起请求的服务账号或用户邮箱，比如如果是某个CI/CD工具专用的服务账号，一眼就能对应上；
• 查IP地址：protoPayload.requestMetadata.callerIp是发起请求的机器IP，结合你内部的工具IP清单，能快速锁定是哪台服务器或服务在调用；
• 识别客户端库：protoPayload.requestHeaders.User-Agent会标注客户端库的信息，比如google-api-java-client/1.34.1或者gsutil/5.23，这能帮你判断是官方客户端库还是gsutil这类工具发起的请求。

3. 进阶追踪手段（如果日志信息不够） #

如果上面的信息还不足以定位，试试这些方法：

• 开启Cloud Trace：给GCS操作启用Trace后，能看到完整的调用链，如果这些请求来自你的应用服务，Trace能直接关联到具体的代码方法，帮你快速找到废弃调用的代码位置；
• 临时升级日志粒度：暂时调整存储桶日志配置，开启完整的请求头和响应头记录（默认可能只记录部分字段），这样能拿到更多细节，但注意不要长期开启，避免日志量爆炸；
• 逐个排查工具：如果工具数量不多，可以临时关停部分工具，观察废弃请求是否消失，逐步缩小范围找到源头。

4. 顺便提下迁移建议 #

既然这些端点要废弃了，找到来源后尽快迁移：

• 替代Global Batch Endpoint的最佳方式是使用客户端库的批量操作支持（比如Python客户端库的Batch类），或者改用并行发送单个请求，性能上差异不大；
• 检查所有工具的客户端库版本，旧版本的库可能默认使用废弃端点，升级到最新版后会自动切换到新的合法端点。

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