WEBKT

Grafana复合告警实战：CPU高负载与Elasticsearch错误日志激增的智能联动告警策略

131 0 0 0

你是否曾遇到过这样的困境：单一指标告警频繁误报，或者当真正的问题发生时，却因为多个看似独立的信号未能联动而错失最佳响应时机？在复杂的生产环境中，一个故障往往不是由单一事件触发，而是由多个条件共同构成。比如，CPU利用率飙升可能只是一个表象，如果同时伴随着某个核心服务的错误日志大量出现，那么这几乎可以确定是一个需要立即关注的问题。

传统的监控体系，往往将指标（Metrics）和日志（Logs）视为独立的两个世界，告警也多是各自为战。然而，Grafana的统一告警（Grafana Unified Alerting）功能，为我们提供了一个优雅的解决方案，能将这些看似孤立的数据源巧妙地结合起来，构建出更智能、更准确的复合告警策略。今天，我们就深入探讨如何在Grafana中实现这一目标，以“当CPU利用率超过阈值且Elasticsearch中出现大量错误日志时触发告警”为例，手把手教你配置流程与最佳实践。

为什么需要复合告警？

单一指标告警很容易产生“告警疲劳”，比如CPU瞬时升高可能是正常的流量波动，而大量错误日志可能只是偶发性的外部请求问题。但当两者同时发生时，其背后的系统稳定性问题就变得不容忽视。复合告警能够通过逻辑“与”（AND）或“或”（OR）等关系，极大地减少误报，提高告警的精准度，确保我们只在真正需要关注的事件上投入精力。

Grafana统一告警的核心能力

Grafana 9.x及更高版本引入的统一告警系统，是实现复合告警的关键。它将告警规则的定义、管理和通知集成到一个统一的界面中，并且允许在一个告警规则内引用来自不同数据源的多个查询结果。通过使用“表达式”（Expressions）功能，我们可以对这些查询结果进行数学或逻辑运算，从而构建复杂的告警条件。

场景实战：CPU + Elasticsearch 错误日志联动告警

设想一个场景：你的某个应用服务部署在多台服务器上，并将其性能指标（如CPU、内存）发送到Prometheus，同时将所有运行日志发送到Elasticsearch。现在，你想设置一个告警，当某台服务器的CPU利用率连续5分钟超过80%，并且在同一时间段内，Elasticsearch中该服务器相关服务的错误日志数量超过100条时，才触发告警。

前提条件：

  1. Grafana实例：已安装并正常运行。
  2. 数据源配置：
    • Prometheus数据源：用于收集和存储CPU利用率等系统指标（通常通过Node Exporter采集）。确保你可以在Grafana中查询到node_cpu_seconds_total这类指标。
    • Elasticsearch数据源：用于存储和查询应用程序日志。确保你可以在Grafana中查询到错误日志，例如通过level:error或message:*error*等查询条件。

现在，我们开始配置告警规则。

第一步：创建告警规则

  1. 在Grafana左侧导航栏中，点击“告警”（Alerting）图标，然后选择“告警规则”（Alert rules）。
  2. 点击右上角的“新建告警规则”（New alert rule）。
  3. 选择“Grafana管理告警”（Grafana managed alert）。

第二步：配置Prometheus查询（CPU利用率）

  1. 在“查询A”（Query A）部分：
    • 数据源选择：选择你配置好的Prometheus数据源。
    • PromQL查询：输入获取CPU利用率的PromQL查询。一个常见的计算CPU利用率（排除空闲时间）的例子是：
      1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
      这个查询会计算过去5分钟内，每个实例（服务器）的CPU非空闲时间占总时间的比例，即CPU利用率。结果将是一个0到1之间的浮点数。你可以根据需要调整mode标签或时间范围。
  2. 转换（Transform）：为了在后续表达式中使用一个单一的CPU值，我们需要对其进行聚合。
    • 在Query A下方，添加一个“减少”（Reduce）转换。
    • 模式（Mode）：选择“最新”（Last）。
    • 值（Value）：选择“平均值”（Mean）。这将把Prometheus查询结果（可能有多条时间序列）减少为一个单一的平均值。这个转换后的结果我们称之为 A。

第三步：配置Elasticsearch查询（错误日志数量）

  1. 在“查询B”（Query B）部分：
    • 数据源选择：选择你配置好的Elasticsearch数据源。
    • 查询（Query）：输入用于筛选错误日志的查询语句。例如：level:error AND hostname:your_server_name (你需要替换your_server_name为你监控的实例的hostname，或者使用变量使其更通用)。
    • 指标（Metrics）：选择“Count”。这会计算匹配查询条件的文档数量。
    • 时间间隔（Interval）：确保时间间隔与Prometheus查询的时间窗口（例如5分钟）相匹配，以便在相同的时间范围内进行比较。
  2. 转换（Transform）：与CPU查询类似，我们需要一个单一的日志计数。
    • 在Query B下方，添加一个“减少”（Reduce）转换。
    • 模式（Mode）：选择“最新”（Last）。
    • 值（Value）：选择“总和”（Sum）。这将聚合所有时间桶内的错误日志计数为一个总和。这个转换后的结果我们称之为 B。

