创建 Synthetics 监测状态规则

在 Synthetics UI 中，创建一个 Monitor Status 规则，以便根据错误和停机接收通知。

1. 要访问此页面，请转到 Synthetics → Overview。
2. 在页面顶部，点击 Alerts → Monitor status rule → Create status rule。

要创建 Synthetics 监测状态规则，您需要具备以下条件

• Synthetics 应用程序的权限。

此规则仅针对 synthetics-* 进行查询，且这是硬编码的。

Filter by 部分控制规则的范围。该规则将仅检查符合此部分定义的过滤条件的监测项。在此示例中，该规则仅针对位于 Asia/Pacific - Japan 的 browser 监测项发出告警。

×

每个规则的条件将应用于符合 Filter by 部分中过滤条件的所有监测项。您可以选择监测项处于 Down 状态的次数（相对于运行的检查次数或运行检查的时间范围），以及监测项必须处于 Down 状态的最少位置数。

Alert on no data（无数据时告警，可选）：启用此选项可在监测项处于 pending（待定）状态（即在评估期间未收到来自监测项的任何 Ping 数据）时接收告警。这有助于您检测已停止上报的监测项（例如由于配置错误、运行器故障或网络问题）。启用此选项时

• Pending 状态：如果在规则的评估窗口内未收到检查结果（Ping），则认为监测项处于待定状态。告警原因遵循以下格式：Monitor "X" from Location Y is pending.
• 恢复：一旦监测项再次上报数据（无论结果是 Up 还是 Down），告警就会自动恢复。无需单独的恢复操作。
• 操作变量：对于待定状态的告警，可以使用相同的操作变量（例如 context.monitorName、context.monitorId、context.locationName、context.monitorUrl 和 context.reason）。context.reason 和 context.message 字段反映待定状态以及监测项/位置的详细信息。

Rule schedule（规则调度）定义评估条件的频率。请注意，检查排队运行，并在容量允许的前提下尽量贴近定义的值运行。例如，如果检查计划每 2 分钟运行一次，但检查运行耗时超过 2 分钟，则在前一次检查完成之前不会运行新的检查。

在此示例中，无论在符合过滤条件的任何位置，只要 browser 监测项在最近 5 次运行中有 3 次处于 Down 状态，就会满足条件。这些条件将每分钟评估一次，并且只有在连续三次满足条件时，您才会收到告警。

×

您还可以设置 Advanced options（高级选项），例如

• Alert delay（告警延迟）：触发告警前必须符合规则条件的连续运行次数。

• Alert flapping detection（告警抖动检测）：检测在激活状态和恢复状态之间快速切换的告警，并减少此类抖动告警的干扰噪音。

  您还可以通过以下设置自定义配置

  • Rule run look back window（规则运行回溯窗口）：必须达到阈值的最小运行次数。

  • Alert status change threshold（告警状态更改阈值）：告警在回溯窗口内必须切换状态的最小次数。

×

通过将规则连接到使用以下支持的内置集成的操作，来扩展您的规则。

• 案例 (Cases)
• D3 Security
• 电子邮件
• IBM Resilient
• 索引
• Jira
• Microsoft Teams
• 可观测性 AI 助手
• Opsgenie
• PagerDuty
• 服务器日志
• ServiceNow ITOM
• ServiceNow ITSM
• ServiceNow SecOps
• Slack
• Swimlane
• Torq
• Webhook
• xMatters

选择连接器后，您必须设置操作频率。您可以选择在每个检查间隔或自定义间隔上创建告警摘要。例如，每小时发送一次汇总新告警、持续告警和已恢复告警的电子邮件通知

×

或者，您可以设置操作频率，以便选择操作运行的频次（例如，在每个检查间隔、仅当告警状态更改时或在自定义操作间隔）。在这种情况下，您还必须选择影响操作何时运行的具体阈值条件：Synthetics monitor status 发生更改，或者处于 Recovered（从 Down 变为 Up）。

×

您还可以通过指定仅当操作符合 KQL 查询或当告警发生在特定时间范围内时才运行操作，来进一步限定操作运行的条件

• If alert matches query（如果告警匹配查询）：输入定义字段值对或发送通知必须满足的查询条件的 KQL 查询。该查询仅搜索为该规则指定的索引中的告警文档。
• If alert is generated during timeframe（如果在时间范围内生成告警）：设置时间范围详细信息。仅当告警在您定义的时间范围内生成时才会发送通知。

×

使用默认通知消息或进行自定义。您可以通过点击消息文本框上方的图标并从可用变量列表中进行选择，从而为消息添加更多上下文。

