【问题标题】:How can I get a reliable alert via Stackdriver when there are no clients pulling from a Pub/Sub subscription?当没有客户端从 Pub/Sub 订阅中拉出时,如何通过 Stackdriver 获得可靠的警报?
【发布时间】:2019-12-21 15:41:31
【问题描述】:

我目前设置了一些警报以在 subscription/pull_request_count 为 0 时进行报告。但是,在 similar question about that metric 中,我发现一旦没有数据,指标和警报就会中断,我相信这会在没有订阅时发生。

我的目的是确定我的服务器是否已停止提取消息。我想到了 2 个场景,其中细节很重要。

  1. 即使没有发布消息,我也想知道我是否不再退出订阅以确保一切正常。
  2. 如果大量未确认的消息仅仅因为我拉出它们但没有确认它们而排队(例如合作伙伴 API 已关闭),我不希望触发此警报

除了使用subscription/pull_request_count 作为条件,当没有数据进入时(至少在一段时间后)将不起作用,我如何设置一个警报,通知我没有客户从 Pub/订阅?

【问题讨论】:

  • 您真的想检查是否没有客户端从 Pub/Sub 订阅中拉取,还是只想检查是否有未传递的消息,因为没有客户端从订阅中拉取(否客户端 => 未传递的消息)?
  • 好问题。我的目的是弄清楚我的服务器是否已停止提取消息。我想到了两种情况,其中细节很重要。 1) 即使没有发布消息,我也想知道我是否不再退出订阅以确保一切正常。 2) 即使大量未确认的消息被排队只是因为我拉了它们但没有确认它们(例如合作伙伴 API 已关闭),我不希望触发此警报。
  • 好的,所以根据你的 2 个场景,很遗憾你不能使用像 num_undelivered_messages 这样的另一个指标。您应该在问题中包含这些用例,因为它们非常相关!无论如何,subscription/pull_request_count 似乎是您要在此处使用的指标。你有没有发现为什么这个指标有时不生成数据?你能澄清一下“alerting break 一旦没有数据”是什么意思吗?是否触发了警报?您的警报现在是如何配置的?请将这些信息添加到您的问题中,它可能有助于其他人了解发生了什么。
  • 我已将这些示例添加到问题中。有关警报中断的详细信息,请参阅我的问题中指向我最近发布的问题的链接,其中 GCP 支持提到该指标意味着缺少数据。
  • 为什么不使用is absent 而不是is under 1 作为策略条件?不过,最小值似乎是 3 分钟。

标签: google-cloud-pubsub stackdriver google-cloud-stackdriver


【解决方案1】:

由于您希望在没有拉取消息操作时收到警报,因此您必须使用 subscription/pull_request_count 指标。如果一段时间后,指标被删除而不是报告 0 拉动,您可以使用两个条件:is absent for 3 minutesis below 1 for 1 minute

但是,这里的问题是 UI 过滤掉了所有未使用的资源和指标(过去 6 周)。虽然这极大地简化了设置警报和浏览运行操作的指标,但它需要一种不同的方法来在系统投入生产之前创建新警报。最简单的解决方案是进行虚拟订阅并拉取消息,以便显示指标。

但您仍然可以使用 Stackdriver Monitoring API 来设置它们(我实际上在过去几个月没有实例的工作区中使用 Spanner 指标对此进行了测试)。请注意,提醒政策 API 位于 Beta 中,因此可能会发生不向后兼容的更改。

我建议首先使用 projects.alertPolicies/list 检查现有的策略,并查看 AlertPolicy 正文是如何构建的。

然后你可以设置一些初始变量:

TOKEN="$(gcloud auth print-access-token)"
PROJECT=$(gcloud config get-value project 2>\dev\null)
SUBSCRIPTION=PUBSUB_SUBSCRIPTION_ID
CHANNEL=NOTIFICATION_CHANNEL_ID

在我的例子中,我在整个示例中仅监控特定的 Pub/Sub 订阅,并且我已经有一个通知渠道(用于我的电子邮件)。由于您还有一个现有的策略,您可以获得通知渠道 ID here

使用projects.alertPolicies/create,您可以创建新的警报策略:

curl -X POST \
    -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://monitoring.googleapis.com/v3/projects/$PROJECT/alertPolicies" \
  -d @alert.json

alert.json 在哪里(根据需要替换变量):

{
  "displayName": "no-pull-alert",
  "combiner": "OR",
  "conditions": [
    {
      "conditionAbsent": {
        "filter": "metric.type=\"pubsub.googleapis.com/subscription/pull_request_count\" resource.type=\"pubsub_subscription\" resource.label.\"project_id\"=\"$PROJECT\" resource.label.\"subscription_id\"=\"$SUBSCRIPTION\"",
        "duration": "180s",
        "trigger": {
          "count": 1
        },
        "aggregations": [
          {
            "alignmentPeriod": "60s",
            "perSeriesAligner": "ALIGN_RATE"
          }
        ]
      },
      "displayName": "Pull requests absent for $PROJECT, $SUBSCRIPTION"
    },
    {
      "conditionThreshold": {
        "filter": "metric.type=\"pubsub.googleapis.com/subscription/pull_request_count\" resource.type=\"pubsub_subscription\" resource.label.\"project_id\"=\"$PROJECT\" resource.label.\"subscription_id\"=\"$SUBSCRIPTION\"",
        "comparison": "COMPARISON_LT",
        "thresholdValue": 1,
        "duration": "60s",
        "trigger": {
          "count": 1
        },
        "aggregations": [
          {
            "alignmentPeriod": "60s",
            "perSeriesAligner": "ALIGN_RATE"
          }
        ]
      },
      "displayName": "Pull requests are 0 for $PROJECT, $SUBSCRIPTION"
    }
  ],
  "documentation": {
    "content": "**ALERT**\n\nNo pull message operations",
    "mimeType": "text/markdown"
  },
  "notificationChannels": [
    "projects/$PROJECT/notificationChannels/$CHANNEL"
  ],
  "enabled": true
}

简而言之,您无需传递政策或条件 ID,因为这些 ID 将由 API 填充。使用 OR 作为组合器(满足任何条件时违反策略)以在指标不存在 (conditionAbsent) 或低于 1 (conditionThreshold) 时触发警报。当然,您可以修改参数以更好地适应您的用例、显示名称、描述等。

【讨论】:

  • 我在生产中使用了它,并在几天内收到了一些错误警报 - 每个持续几秒钟,这是由 is absent for 3 minutes 规则触发的,即使数据不缺席一点也不。我已经更新了缺席条件,改为使用 4 分钟窗口,此后没有收到任何误报。
  • 我最近切换到使用 Google Cloud Java JDK,它使用 StreamingPull 而不是 Pull 并进行持续轮询。虽然这在幕后更好、更高效,但它使事情更难监控,因为除了应用程序启动或消息进来时不会有任何 API 请求。不幸的是,这意味着在订阅时 '没有定期活动,我们可以使用的最佳指标是最旧消息的年龄,因此在发送消息之前我们不会知道是否没有订阅者。
猜你喜欢
  • 1970-01-01
  • 2018-03-13
  • 2021-04-21
  • 2021-01-11
  • 1970-01-01
  • 2019-06-17
  • 1970-01-01
  • 2018-11-13
相关资源
最近更新 更多