第四步：使用表达式结合两个查询结果

现在，我们有了CPU利用率的单一值（来自A）和错误日志数量的单一值（来自B）。我们需要一个表达式来将它们用“与”逻辑关联起来。

  1. 在“查询C”（Query C）部分，选择**“表达式”（Expression）**作为类型。
    • 操作（Operation）：选择“数学”（Math）。
    • 表达式（Expression）：输入以下表达式：
      ($A > 0.8) && ($B > 100)
      • $A 引用的是我们从Prometheus查询并经过Reduce转换后的CPU平均利用率。
      • $B 引用的是我们从Elasticsearch查询并经过Reduce转换后的错误日志总数。
      • > 0.8 表示CPU利用率超过80% (0.8)。
      • > 100 表示错误日志数量超过100条。
      • && 是逻辑“与”操作符。这个表达式在 $A > 0.8 和 $B > 100 都为真时，将返回1（表示真），否则返回0（表示假）。

第五步：设置告警条件

  1. 在“告警条件”（Alert conditions）部分：
    • 条件选择：选择“查询C”作为评估对象。
    • 阈值设置：选择“高于”（Is above），并输入 0.5 作为阈值。
      • 解释：因为我们的表达式C在两个条件都满足时返回1，否则返回0。所以当C的值高于0.5时，就意味着告警条件成立。
  2. 告警评估间隔（Evaluate every）：设置告警规则的检查频率，例如1m（每1分钟）。
  3. 告警触发持续时间（For）：设置条件持续多久才真正触发告警。例如，设置为5m。这意味着CPU和错误日志条件必须同时满足并持续5分钟，告警才会真正发出。这有助于过滤掉瞬时波动。

第六步：配置通知

  1. 在“通知”（Notifications）部分：
    • 选择联系点（Contact points）：选择或创建一个联系点，例如Slack、Email、Webhook等。这里你需要预先配置好联系点。
    • 通知策略（Notification policy）：根据你的需求设置通知策略，例如是否静默、是否分组等。

第七步：保存告警规则

  1. 为告警规则起一个清晰的名称，例如“高CPU与ES错误日志复合告警”。
  2. 添加有意义的描述和标签。
  3. 点击“保存规则”（Save rule）。

至此，一个结合了Prometheus指标和Elasticsearch日志的复合告警规则就配置完成了！

复合告警的最佳实践

配置复合告警并非一劳永逸，还需要遵循一些最佳实践来确保其长期有效性和可靠性。

  1. 时间窗口对齐：确保所有涉及的查询和告警评估的时间窗口（例如rate函数的范围、Elasticsearch的聚合间隔、告警持续时间For）保持一致或合理对齐。这能避免因时间不匹配导致的误判。
  2. 阈值校准：告警阈值不是一成不变的，需要根据系统的实际运行情况和业务需求进行反复测试和调整。过高可能漏报，过低则可能导致告警疲劳。可以从历史数据中分析正常范围和异常峰值。
  3. 充分测试与验证：在生产环境上线前，务必在测试环境中模拟触发条件，验证告警是否能按预期工作，通知是否能准确送达。利用Grafana的“测试规则”（Test rule）功能非常有用。
  4. 提供丰富上下文：在告警通知中包含尽可能多的上下文信息，例如受影响的主机名、服务名称、具体的CPU利用率数值、错误日志的精确条数，甚至可以附带指向Grafana仪表盘或日志系统的链接。这能帮助值班人员快速定位问题。
  5. 告警静默与分组：利用Grafana的通知策略（Notification Policies）进行告警分组、静默和抑制。例如，当一个主要服务故障时，可能引发一系列次级告警，通过分组可以只发送一个主告警。
  6. 考虑性能开销：复杂的告警规则会增加Grafana服务器的负担，尤其是涉及大量数据源查询时。优化你的查询语句，确保它们高效运行。对于Elasticsearch查询，使用索引别名和合理的_source过滤可以提高效率。
  7. 清晰的命名与文档：为告警规则、联系点和通知策略使用清晰、一致的命名约定。为复杂的复合告警规则编写详细的文档，记录其触发逻辑、依赖关系和处理流程，这对于团队协作和后续维护至关重要。
  8. 考虑告警级别：根据复合告警的严重程度，设置不同的告警级别（如P1、P2），并将其映射到不同的通知渠道或通知策略，确保高优先级问题能被最快响应。

结语

通过Grafana的统一告警和强大的表达式功能，我们不再满足于单一维度的监控。将指标和日志等异构数据源结合起来，构建更具洞察力的复合告警，是提升系统可观测性和响应效率的关键一步。这不仅能减少无效告警的干扰，更能帮助我们更快、更准确地识别和解决生产环境中的复杂问题。拥抱这种更智能的告警策略，让我们的系统运维工作变得更加从容和高效。

监控老兵 Grafana告警复合告警PrometheusElasticsearch告警策略

评论点评