5

我正在使用 Cloud Run 和 Cloud Tasks 对 webhook 进行一些异步处理。当我收到对我的 Cloud Run 服务的请求时，我会在我的 Cloud Tasks 队列中排队一个任务，并立即从我的服务返回响应。然后，Cloud Tasks 将再次触发我的服务（不同的端点）并进行一些处理。我想通过使用相同的跟踪 ID 来关联这些步骤中的所有日志，但它不起作用。

在 Cloud Tasks 中创建任务时，我请求它发送标头并用原始请求的标头值X-Cloud-Trace-Context填充它。X-Cloud-Trace-Context从理论上讲，当请求来自 Cloud Tasks 到我的 Cloud Run 服务时，它应该具有此标头值，并且我的所有日​​志都将正确关联。但是，当第二个请求到来时，Cloud Run 似乎正在使用新的跟踪 ID 覆盖标头。

有没有办法防止这种情况发生？如果不是，在上述步骤中关联所有日志（由服务代码生成以及由 GCP 自动生成的日志）的推荐解决方案是什么？

谢谢您的帮助！

4

2 回答 2

0

我不认为您可以覆盖 Cloud Tasks 设置的 HTTP 标头，但您可以覆盖trace发送到 Stack Driver 的日志记录中的成员。

因此，您可以在任务负载中包含原始跟踪 ID，然后覆盖trace执行实际工作的 Cloud Run 端点生成的日志中的 ID。

于 2021-05-28T15:02:13.990 回答
0

我们发现将 traceparent 标头传递到云任务中是可行的。跟踪 id 被保留，cloudrun 会自动分配一个新的 span/parent id。

 task = {
     "http_request": {
         "url": url,
         "headers": {
             "traceparent": request.headers.get('traceparent', "")
         }
     }
 }

请注意，它似乎也适用于“X-Cloud-Trace-Context”，但您必须拆分值并仅传递跟踪 ID（例如 cloudrun 标头值类似于“trace_id/span_id;flags” - 你必须仅拆分 trace_id 并将其设置为任务标头值）。否则，似乎 cloudrun 认为标头无效，并且正如您所提到的，设置了一个全新的跟踪上下文。

作为相关说明 - 虽然这可以获得正确的标题，但您仍然需要以某种方式实际记录 trace_id 以便您的日志关联。在我看来，cloudrun 本身生成的日志就是这样做的，但我必须配置我的记录器，以便我的日志也可以关联。

于 2022-03-03T20:58:08.863 回答