Thanos Ruler（Rule）组件完全指南：分布式 Prometheus 规则评估、告警与无状态横向扩展

导读

Thanos Ruler（thanos rule 命令）是一个"简化版 Prometheus"：它不抓取指标、不提供 PromQL 查询 API，只负责对来自 Thanos Query（或其他 Query API）的数据执行 recording/alerting 规则，将评估结果以 TSDB 块形式写盘并上传对象存储，或通过 remote write 推送到远端存储。本文将围绕 docs/components/rule.md 的完整内容，结合仓库源码深入讲解 Ruler 的架构定位、规则文件语法、Partial Response 策略、HA 高可用部署、无状态模式以及全部命令行参数，帮助你正确评估并落地 Ruler。

---

Ruler 是什么：架构定位与两种运行模式

Thanos Ruler 通过重复的 --query 参数（或 FileSD --query.sd）指定的查询 API 来执行 Prometheus recording 与 alerting 规则。如果传入了多个 query 地址，Ruler 会对查询请求做 round-robin（轮询）负载均衡。从源码结构看，这一逻辑位于 cmd/thanos/rule.go 中的 queryFuncCreator：它会以随机顺序遍历所有查询端点，直到拿到结果或上下文被取消。

Ruler 与普通 Prometheus 的核心区别在于读路径是分布式的：Ruler 本身不存原始指标，而是向 Thanos Querier 发起查询，Querier 再通过 StoreAPI 从各 Store 节点拉取数据。

Ruler 支持两种运行模式：

模式	存储方式	StoreAPI	适用场景
有状态（默认）	评估结果以 Prometheus 2.0 存储格式写回本地磁盘（TSDB），随后作为 Store 节点参与系统，将生成的 TSDB 块上传到对象存储	暴露 StoreAPI（gRPC 10901 端口），可被 Querier 直接查询	需要查询历史规则结果、依赖 TSDB 块上传的常规部署
无状态	仅使用 WAL（复用上游 Prometheus agent），通过 remote write 把样本推送到远端存储	不暴露 StoreAPI，只作为数据生产者	需要近无限水平扩展、不关心本地历史结果

官方文档明确建议：默认仍应优先把规则部署在对应 Prometheus 本地，仅在特定场景下才使用 Ruler（详见下文"风险与权衡"）。Ruler 也不应被用来规避配置管理层面本应妥善解决的规则部署问题。

有状态模式的核心组件

从 cmd/thanos/rule.go 的 runRule 实现看，有状态模式下 Ruler 内部运行着这样一组协作组件：

• 规则管理器（rules.Manager）：基于 Prometheus 上游 prometheus/rules 包，负责按 --eval-interval 周期评估规则、维护 alert 的 for 状态；
• 本地 TSDB：通过 tsdb.Open 打开 --data-dir 下的存储，作为 storage.Appendable 与 storage.Queryable；
• Shipper：后台 goroutine 每 30 秒调用 shipper.Sync 扫描数据目录，把新生成的块上传到对象存储，块源标记为 metadata.RulerSource，外部标签取自 --label；
• Alert 队列与 Sender：alert.NewQueue 缓冲触发的告警，alert.NewSender 将告警推送到 Alertmanager；
• gRPC StoreAPI 服务器：注册 store.RegisterStoreServer（基于本地 TSDB）与 thanosrules.RegisterRulesServer，并附带 Info、Status 服务；
• HTTP UI 与 API：在 --http-address（默认 0.0.0.0:10902）上提供 Alerts/Rules 页面和 /api/v1 规则 API，以及 POST /-/reload 热重载端点。

风险与权衡：为什么默认不建议使用 Ruler

Ruler 存在概念性权衡，最核心的一点是对查询可靠性的依赖。普通 Prometheus 的规则评估是本地完成的，评估失败概率很低；而 Ruler 的读路径是分布式的——它大概率在查询 Thanos Querier，而 Querier 的数据来自远端 StoreAPI，因此查询失败的可能性显著更高。

这意味着，部署 Ruler 前必须想清楚一个关键策略：查询不可用时，告警与 recording 规则会发生什么。官方文档特别强调，对于告警规则，出现部分响应（partial response）可能导致 Ruler 漏掉真实症状，因此默认建议将告警规则的 partial response 策略保持为 abort（详见下文"Partial Response 策略"）。

