Thanos 架构剖析告警规则如何管理

Posted 2022-10-24

Thanos Rule 组件通过 thanos rule命令来启动，通过重复查询 Query 来评估告警是否触发 ，如果有多个 Query ，那么会通过轮询来保持平衡。

默认情况下，Rule 评估结果以 Prometheus 2.0 存储格式写回磁盘。同时，Rule 节点作为源存储节点参与系统，这意味着它们公开 StoreAPI 并将它们生成的TSDB块上传到对象存储中。

Rule 还有一个无状态模式，它通过远程写将 Rule 评估结果发送到一些远程存储，以获得更好的可伸缩性。这样的 Rule 节点只作为数据生产者工作，而远程接收节点作为源存储节点工作。Thanos Rule 在这个模式下不会公开 StoreAPI。

可以将 Rule 组件看作是一个简化的 Prometheus，它不需要 Sidecar 也不需要或者监控指标，只需要执行 PromQL 评估 ，所以也没有 QueryAPI。所以也可以对每个 Rule 节点的数据设置 label ，以满足集群的 label 方案。基于 Rule 的高可用性，多个 Rule 组件可以并行运行，并且用指定的 replica label 区分，就像普通的Prometheus 服务器一样。

Thanos Rule 组件的启动方式如下：

thanos rule \\
    --data-dir             "/path/to/data" \\
    --eval-interval        "30s" \\
    --rule-file            "/path/to/rules/*.rules.yaml" \\
    --alert.query-url      "http://0.0.0.0:9090" \\ # This tells what query URL to link to in UI.
    --alertmanagers.url    "http://alert.thanos.io" \\
    --query                "query.example.org" \\
    --query                "query2.example.org" \\
    --objstore.config-file "bucket.yml" \\
    --label                monitor_cluster="cluster1" \\
    --label                replica="A"

使用 Rule 的风险

使用 Rule 对用户来说最大的风险是可靠性。

对于 Rule 组件，他读取数据的路径是分布式，获取的数据有可能是从 Thanos Query 获取的，也有可能是通过 Thanos Store 获取的，这样就可能会存在查询失败的情况。

查询失败可能会导致告警没有第一时间触发，对于生产环境来说，这个情况的出现是不能接受的。但是对于 Prometheus 来说，一般是不会存在告警查询评估失败。当然对于跨 Prometheus 实例的聚合告警，还是需要 Rule 组件来支持和实现的。

Thanos 建议将 Prometheus 的告警规则保留在 Prometheus 的本地配置中，只在特殊 情况下使用 Thanos Rule 组件。

配置规则

Thanos Rule 的规则文件也是使用 YAML 格式，语法如下：

groups:
  - name: example
    rules:
    - record: job:http_inprogress_requests:sum
      expr: sum(http_inprogress_requests) by (job)
<rule_group>

# The name of the group. Must be unique within a file.
name: <string>

# How often rules in the group are evaluated.
[ interval: <duration> | default = global.evaluation_interval ]

rules:
  [ - <rule> ... ]

Thanos Rule 支持 告警规则和记录规则的配置，这个和 Prometheus 是一样的。

记录规则

记录规则可以预先计算经常需要的或计算代价很高的表达式，并将其结果保存为一组新的时间序列。因此，查询预先计算的结果通常比每次需要时执行原始表达式要快得多。这对于监控看板特别有用，因为每次刷新时都需要重复查询相同的表达式。

规则组中存在记录规则和告警规则。组内的规则按规则间隔顺序运行。

如果使用记录规则，请确保将 Thanos Rule 实例作为 Thanos Query 中的存储公开，以便可以将新的时间序列作为 Thanos Query 的一部分进行查询。其中一种方法是向 Thanos Query 组件添加一个新的 --store <thanos-ruler-ip> 命令行参数来指定 Rule 组件。

告警规则

告警规则和 Prometheus 的告警规则是一样，语法、文件格式都一样，就不再赘述了。

必要的监控告警

为了确保 Rule 组件的 告警功能正常工作，有必要使用当前的集群中 Prometheus 来监控 Thanos Rule 组件，如果出现异常需要使用 Prometheus 的本地告警规则来进行告警。

需要警惕的最重要指标是:

• thanos_alert_sender_alerts_dropped_total 如果大于0，则意味着Rule 触发的警报没有发送到 AlertManager，这可能表明连接异常、不兼容或配置错误。

• prometheus_rule_evaluation_failures_total 如果大于0，则意味着该告警规则评估失败，这可能导致 Rule 告警出现遗漏或者忽略。这个指标表明您使用的 QueryAPI 接口可能存在问题。如果这种情况发生的时间超过了警报阈值，请对此高度警惕。策略标签会告诉你失败是否来自于容忍部分反应的规则。

• prometheus_rule_group_last_duration_seconds < prometheus_rule_group_interval_seconds 如果差异很大，则意味着规则计算花费的时间比计划的时间长。它可以表明您的查询后端(例如 Query)花了太多的时间来评估查询，也就是说，它不够快，无法填充规则。这可能表明其他问题，比如 StoreAPI 速度慢或规则中的查询表达式太复杂。

• thanos_rule_evaluation_with_warnings_total 如果选择使用规则和警报，将部分响应策略的值设置为 “warn”，这个指标将展示有多少次评估以某种类型的警告结束。要查看实际的警告，请查看WARN日志级别。这可能意味着这些评估只得到部分反应，而且可能不准确。

这些指标对于普通的 Prometheus 也很重要，尤其我们严重依赖网络这些指标更为重要。

由于 Rule 组件将查询处理外包给 Query 组件，因此它们通常承受的负载较小。如果有必要，可以通过分割 HA 对集群之间的规则集来进行应用功能分片。规则根据查询节点上配置的复制标签对重复数据删除后的数据进行处理。

Rule 组件的目标是使用与 Prometheus 相似的方法 ，可以配置 external labels 或者 relabel 。

通过远程写实现无状态的 Rule

无状态 Rule 组件支持几乎无限的水平可伸缩性 ，Rule 组件没有一个功能完备的 TSDB 来存储评估结果，但是可以在本地只使用 WAL 存储并通过远程写入将数据发送到某个远程存储。

本地 WAL 仅存储重用上游的 Prometheus 代理，并且与旧的TSDB数据兼容。

无状态模式可以通过在文件中通过 --remote-write.config 或内联--remote-write.config-file 参数提供 Prometheus 远程写的配置来启用。