【问题标题】:GCP EventArc : Response Code 500 when using PubSub trigger with Cloud RunGCP EventArc:将 PubSub 触发器与 Cloud Run 结合使用时的响应代码 500
【发布时间】:2022-01-27 18:09:12
【问题描述】:

我正在使用PubSub 使用EventArc 触发 Cloud Run。 PubSub 下标因此具有 Push Endpointhttps://<my cloud run url>/?__GCP_CloudEventsMode=CUSTOM_PUBSUB_projects%2F<my project ID>%2Ftopics%2F<my pubsub topic>。我注意到在测试大量消息时,我收到了"requestMethod": "POST", "status": 500, "requestUrl": "https://<my cloud run url>/?__GCP_CloudEventsMode=CUSTOM_PUBSUB_projects%2F<my project ID>%2Ftopics%2F<my pubsub topic>" 的一些消息。消息已重新传递并因此得到处理。但是,我想知道我收到此消息的原因以及如何防止它发生。你能帮忙吗?

编辑: 完整的错误日志

{
  "insertId": "61cc8fbf0000cbfca245d9e8",
  "httpRequest": {
    "requestMethod": "POST",
    "requestUrl": "https://<my cloud run url>/?__GCP_CloudEventsMode=CUSTOM_PUBSUB_projects%2F<my project ID>%2Ftopics%2F<my pubsub topic>",
    "requestSize": "2125",
    "status": 500,
    "responseSize": "807",
    "userAgent": "APIs-Google; (+https://developers.google.com/webmasters/APIs-Google.html)",
    "remoteIp": "< hidden>",
    "serverIp": "< hidden>",
    "latency": "0.026223558s",
    "protocol": "HTTP/1.1"
  },
  "resource": {
    "type": "cloud_run_revision",
    "labels": {
      "location": "us-central1",
      "project_id": "<my project ID>",
      "configuration_name": "<config id>",
      "service_name": "<service name>",
      "revision_name": "<service revision name>"
    }
  },
  "timestamp": "2021-12-29T16:41:35.052220Z",
  "severity": "ERROR",
  "labels": {
    "instanceId": "<instance ID>"
  },
  "logName": "projects/<my project ID>/logs/run.googleapis.com%2Frequests",
  "trace": "projects/<my project ID>/traces/aff551446a5eb4d6e32cf6fe0b43dbbe",
  "receiveTimestamp": "2021-12-29T16:41:35.135561206Z"
}

【问题讨论】:

  • 您在哪里看到错误 500?在云上运行?别处?你能分享完整的错误吗?
  • 已用完整的错误消息更新了问题。我在 Cloud Run 日志中看到此错误。
  • 您的邮件是在 500 错误代码后重新发送的,后来得到了处理,对吗?
  • 这是一个云运行问题,我猜在你的代码中。
  • @Priyashree - 是的

标签: google-cloud-platform cloud google-cloud-pubsub google-cloud-run event-arc


【解决方案1】:

你为什么会收到这条消息?

当 Pub/Sub 将消息传递到推送端点时,Pub/Sub 会在 POST 请求的正文中发送消息。请求的主体是一个 JSON 对象,消息数据在 message.data 字段中。要接收来自推送订阅的消息,请使用 webhook 并处理 Pub/Sub 发送到推送端点的 POST 请求。推送端点必须是可公开访问的 HTTPS 地址。推送端点的服务器必须具有由证书颁发机构签署的有效 SSL 证书。 Pub/Sub 服务将消息传递到来自 Pub/Sub 服务存储消息的同一 Google Cloud 区域的推送端点。

102、200、201、202、204 等成功代码确认 Pub/Sub 消息已完成处理。除 HTTP 400 或 500 之外的任何代码都将导致否定确认。如果您发送否定确认或确认截止日期已过,Pub/Sub 会重新发送消息。

从这个documentation, 如果推送订阅者发送否定确认(如您的情况),则 Pub/Sub 可能会使用推送退避来传递消息。当 Pub/Sub 使用推送退避时,它会停止传递消息 100 毫秒到 60 秒,然后再次开始传递消息。推送退避是一种指数退避,可防止推送订阅者接收它无法处理的消息。 Pub/Sub 停止传递消息的时间量取决于推送订阅者发送的否定确认的数量,或者如果设置为默认 PubSub 将尝试立即重新发送消息。但是,在使用立即重新传递时,阻止消息确认的条件可能来不及更改,导致消息再次未确认,the message being continuously redelivered

我们可以做些什么来防止它发生?

  1. 如果确认截止日期到期或订阅者以否定确认响应,Pub/Sub 可以使用指数退避再次发送消息。如果未设置重试策略,Pub/Sub 会在确认截止日期到期或订阅者以否定确认响应后立即重新发送消息。所以你应该继续设置最小回退持续时间(不要保持默认)并将默认最大回退持续时间保持为 600 秒。

  2. 10 秒是默认的确认截止时间。最长为 10 分钟。我们可以将确认截止日期增加到默认值以上,这样我们的消息就不会过期。

  3. 如果预计您的所有消息都需要更长的时间来处理,那么最好增加确认截止日期。如果只有几条消息会很慢,而大部分消息会很快处理,那么最好使用modifyAckDeadline 调用来增加每条消息的确认截止日期。

检查您的推送订阅是否为uses authentication。如果是,则 Pub/Sub 服务应签署 JSON Web Token (JWT) 并在推送请求的授权标头中发送 JWT。 JWT 应包含声明和签名。

  • 声明必须准确。
  • Pub/Sub 服务应签署声明。

如果订阅者使用防火墙,他们将无法接收推送请求。要接收推送请求,您必须关闭防火墙并验证 JWT。

  • 您还必须授予 Pub/Sub 创建令牌所需的权限 为您的服务帐户。 Pub/Sub 为您的项目创建并维护一个 special service accountservice-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com哪里 {PROJECT_NUMBER} 是包含订阅的项目。这 服务帐户需要Service Account Token Creator role。如果你 使用 Cloud Console 设置推送订阅 身份验证或您使用 2021 年 4 月 8 日之后创建的项目, 角色作为Pub/Sub service agent role 的一部分自动授予。否则,您必须将explicitly grant 角色分配给 帐户。也是配置了服务帐户的推送订阅 应该具有角色roles/run.invoker,它将它绑定到特定的 可以调用 Cloud Run 服务的 Cloud Run 服务。

【讨论】:

  • 感谢 Priyashree。问题出在一些消息上,而不是全部。
  • 如果您的所有消息预计需要更长的时间来处理,那么最好增加确认截止日期。如果只有几条消息会很慢,而大部分消息会被快速处理,那么最好使用modifyAckDeadline 调用来增加每条消息的确认截止日期。
猜你喜欢
  • 2021-10-12
  • 2021-04-21
  • 2022-08-19
  • 2021-02-17
  • 2022-08-05
  • 2020-11-24
  • 2021-12-28
  • 1970-01-01
  • 2020-02-10
相关资源
最近更新 更多