快速上手：启动一个 Ruler 实例

最典型的启动命令如下（参数顺序可自由调整）：

thanos rule \
    --data-dir             "/path/to/data" \
    --eval-interval        "30s" \
    --rule-query-offset    "10s" \
    --rule-file            "/path/to/rules/*.rules.yaml" \
    --alert.query-url      "http://0.0.0.0:9090" \ # 告警 UI 中"Source"字段指向的查询 URL
    --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"'

各参数要点：

• --query 可重复传入多个 Query API 地址，Ruler 会轮询使用；地址还可加 dns+ 或 dnssrv+ 前缀做 DNS 服务发现；
• --objstore.config-file 指向对象存储配置（S3、GCS 等），配置格式见 docs/storage.md；不配置对象存储时，从源码可以看到 Ruler 会打印 no supported bucket was configured, uploads will be disabled 并跳过 shipper；
• --label 可重复指定外部标签，用于标记 Ruler 及其生成的块来源（详见"外部标签"一节）；
• 规则文件默认路径是 rules/（glob 模式，可重复），注意规则文件不会被自动检测变更，修改后需发送 SIGHUP 或 POST /-/reload 触发重读。

规则热重载

源码 cmd/thanos/rule.go 中的 reloadRules 通过 ruleMgr.Update(evalInterval, files) 重新加载所有 glob 匹配的规则文件，并更新 thanos_rule_config_last_reload_successful、thanos_rule_config_last_reload_success_timestamp_seconds 与 thanos_rule_loaded_rules 指标。触发方式：

• 向 Ruler 进程发送 SIGHUP 信号；
• 调用 POST /-/reload HTTP 接口（由 router.Post("/-/reload", ...) 注册）。

配置规则文件：YAML 语法

规则文件使用 YAML，顶层语法为：

groups:
  [ - <rule_group> ]

一个最简单的规则文件示例：

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

<rule_group> 的结构：

# 组的名称。在同一文件内必须唯一。
name: <string>

# 组内规则的评估周期。
[ interval: <duration> | default = global.evaluation_interval ]

# 将该组规则的评估时间戳向过去偏移指定时长。
[ query_offset: <duration> | default = --rule-query-offset flag ]

rules:
  [ - <rule> ... ]

说明：interval 的默认值来自全局评估间隔（即 --eval-interval 参数，默认 1m），query_offset 的默认值来自 --rule-query-offset 参数（默认 0s）。仓库测试用例 cmd/thanos/testdata/rules-files/valid.yaml 展示了包含 partial_response_strategy 与 interval: 2m 的合法规则组。

Thanos 支持两种规则类型：recording rules（记录规则） 和 alerting rules（告警规则），二者都存在于规则组中，组内规则按顺序、按固定周期串行执行。

Recording Rules：预计算高频查询表达式

记录规则允许你预先计算频繁使用或计算代价高昂的 PromQL 表达式，把结果保存为新的时间序列。之后直接查询预计算结果，通常比每次重复执行原始表达式快得多——这对每次刷新都要查询同一表达式的 Dashboard 尤其有用。

# 输出时间序列的名称。必须是合法的指标名。
record: <string>

# 要评估的 PromQL 表达式。每个评估周期都会在当前时刻执行，
# 结果以 'record' 指定的指标名保存为一组新的时间序列。
expr: <string>

# 存储结果前要添加或覆盖的标签。
labels:
  [ <labelname>: <labelvalue> ]

重要提示：如果使用了 recording rules，务必把 Ruler 实例作为 store 暴露给 Thanos Querier，这样新产生的时间序列才能被 Thanos Query 查询到。一种做法是在 Thanos Query 命令中追加 --endpoint <thanos-ruler-ip> 参数。仓库自带示例规则 examples/alerts/rules.yaml 中包含大量可直接参考的 recording rules（如 :grpc_client_failures_per_unary:sum_rate、:query_duration_seconds:histogram_quantile 等）。

Alerting Rules：定义告警

# 告警的名称。必须是合法的指标名。
alert: <string>

# 要评估的 PromQL 表达式。每个评估周期都会在当前时刻执行，
# 所有结果时间序列都会变成 pending/firing 状态的告警。
expr: <string>

# 告警持续返回该时长后才会被视为 firing；
# 尚未达到该时长的告警被视为 pending。
[ for: <duration> | default = 0s ]

