📚 课程目录第4章 Ruler组件详解

4. Ruler组件详解：Ruler在Loki中的位置、规则评估周期、与Alertmanager的通信

Ruler 是 Loki 可观测性体系中负责规则评估与告警生成的核心组件。它持续从 Querier 或 Index Gateway 获取日志流，依据用户定义的告警规则或记录规则进行周期性评估，并将触发的告警转发至 Alertmanager。理解 Ruler 的内部架构、评估周期以及通信机制，是配置可靠告警路由与性能调优的前提。

4.1 Ruler在Loki架构中的位置

Ruler 在逻辑上位于查询层与告警通知层之间。它不直接参与日志写入，而是依赖 Querier 提供的数据进行规则计算。在微服务部署模式下，Ruler 通常作为独立组件运行，也可与 Querier 或 Distributor 合并部署（不推荐生产环境）。

  关键定位： Ruler 是“规则引擎”而非“数据存储节点”。它从存储层读取数据，向 Alertmanager 输出告警事件。

4.2 规则评估周期

Ruler 使用固定间隔轮询的方式执行规则评估。每个规则组（Rule Group）可以独立配置评估间隔，但所有规则共享 Ruler 实例的全局并发限制。

4.2.1 评估周期配置

配置项	默认值	说明	推荐生产值
`ruler.evaluation_interval`	1m	全局默认评估间隔，所有规则组未指定时使用此值	30s – 2m
`ruler.poll_interval`	1m	Ruler 从存储重新加载规则文件的间隔	1m – 5m
`ruler.evaluation_concurrency`	10	同时评估的规则组数量上限	10 – 50（视规则复杂度）
`ruler.max_rules_per_rule_group`	20	单个规则组内允许的最大规则数	10 – 30

4.2.2 评估流程

规则加载： Ruler 在启动时及每次 poll_interval 到达时，从配置的规则存储（本地文件、对象存储或 ConfigDB）读取所有规则组。
调度队列： 每个规则组被分配一个评估时间槽。Ruler 维护一个优先级队列，按 next_evaluation_time 排序。
并发执行： 工作协程从队列中取出到期的规则组，执行 LogQL 查询并计算告警条件。并发数受 evaluation_concurrency 限制。
结果处理： 若规则触发，Ruler 生成告警事件（包含标签、注解、时间戳），写入内存中的告警缓存。
发送告警： 每轮评估结束后，Ruler 将新触发的告警批量发送至 Alertmanager。

性能调优要点： 如果规则组数量多且评估间隔短（如 <15s），建议增大 evaluation_concurrency 并确保 Querier 有足够的查询吞吐。同时，避免在单个规则组中放置超过 20 条规则，防止单次评估超时。

4.3 与Alertmanager的通信

Ruler 与 Alertmanager 之间采用HTTP/HTTPS 推送模式。Ruler 作为客户端，将告警事件以 JSON 格式 POST 到 Alertmanager 的 /api/v1/alerts 端点。

4.3.1 通信配置

# ruler 配置段
ruler:
  alertmanager_url: http://alertmanager:9093
  # 支持多实例负载均衡
  alertmanager_url: 
    - http://alertmanager-1:9093
    - http://alertmanager-2:9093
  # 告警发送超时
  alertmanager_timeout: 10s
  # 告警重试间隔
  alertmanager_retry_interval: 15s
  # 是否启用告警发送
  enable_alertmanager: true
  # 外部标签，附加到所有告警
  external_labels:
    cluster: prod-us-east
    env: production

4.3.2 告警事件格式

Ruler 发送的告警负载遵循 Prometheus Alertmanager API 格式：

[
  {
    "labels": {
      "alertname": "HighErrorRate",
      "severity": "critical",
      "job": "nginx",
      "cluster": "prod-us-east"
    },
    "annotations": {
      "summary": "Nginx 5xx 错误率超过 5%",
      "description": "过去5分钟，job=nginx 的 5xx 错误率为 {{ $value }}%"
    },
    "startsAt": "2025-03-15T10:30:00Z",
    "endsAt": "2025-03-15T10:35:00Z",
    "generatorURL": "http://loki-ruler:3100/..."
  }
]

4.3.3 通信可靠性机制

机制	说明	配置项
重试	发送失败时按指数退避重试，最多重试 3 次	`alertmanager_retry_interval`
负载均衡	多 Alertmanager 地址时，Ruler 随机选择实例发送	`alertmanager_url` 列表
告警去重	Ruler 在内存中维护告警指纹，相同告警不会重复发送	内置，无需配置
健康检查	Ruler 定期探测 Alertmanager 的 `/-/healthy` 端点	内置，每 30s
外部标签	所有告警自动附加 `external_labels`，用于路由匹配	`external_labels`

4.4 多租户与Ruler隔离

在 Loki 多租户环境中，每个租户拥有独立的规则命名空间。Ruler 通过 X-Scope-OrgID 头部区分租户，确保告警规则和评估结果严格隔离。

规则存储隔离： 租户规则文件存储在对象存储的不同前缀下（如 rules/tenant-a/）。
评估隔离： Ruler 为每个租户维护独立的评估队列，一个租户的规则超载不会阻塞其他租户。
告警隔离： 发送至 Alertmanager 时，Ruler 在告警标签中注入 tenant_id，Alertmanager 可根据该标签进行路由。

注意： 如果启用了多租户，务必在 Alertmanager 的 inhibit_rules 和 route 配置中考虑 tenant_id 标签，避免跨租户告警抑制或路由错误。

4.5 性能调优建议

评估间隔与查询范围匹配： 如果规则使用 rate[5m]，评估间隔设为 1m 即可；若使用 rate[1m]，评估间隔可缩短至 15s–30s。
避免高基数标签： 规则中的 group_left 或 on() 操作会显著增加评估耗时，尽量使用精确匹配。
监控 Ruler 自身指标： 关注 cortex_ruler_evaluation_duration_seconds、cortex_ruler_queries_total 和 cortex_ruler_alerts_sent_total。
水平扩展： 当规则数超过 500 条或评估间隔 <30s 时，建议部署多个 Ruler 实例，并通过 hashring 配置分片。