New

The executive guide to generative AI

Read more

告警生产注意事项

编辑

告警将规则检查和操作作为由任务管理器管理的持久后台任务运行。

当依赖规则和操作作为关键任务服务时,请确保遵循任务管理器的生产注意事项

运行后台规则检查和操作

编辑

Kibana 使用后台任务来运行规则和操作,这些任务分布在集群中的所有 Kibana 实例上。

默认情况下,每个 Kibana 实例以三秒的间隔轮询工作,并且最多可以同时运行十个并发任务。然后这些任务在 Kibana 服务器上运行。

规则是周期性后台任务,会根据完成时的检查间隔重新安排。操作是非周期性后台任务,在完成后会被删除。

有关任务管理器的更多详细信息,请参阅运行后台任务

规则和操作任务可能会延迟运行或以不一致的时间表运行。这通常是集群特定使用情况的症状。

您可以通过调整任务管理器设置或扩展部署以更好地适应您的用例来解决此类问题。

有关详细指南,请参阅告警故障排除

扩展指南

编辑

由于规则和操作利用后台任务来执行大部分工作,因此可以通过遵循任务管理器扩展指南来实现告警的扩展。

在估计所需的任务吞吐量时,请记住以下几点

  • 每个规则使用一个定期任务,该任务计划按照其检查间隔定义的节奏运行。
  • 每个操作使用一个任务。但是,由于操作是按实例进行的,因此告警可能会生成大量的非定期任务。

很难预测需要多少吞吐量才能确保所有规则和操作都以一致的时间表执行。通过将规则计为定期任务,将操作计为非定期任务,可以粗略估计吞吐量可以估计为*每分钟任务数*的度量。

预测处理操作所需的缓冲区在很大程度上取决于您使用的规则类型、它们可能检测到的告警数量以及您可能选择分配给操作组的操作数量。考虑到这一点,请定期监控您的任务管理器实例的运行状况。

事件日志索引生命周期管理

编辑

此功能处于技术预览阶段,可能会在未来版本中更改或删除。Elastic 将努力解决任何问题,但技术预览中的功能不受官方 GA 功能的支持 SLA 的约束。

告警和操作会将活动记录在一组“事件日志”数据流中,每个 Kibana 版本一个,命名为 .kibana-event-log-{VERSION}。这些数据流配置了 90 天的生命周期数据保留。可以通过标准数据流生命周期 API 将其更新为其他值。请注意,事件日志数据包含 Kibana 告警页面中显示的数据,因此缩短数据保留期将导致可查看的数据减少。

有关数据流生命周期管理的更多信息,请参阅:数据流生命周期

熔断器

编辑

在某些情况下,运行告警规则和操作可能会开始对 Kibana 实例的整体运行状况产生负面影响,这可能是由于阻塞任务管理器吞吐量,或者消耗了过多的 CPU/内存,导致其他操作无法在合理的时间内完成。有几个可配置的熔断器可以帮助最大限度地减少这些影响。

间隔非常短的规则

编辑

以非常短的间隔运行大量规则可能会迅速阻塞任务管理器吞吐量,导致更高的计划漂移。使用 xpack.alerting.rules.minimumScheduleInterval.value 设置规则的最小计划间隔。此配置的默认值(也是推荐值)为 1m。使用 xpack.alerting.rules.minimumScheduleInterval.enforce 指定是否严格强制执行此最小值。虽然此设置的默认值为 false 以保持与现有规则的向后兼容性,但请将此设置为 true 以防止新的和更新的规则以低于最小值的间隔运行。

另一个相关设置是 xpack.alerting.rules.maxScheduledPerMinute,它限制每分钟可以运行的规则数量。例如,如果设置为 400,则可以有 400 个检查间隔为一分钟的规则或 2,000 个检查间隔为 5 分钟的规则。如果其检查间隔会导致超过此设置,则无法创建或编辑规则。为了保持在此限制内,请删除或禁用某些规则,或者更新检查间隔,以便您的规则运行频率较低。

运行时间较长的规则

编辑

运行时间较长的规则通常是因为它们发出资源密集型 Elasticsearch 查询或执行 CPU 密集型处理。这可能会阻塞事件循环,使 Kibana 在规则运行时无法访问。默认情况下,规则处理在 5m 后取消,但可以使用 xpack.alerting.rules.run.timeout 配置覆盖此值。也可以使用 xpack.alerting.rules.run.ruleTypeOverrides 为每个规则类型配置此值。例如,以下配置将全局超时值设置为 1m,同时允许索引阈值规则在取消之前运行 10m

xpack.alerting.rules.run:
  timeout: '1m'
  ruleTypeOverrides:
    - id: '.index-threshold'
      timeout: '10m'

当规则运行被取消时,运行期间生成的任何告警和操作都将被丢弃。此行为由 xpack.alerting.cancelAlertsOnRuleTimeout 配置控制,默认值为 true。将其设置为 false 以在超时后接收告警和操作,但请注意,这些告警和操作可能不完整,并且可能不准确。

生成过多操作的规则

编辑

生成过多操作的规则可能会迅速阻塞任务管理器吞吐量。如果出现以下情况,则可能发生这种情况

  • 配置了单个操作的规则会生成许多告警。例如,如果配置为运行单个电子邮件操作的规则生成 100,000 个告警,则将在运行期间计划 100,000 个操作。
  • 配置了多个操作的规则会生成告警。例如,如果配置为运行电子邮件操作、服务器日志操作和 Webhook 操作的规则生成 30,000 个告警,则将在运行期间计划 90,000 个操作。

使用 xpack.alerting.rules.run.actions.max 限制规则每次运行可以生成的最大操作数。也可以使用 xpack.alerting.rules.run.actions.connectorTypeOverrides 按连接器类型配置此值。例如,以下配置将全局最大操作数设置为 100,同时允许具有电子邮件操作的规则生成最多 200 个操作。

xpack.alerting.rules.run:
  actions:
    max: 100
    connectorTypeOverrides:
      - id: '.email'
        max: 200
Was this helpful?
Feedback