# 触发条件已清除后，告警继续 firing 的时长。
[ keep_firing_for: <duration> | default = 0s ]

# 为每个告警添加或覆盖的标签。
labels:
  [ <labelname>: <tmpl_string> ]

# 为每个告警添加的注解。
annotations:
  [ <labelname>: <tmpl_string> ]

标签和注解的值支持 Prometheus 模板字符串（tmpl_string），可引用 $labels、$value 等变量。

Partial Response 策略：告警准确性的关键开关

关于 partial response 的初始概念请先阅读 docs/components/query.md 中的"Partial Response"一节。Ruler 允许在规则组中通过附加字段 partial_response_strategy 控制每个组的策略，支持 warn 与 abort 两个取值，默认是 abort：

groups:
- name: "warn strategy"
  partial_response_strategy: "warn"
  rules:
  - alert: "some"
    expr: "up"
- name: "abort strategy"
  partial_response_strategy: "abort"
  rules:
  - alert: "some"
    expr: "up"
- name: "by default strategy is abort"
  rules:
  - alert: "some"
    expr: "up"

官方建议：告警规则的 partial response 保持为 abort（这也是默认值）。本质上，允许 partial response 会让 Ruler 的告警漏掉真实症状——数据不完整时宁可直接失败，也不要用残缺结果做判断。

从源码实现看，这一策略被精细地落到了执行层：

• pkg/rules/manager.go 中 LoadRuleGroups 解析 partial_response_strategy 字段（解析失败会报错，如 failed to unmarshal "xxx" as 'partial_response_strategy'），并按策略将规则组分类；
• cmd/thanos/rule.go 的 queryFuncCreator 针对 WARN 与 ABORT 使用不同的 tracing span ID（/rule_instant_query HTTP[client] 与 /rule_instant_query_part_resp_abort HTTP[client]），并把策略传给下游查询客户端，从而决定请求是否容忍部分 StoreAPI 失败。

必须监控：Ruler 的关键告警指标

要确信告警链路正常工作，必须从同一集群内的另一套 Scraper（Prometheus + sidecar） 监控 Ruler 自身，并对以下指标设置告警：

• thanos_alert_sender_alerts_dropped_total：大于 0 表示 Ruler 触发的告警没有被发送到 Alertmanager，可能表明连接、兼容性或配置问题。对应源码 pkg/alert/alert.go 中的 sender 计数器。
• prometheus_rule_evaluation_failures_total：大于 0 表示规则评估失败，会导致规则结果出现空洞或告警被忽略。该指标可能暗示你所用的 Query API 端点有问题。strategy 标签能区分失败来自"容忍 partial response"的规则还是其他规则；如果持续时间超过告警阈值，应当重点告警。
• prometheus_rule_group_last_duration_seconds > prometheus_rule_group_interval_seconds：若差值为正，说明规则评估耗时超过了计划周期，部分间隔的数据可能缺失。这往往意味着查询后端（如 Querier）求值太慢、来不及喂饱规则，也可能是 StoreAPI 响应慢或规则表达式过于复杂所致。
• thanos_rule_evaluation_with_warnings_total：如果对规则使用了 partial_response_strategy: "warn"，该指标统计有多少次评估最终带警告结束。要查看具体警告内容请看 WARN 级别日志。该指标可能暗示这些评估返回的是部分响应、结果未必准确。对应源码 cmd/thanos/rule.go 中的 thanos_rule_evaluation_with_warnings_total CounterVec（按 strategy 分桶）。

这些指标对原生 Prometheus 同样重要，但在依赖（有时是 WAN 广域网）网络的情况下对 Ruler 尤其关键。更完整的 Ruler 告警示例（ThanosRuleQueueIsDroppingAlerts、ThanosRuleSenderIsFailingAlerts、ThanosRuleHighRuleEvaluationFailures 等）可参考 examples/alerts/alerts.md 中的 Ruler 一节及 examples/alerts/alerts.yaml。

补充建议：官方文档推荐在 Ruler 上设置一条"探活"假告警，例如用 vector(1) 这样的简单查询定期检查 Querier 是否存活。

性能与扩展

