4. 告警规则引擎：Ruler组件原理、基于LogQL的告警规则编写、评估间隔与延迟

4.1 Ruler组件架构与职责

Loki的Ruler组件是告警与记录规则的核心执行引擎。它负责周期性地评估用户定义的规则，当规则条件满足时，将告警推送到Alertmanager或生成新的指标数据。理解Ruler的内部工作原理，是编写高效、可靠告警规则的前提。

4.2 基于LogQL的告警规则编写

Loki告警规则使用YAML格式定义，核心是LogQL查询表达式。与PromQL不同，LogQL操作的是日志流而非指标，因此需要特别关注日志速率、计数和聚合函数的使用。

4.2.1 规则文件结构

groups:
  - name: example_alert_group
    interval: 30s
    limit: 10
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate({app="nginx"} |= "ERROR" [5m])) 
          / 
          sum(rate({app="nginx"} [5m])) > 0.05
        for: 2m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "Nginx 错误率超过 5%"
          description: "当前错误率: {{ $value | humanizePercentage }}"

4.2.2 常用告警模式与LogQL示例

4.3 评估间隔与延迟

评估间隔和延迟是影响告警实时性与系统负载的关键参数。配置不当可能导致告警风暴或漏报。

4.3.1 评估间隔（Interval）

评估间隔定义了Ruler对每条规则执行LogQL查询的频率。它可以在全局配置和规则组级别设置，规则组级别的设置会覆盖全局配置。

• 全局默认值：通常为 1m（1分钟），适用于大多数场景。
• 规则组覆盖：对于需要快速响应的告警（如高错误率），可设置为 15s 或 30s。
• 性能考量：评估间隔越短，Ruler和Loki查询前端的负载越高。对于聚合查询（如 sum(rate(...))），过短的间隔可能导致查询结果波动较大。

4.3.2 评估延迟（Evaluation Delay）

评估延迟是一个反直觉但极其重要的参数。它告诉Ruler在评估规则时，查询的时间范围要向后偏移一个固定的时间量。

配置示例：

# ruler.yml 全局配置
ruler:
  evaluation_interval: 30s
  evaluation_delay: 30s  # 查询时，将时间窗口向后偏移30秒

# 规则组级别覆盖
groups:
  - name: critical_alerts
    interval: 15s
    limit: 20
    rules:
      - alert: ...

4.3.3 参数对比与最佳实践

4.4 规则评估的生命周期

理解一条规则从加载到触发告警的完整流程，有助于排查告警未触发或误触发的问题。

1. 规则加载：Ruler启动或配置热加载时，从存储后端读取规则文件，解析为内存中的规则树。
2. 定时触发：根据规则组的 interval，调度器触发一次评估任务。
3. 查询执行：Ruler构造LogQL查询，应用 evaluation_delay 偏移时间范围，发送至Loki查询前端。
4. 结果处理：将查询返回的瞬时向量与规则中的阈值进行比较。如果满足条件，记录为“待触发”状态。
5. 持续时间检查：检查该告警是否已持续满足条件超过 for 字段指定的时长。如果是，则转为“触发”状态。
6. 告警发送：将触发的告警（包含标签和注解）通过HTTP API发送至Alertmanager。