当启用 Alert on no data（无数据时告警）且针对处于 pending 状态的监测项（未收到数据）触发告警时，告警文档包含监测项和位置的详细信息（如监测项名称、ID、类型、位置、标签、URL 以及错误信息，如果适用）。这些信息可通过下面列出的相同上下文变量获得；针对 pending 告警的 context.reason 使用以下格式：Monitor "X" from Location Y is pending.

×

以下变量特定于此规则类型。您也可以指定适用于所有规则的通用变量。

context.checkedAt

监测项运行的时间戳。

context.hostName

执行检查的位置的主机名。

context.lastErrorMessage

监测项最后一次错误消息。

context.locationId

执行检查的位置 ID。

context.locationName

执行检查的位置名称。

context.locationNames

执行检查的位置名称列表。

context.message

汇总当前处于 Down 状态的监测项状态的系统生成消息。

context.monitorId

监测项的 ID。

context.monitorName

监测项的名称。

context.monitorTags

与监测项关联的标签。

context.monitorType

监测项的类型（例如 HTTP/TCP）。

context.monitorUrl

监测项的 URL。

context.reason

告警原因的简要说明。

context.recoveryReason

恢复原因的简要说明。

context.status

监测项状态（例如 "down"）。

context.viewInAppUrl

在 Synthetics 应用中打开告警详细信息和上下文。

在 Uptime 应用中，创建一个 Monitor Status 规则，以便根据错误和停机接收通知。

1. 要访问此页面，请转到 Observability → Uptime。
2. 在页面顶部，点击 Alerts and rules → Create rule。
3. 选择 Monitor status rule。

您可以为规则指定以下阈值。

我们来为在 10 分钟内显示 Down 超过三次的任何监测项创建一个规则。

此规则涵盖您正在运行的所有监测项。您可以使用查询来指定特定监测项，也可以为每个监测项设置不同的条件。

×

创建规则的最后一步是选择触发告警时要采取的一个或多个操作。

您可以通过将规则连接到使用以下支持的内置集成的操作来扩展规则。操作是 Kibana 服务或与第三方系统的集成，当满足规则条件时，它们会在 Kibana 服务器上作为后台任务运行。

您可以在Settings（设置）页面上配置操作类型。

×

选择连接器后，您必须设置操作频率。您可以选择在每个检查间隔或自定义间隔上创建告警摘要。例如，每小时发送一次汇总新告警、持续告警和已恢复告警的电子邮件通知

×

或者，您可以设置操作频率，以便选择操作运行的频次（例如，在每个检查间隔、仅当告警状态更改时或在自定义操作间隔）。在这种情况下，您还必须选择影响操作何时运行的具体阈值条件：Uptime Down Monitor 或 Recovered。

×

使用默认通知消息或进行自定义。您可以通过点击消息文本框上方的图标并从可用变量列表中进行选择，从而为消息添加更多上下文。

×

要在告警恢复时接收通知，请选择 Run when Recovered。使用默认通知消息或进行自定义。您可以通过点击消息文本框上方的图标并从可用变量列表中进行选择，从而为消息添加更多上下文。

×

如果您当前将 Uptime 监测状态与通过 Elastic Synthetics 创建的监测项结合使用，您应该将 Uptime 监测状态规则迁移到

• 如果您将 Uptime 规则用于 Synthetics 监测状态检查，您可以使用 Synthetics 监测规则重新创建类似功能。
• 如果您将 Uptime 规则用于 Synthetics 监测可用性检查，Synthetics 监测规则中没有直接对应的规则。相反，您可以使用 Synthetics 可用性 SLI 来创建类似功能。

您在 Uptime 监测状态规则中使用的 KQL 语法在 Synthetics 监测状态规则的 Filter by 部分同样有效。Synthetics 监测状态规则还提供了几个类别的下拉菜单以便于过滤。但是，如果您愿意，仍可以对这些类别使用 KQL 语法。

如果您使用的是 Uptime 状态检查条件，您可以使用以下等效的 Synthetics 监测状态规则条件来重新创建类似效果

Uptime 监测状态规则和 Synthetics 监测状态规则的默认消息有所不同，但您可以使用 Synthetics 监测状态规则操作变量重新创建类似的消息。

SLO 允许您根据可用性等因素为服务性能设置清晰、可衡量的目标。Synthetics 可用性 SLI 是基于 Synthetics 监测项可用性的服务等级指标 (SLI)。

您在 Uptime 监测状态规则中使用的 KQL 语法在 Synthetics 可用性 SLI 的 Query filter 字段中同样有效。

使用以下 Synthetics 可用性 SLI 字段来替换 Uptime 监测状态规则的可用性条件

在使用 Synthetics 可用性 SLI 创建新的 SLO 后，您可以使用 SLO 消耗率规则。有关配置规则的更多信息，请参阅创建 SLO 消耗率规则。