由于规则节点把查询处理外包给了查询节点，Ruler 自身通常负载很轻。如确有需要，可以通过在 HA 对之间拆分规则集合实现功能性分片（functional sharding）。同时，规则按查询节点上配置的 replica 标签处理去重后的数据（即 Querier 会按 replica 标签对外部标签相同的副本做去重），保证 HA 部署时规则只被计算一次、结果一致。

外部标签：多副本运行的前提

给 Ruler 设置外部标签是强制要求，必须通过 --label 指明 Ruler 来源（例如 label='replica="A"' 或 cluster 标签），否则无法运行多个 Ruler 副本——压缩（compaction）阶段会因为多个来源产生冲突。

注意，建议给 Ruler 设置不同于被记录/告警数据来源的外部标签。官方文档给出了一个典型反例：

• Ruler 位于 mon1 集群，被监控的 Prometheus 位于 eu1 集群；
• 若为了让标签一致，给 Prometheus 设 cluster=eu1、给 Ruler 设 cluster=mon1；
• 配置一条监控 work1 集群服务的 ScraperIsDown 告警；
• 告警触发时结果是 ScraperIsDown{cluster=mon1}——因为外部标签总是会替换来源标签。

这样会丢掉关键元数据，不手动查询根本无法分辨 ScraperIsDown 到底是在哪个 cluster 发现问题。

Ruler UI

Ruler 在 HTTP 地址上暴露 UI，主要包含 Alerts 与 Rules 页面（与 Prometheus 的 Alerts 页面类似）。每条告警都链接到触发该告警的查询表达式，点击可跳转到 --alert.query-url 配置的查询页面。--alert.query-template 参数（默认 /graph?g0.expr={{.Expr}}&g0.tab=1）控制该链接的生成模板，源码 cmd/thanos/rule.go 中的 tableLinkForExpression 会先对表达式做 URL 转义再套用模板。

Ruler HA：高可用部署

Ruler 采用与 Prometheus 类似的 HA 思路，支持外部标签与 relabel 配置。HA 部署时必须保证以下标签体系：

1. 标识 HA 组与副本：用 --label 给每个 Ruler 实例设置标识 HA 组的标签和取值不同的副本标签，例如 cluster="eu1", replica="A" 与 cluster="eu1", replica="B"；
2. 发送 Alertmanager 前丢弃副本标签：用 --alert.label-drop="replica" 在发送前丢弃这些标签，使 Alertmanager 能对来自不同副本的同一告警做去重。

更高级的 relabel 配置可通过 --alert.relabel-config（内联）或 --alert.relabel-config-file（文件）指定，其配置格式与 Prometheus 的 alert_relabel_configs 字段完全一致。注意：Thanos Ruler 会先丢弃 --alert.label-drop 中列出的标签，再执行告警 relabel。

从源码 pkg/alert/alert.go 看，告警队列在入队时就会剔除 --alert.label-drop 指定的标签，随后应用 relabel 配置，最终由 sender 推送到 Alertmanager。

Stateless Ruler：通过 Remote Write 实现近无限扩展

无状态模式让 Ruler 具备了近乎无限的水平扩展能力。该模式下 Ruler 不再拥有完整的 TSDB，而是只使用 WAL 存储，并通过 remote write 把样本推送到远端存储。

• WAL-only 存储复用了上游 Prometheus agent（Prometheus agent 设计），且与旧 TSDB 数据兼容；
• 设计动机与细节见仓库内提案 docs/proposals-done/202005-scalable-rule-storage.md。

启用方式：通过 --remote-write.config-file（文件）或 --remote-write.config（内联）提供 Prometheus remote write 配置。从源码看，只要传入的 remote write 配置非空，Ruler 就会用 agent.Open 打开 WAL-only agent 存储，并把 agentDB 与 remote storage 组合成 fanout store 作为 appendable；若配置为空，则忽略该标志并回退到自带 TSDB 的有状态模式。此外，源码会调用 agentDB.SetWriteNotified(remoteStore)，让样本在规则评估后立即触发推送，避免最多 15 秒的轮询延迟。

启动命令示例：

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" \ # 告警 UI 中"Source"字段指向的查询 URL
    --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"' \
    --remote-write.config-file  'rw-config.yaml'

其中 rw-config.yaml 可参考如下（完整包含两个 remote write 目标、重定向策略与队列调优参数）：

remote_write:
- url: http://e2e_test_rule_remote_write-receive-1:8081/api/v1/receive
  name: thanos-receiver
  follow_redirects: false
