菜单
文档breadcrumb arrow Grafana Mimirbreadcrumb arrow 参考breadcrumb arrow 高级架构breadcrumb arrow 组件breadcrumb arrow (可选) Ruler
开源

(可选) Grafana Mimir Ruler

Ruler 是一个可选组件，用于评估录制规则和警报规则中定义的 PromQL 表达式。每个租户都有一组录制规则和警报规则，并将这些规则分组到命名空间中。

操作模式

Ruler 支持两种不同的规则评估模式：

内部模式

这是默认模式。Ruler 内部运行 querier 和 distributor，并在 ruler 进程本身评估录制规则和警报规则。为了评估规则，ruler 直接连接到 ingesters 和 store-gateways，并将所有生成的时序数据写入 ingesters。

内置 querier 和 distributor 的配置使用各自的配置参数。

注意

使用内部模式时，ruler 不使用任何查询加速技术，并且高基数查询的评估可能需要比评估间隔更长的时间，这可能导致评估的录制规则中缺少数据点。

Architecture of Grafana Mimir’s ruler component in internal mode

远程模式

在此模式下，ruler 将规则评估委托给 query-frontend。启用后，ruler 利用 query-frontend 使用的所有查询加速技术，例如查询分片。要启用远程操作模式，请为 ruler 设置 -ruler.query-frontend.address CLI 标志或其相应的 YAML 配置参数。ruler 和 query-frontend 之间的通信通过 gRPC 建立，因此您可以通过在 query-frontend 地址 URL 前加上 dns:// 来利用客户端负载均衡。

Architecture of Grafana Mimir’s ruler component in remote mode

录制规则

ruler 会按设定的间隔评估录制规则中的表达式，并将结果写回 ingesters。

警报规则

ruler 会按设定的间隔评估警报规则中的表达式，如果结果包含任何时序数据，警报将变为活动状态。如果警报规则定义了 for 持续时间，它将进入等待中 (PENDING) (pending) 状态。在警报活动持续了整个 for 持续时间后，它将进入正在触发 (FIRING) (firing) 状态。然后 ruler 会通知 Alertmanagers 任何正在触发 (FIRING) (firing) 的警报。

使用 -ruler.alertmanager-url 标志配置 Alertmanagers 的地址。此标志支持 DNS 服务发现格式。有关 DNS 服务发现的更多信息，请参阅支持的发现模式。

如果您正在使用Mimir 的 Alertmanager，请将地址指向 Alertmanager 的 API。您可以通过 -http.alertmanager-http-prefix 标志配置 Alertmanager 的 API 前缀，其默认值为 /alertmanager。例如，如果 Alertmanager 正在监听 http://mimir-alertmanager.namespace.svc.cluster.local 并使用默认 API 前缀，请将 -ruler.alertmanager-url 设置为 http://mimir-alertmanager.namespace.svc.cluster.local/alertmanager。

联合规则组

联合规则组是具有非空 source_tenants 的规则组。

source_tenants 字段允许在评估规则组时聚合来自多个租户的数据。组中每条规则的表达式将针对 source_tenants 中所有租户的数据进行评估。如果 source_tenants 为空或被省略，则创建该组的租户将被视为 source_tenant。

以下是一个联合规则组的示例：

yaml 
name: MyGroupName
source_tenants: ["tenant-a", "tenant-b"]
rules:
  - record: sum:metric
    expr: sum(metric)

在此示例中，MyGroupName 规则将针对 tenant-a 和 tenant-b 租户进行评估。

默认情况下，联合规则组在评估期间会被跳过。此功能依赖于跨租户查询联合功能。要启用联合规则，请设置 -ruler.tenant-federation.enabled=true 和 -tenant-federation.enabled=true CLI 标志（或其相应的 YAML 配置选项）。

在评估期间，应用于单个租户的查询限制也应用于规则组中的每个查询。例如，如果 tenant-a 有一个包含 source_tenants: [tenant-b, tenant-c] 的联合规则组，则将应用 tenant-b 和 tenant-c 的查询限制。如果超出其中任何一个限制，整个评估将失败。不会保存部分结果。同样的“不保存部分结果”保证也适用于因其他原因（例如 ingester 不可用）而失败的查询。

在评估联合规则期间使用的时序数据将带有 __tenant_id__ 标签，类似于跨租户查询联合返回的时序数据中的标签。

注意

联合规则组允许将来自多个源租户的数据写入单个目标租户。这使得租户数据之间的分离不那么清晰。

例如，tenant-a 有一个联合规则组，它聚合 tenant-b 的数据（如 sum(metric_b)），并将结果作为指标 sum:metric_b 写回 tenant-a 的存储。现在 tenant-a 包含了 tenant-b 的部分数据。

在配置 Mimir 前面的访问控制层以及通过 -ruler.tenant-federation.enabled 启用联合规则时，请记住这一点。

分片

ruler 支持多租户和横向扩容。为了实现横向扩容，ruler 按规则组分片执行规则。Ruler 副本形成自己的哈希环，存储在KV 存储中，以分配执行规则的工作。

要配置 rulers 的哈希环，请参阅配置哈希环。

管理警报规则和录制规则

有多种方式管理警报规则和录制规则。

通过 mimirtool CLI 工具

mimirtool rules 命令提供了一些实用子命令，用于对规则进行 linting、格式化和上传到 Grafana Mimir。更多信息请参阅 mimirtool rules。

通过 grafana/mimir/operations/mimir-rules-action GitHub Action

GitHub Action mimir-rules-action 封装了 mimirtool rules 的部分功能。更多信息请参阅此 Action 的文档。

通过 HTTP 配置 API

ruler HTTP 配置 API 允许租户创建、更新和删除规则组。有关 endpoint 列表和示例请求的完整信息，请参阅ruler。

状态

ruler 使用通过 -ruler-storage.backend 配置的后端。ruler 支持以下后端：

本地存储

local 存储后端从本地文件系统读取 Prometheus 录制规则。

注意

本地存储是只读后端，不支持通过配置 API 创建和删除规则。

当所有 rulers 都拥有相同的规则文件时，本地存储支持 ruler 分片。为了方便 Kubernetes 中的分片，将 Kubernetes ConfigMap 挂载到每个 ruler Pod 中。

以下示例显示了本地存储的定义：

-ruler-storage.backend=local
-ruler-storage.local.directory=/tmp/rules

ruler 在 /tmp/rules/<TENANT ID> 目录中查找租户规则。ruler 要求规则文件采用 Prometheus 格式。