- url: https://e2e_test_rule_remote_write-receive-2:443/api/v1/receive
  remote_timeout: 30s
  follow_redirects: true
  queue_config:
    capacity: 120000
    max_shards: 50
    min_shards: 1
    max_samples_per_send: 40000
    batch_send_deadline: 5s
    min_backoff: 5s
    max_backoff: 5m

配置可通过 --remote-write.config-file= 从文件传入，或用 --remote-write.config= 内联传入。

无状态模式的两点注意事项：

1. metadata_config 在该模式下不受支持，若在 remote write 配置中提供会被忽略；
2. 启用无状态模式后，Ruler 不再暴露 StoreAPI 供查询规则结果。若远端存储是 Thanos Receiver，你可以直接查询 Receiver 获取规则评估结果。

全部 Flags 详解

以下为 thanos rule --help 的完整输出（来自当前仓库实际命令），按功能分组说明：

通用与运行参数

  -h, --[no-]help                显示上下文相关帮助（也支持 --help-long 与 --help-man）
      --[no-]version             显示应用版本
      --log.level=info           日志过滤级别
      --log.format=logfmt        日志格式：logfmt、json 或 journald
      --tracing.config-file=<file-path>
                                 tracing 配置 YAML 文件路径（格式见 docs/tracing.md）
      --tracing.config=<content>
                                 'tracing.config-file' 的替代（互斥），内联 tracing 配置内容
      --[no-]enable-auto-gomemlimit
                                 启用 Go 运行时自动限制内存占用
      --auto-gomemlimit.ratio=0.9
                                 GOMEMLIMIT 相对于检测到的最大容器/系统内存的保留比例

HTTP 与 gRPC 服务

      --http-address="0.0.0.0:10902"     HTTP 端点监听地址（UI、metrics、/api/v1）
      --http-grace-period=2m             收到中断后等待 HTTP Server 退出的时间
      --http.config=""                   [实验性] 为所有 HTTP 端点启用 TLS/认证的配置文件
      --grpc-address="0.0.0.0:10901"     gRPC 端点（StoreAPI）监听地址，需保证其他组件可路由访问
      --grpc-server-tls-cert=""          gRPC server TLS 证书，留空禁用 TLS
      --grpc-server-tls-key=""           gRPC server TLS 私钥
      --grpc-server-tls-client-ca=""     gRPC 客户端校验 CA；不指定则不校验客户端
      --grpc-server-tls-min-version=1.3  TLS 最低版本，可选 ["1.0","1.1","1.2","1.3"]
      --grpc-server-tls-ciphers=...      gRPC server TLS 密码套件（可重复）
      --grpc-server-tls-curves=...       gRPC TLS 曲线（CurveP256/384/521、X25519）
      --grpc-server-max-connection-age=60m
                                         最长连接时长，控制连接重建与 TLS 握手频率
      --grpc-grace-period=2m             收到中断后等待 GRPC Server 退出的时间

Web UI 路由

      --web.route-prefix=""       API 与 UI 端点的前缀，用于把 Thanos UI 挂到子路径（类似 Prometheus 的 --web.route-prefix）
      --web.external-prefix=""    所有 HTML 链接与重定向 URL 的静态前缀，用于反代剥离子路径场景
      --web.prefix-header=""      用于动态前缀的 HTTP 请求头名称；仅在反代会重置该头时启用（安全风险）
      --[no-]web.disable-cors     是否禁用 Thanos 默认设置的 CORS 响应头

Shipper（对象存储上传）

      --[no-]shipper.upload-compacted
                                 是否上传 compacted 块（迁移用途，仅当 Prometheus 侧关闭 compaction 时使用一次）
      --hash-func=               计算文件哈希的函数，可选 "" 或 "SHA256"（用于避免重复下载）
      --shipper.meta-file-name="thanos.shipper.json"
                                 存储 shipper 元数据的文件名
      --shipper.upload-concurrency=0
                                 上传块文件到对象存储时的并发 goroutine 数

Query API 配置

      --query=<query> ...        静态配置的 Query API 地址（可重复），支持 dns+/dnssrv+ 前缀
      --query.config-file=<file-path>
                                 包含 Query API 服务器配置的 YAML 文件路径；若定义则优先于 --query 与 --query.sd-files
      --query.config=<content>   'query.config-file' 的替代（互斥），内联配置内容
      --query.sd-files=<path> ... 包含 Query API 地址的文件路径（支持 glob，可重复）
      --query.sd-interval=5m     重新读取 FileSD 文件的刷新间隔
      --query.sd-dns-interval=30s DNS 解析间隔
      --query.http-method=POST   发送查询的 HTTP 方法，可选 [GET, POST]
      --query.default-step=1s    默认 range 查询步长，仅在无状态 Ruler 与告警状态恢复时使用
      --grpc-query-endpoint=<endpoint> ...
                                 Thanos gRPC Query API 服务器地址（可重复），支持 dns+/dnssrv+ 前缀
      --[no-]query.enable-x-functions
                                 是否启用扩展速率函数（xrate、xincrease、xdelta），仅在使用 Thanos engine 时生效
      --enable-feature= ...      启用的特性，目前支持 promql-experimental-functions

Alertmanager 配置

      --alertmanagers.config-file=<file-path>
                                 包含告警配置的 YAML 文件路径；若定义则优先于 --alertmanagers.url 与 --alertmanagers.send-timeout
      --alertmanagers.config=<content>
                                 'alertmanagers.config-file' 的替代（互斥），内联配置内容
      --alertmanagers.url=ALERTMANAGERS.URL ...
                                 Alertmanager 副本 URL（可重复），推送至少一个成功即视为成功；scheme 不可为空，
                                 支持 dns+/dnssrv+ 前缀，端口默认 9093；URL 路径作为 Alertmanager API 路径的前缀
      --alertmanagers.send-timeout=10s
                                 向 Alertmanager 发送告警的超时时间
      --alertmanagers.sd-dns-interval=30s
                                 Alertmanager 主机 DNS 解析间隔

告警发送与链接

      --alert.query-url=ALERT.QUERY-URL
                                 写入所有告警 'Source' 字段的外部 Thanos Query URL
      --alert.label-drop=ALERT.LABEL-DROP ...
                                 发送到 Alertmanager 前按名称丢弃的标签（可重复），例如丢 replica 便于去重
      --alert.relabel-config-file=<file-path>
                                 告警 relabel 配置 YAML 文件路径
      --alert.relabel-config=<content>
                                 'alert.relabel-config-file' 的替代（互斥），内联 relabel 配置内容
      --alert.query-template="/graph?g0.expr={{.Expr}}&g0.tab=1"
                                 告警 Source 字段使用的链接模板，只需包含 {{.Expr}} 参数

存储与规则执行

      --store.limits.request-series=0
                                 单个 Series 请求允许的最大序列数，超过则请求失败；0 表示不限
      --store.limits.request-samples=0
                                 单个 Series 请求允许的最大样本数，超过则请求失败；0 表示不限。
                                 注意：内部按 chunk 数实现该限制，每个 chunk 最多含 120 个样本
      --label=<name>="<value>" ...
                                 应用到所有生成指标的标签（可重复），类似 Prometheus 外部标签，
                                 用于标识 Ruler 及其块是唯一来源
      --tsdb.block-duration=2h   TSDB 块时长
      --tsdb.retention=48h       本地磁盘块保留时间
      --[no-]tsdb.no-lockfile    不在 TSDB 数据目录创建 lockfile；锁文件都会在下次启动时被删除
      --[no-]tsdb.wal-compression
                                 压缩 TSDB WAL
      --data-dir="data/"         数据目录
      --rule-file=rules/ ...     规则管理器使用的规则文件（支持 glob，可重复）；规则不会被自动检测，
                                 使用 SIGHUP 或 HTTP POST /-/reload 重新读取
      --resend-delay=1m          重新向 Alertmanager 发送告警前的最小等待时间
      --eval-interval=1m         默认评估周期
      --rule-query-offset=0s     默认规则组 query_offset 时长
      --for-outage-tolerance=1h  恢复告警 "for" 状态时容忍的 Prometheus 故障最大时长
      --for-grace-period=10m     告警与其恢复的 "for" 状态之间的最小时长；仅对配置了大于该值的 "for" 时长的告警生效
      --restore-ignored-label=RESTORE-IGNORED-LABEL ...
                                 从远端存储恢复告警时要忽略的标签名（仅无状态模式使用）
      --rule-concurrent-evaluation=1
                                 可并发评估的规则数，默认 1
      --[no-]tsdb.enable-native-histograms
                                 （已废弃）启用原生直方图摄入，现为 no-op，原生直方图摄入总是启用

Remote Write 与对象存储

      --remote-write.config-file=<file-path>
                                 remote write 配置 YAML 文件路径，指定样本发送目标服务器
                                 （格式见 Prometheus remote_write 文档）。设置后自动启用 Ruler 无状态模式，
                                 样本不再存入 Ruler 的 TSDB；若提供空配置则忽略该标志、回退到自带 TSDB
      --remote-write.config=<content>
                                 'remote-write.config-file' 的替代（互斥），内联配置内容，语义同上
      --objstore.config-file=<file-path>
                                 对象存储配置 YAML 文件路径（格式见 docs/storage.md）
      --objstore.config=<content>
                                 'objstore.config-file' 的替代（互斥），内联对象存储配置内容
      --request.logging-config-file=<file-path>
                                 请求日志配置 YAML 文件路径（格式见 docs/logging.md）
      --request.logging-config=<content>
                                 'request.logging-config-file' 的替代（互斥），内联请求日志配置内容

注意：--query/--query.sd-files/--grpc-query-endpoint 与 --query.config* 不能同时定义，--alertmanagers.url 与 --alertmanagers.config* 也不能同时定义，否则启动时直接报错（校验逻辑见 cmd/thanos/rule.go）。

配置文件格式详解

Ruler 支持用 YAML 配置文件替代部分重复参数，实现更丰富的认证、TLS 与多端点管理。

Alertmanager 配置

--alertmanagers.config 与 --alertmanagers.config-file 允许指定多个 Alertmanager。这些条目被视作同一个 HA 组：只有向所有实例发送都失败时，才认为告警发送失败（任一成功即成功）。这与 --alertmanagers.url 参数的行为一致。

alertmanagers:
- http_config:
    basic_auth:
      username: ""
      password: ""
      password_file: ""
    bearer_token: ""
    bearer_token_file: ""
    proxy_url: ""
    tls_config:
      ca_file: ""
      cert_file: ""
      key_file: ""
      server_name: ""
      insecure_skip_verify: false
  static_configs: []
  file_sd_configs:
  - files: []
    refresh_interval: 0s
  scheme: http
  path_prefix: ""
  timeout: 10s
  api_version: v1

api_version 支持的值是 v1 或 v2，对应 Alertmanager API 的兼容版本。

Query API 配置

--query.config 与 --query.config-file 允许指定多个查询端点。这些条目同样被视作同一个 HA 组，且 HTTP 端点优先于 gRPC Query API 端点：只有所有实例都查询失败，才认为查询失败。

产生 native histogram（实验特性）的规则只能通过 gRPC Query API 支持；除此之外，HTTP 与 gRPC 在功能上对普通规则没有区别。配置格式：

- http_config:
    basic_auth:
      username: ""
      password: ""
      password_file: ""
    bearer_token: ""
    bearer_token_file: ""
    proxy_url: ""
    tls_config:
      ca_file: ""
      cert_file: ""
      key_file: ""
      server_name: ""
      insecure_skip_verify: false
  static_configs: []
  file_sd_configs:
  - files: []
    refresh_interval: 0s
  scheme: http
  path_prefix: ""
  grpc_config:
    endpoint_addresses: []

总结

Thanos Ruler 是 Thanos 生态中承担"分布式规则评估"职责的组件：它把规则执行与本地抓取解耦，从 Query API 读取分布式数据、本地评估、结果上送对象存储或 remote write。使用前必须权衡其对查询可靠性的依赖；部署时必须配置外部标签并监控 thanos_alert_sender_alerts_dropped_total、prometheus_rule_evaluation_failures_total 等关键指标；HA 场景需要配合 --alert.label-drop 去重；追求扩展性则可切换到基于 Prometheus agent WAL 的无状态 remote write 模式。正确理解这些取舍与参数，才能让 Ruler 在合适的场景发挥价值，而不是引入新的告警盲区。

进一步阅读：docs/components/rule.md（本文依据）、docs/components/query.md（Partial Response 与查询路径）、docs/proposals-done/202005-scalable-rule-storage.md（无状态规则存储设计提案）、examples/alerts/alerts.md（Ruler 监控告警示例）。