管理记录规则

记录规则是按间隔运行的查询，它们从日志中生成指标，并将这些指标推送到 Prometheus 兼容的后端。

记录规则由 ruler 组件评估。每个 ruler 充当其自身的查询器，即它直接对存储执行查询，而不使用 query-frontend 或 querier 组件。它将遵守为 querier 设置的所有查询限制。

Loki 的记录规则实现很大程度上复用了 Prometheus 的代码。

记录规则生成的样本使用 Prometheus 的远程写入 (remote-write) 功能发送到 Prometheus。

预写日志 (WAL)

记录规则生成的所有样本都写入 WAL。WAL 的主要优势在于它将记录规则生成的样本持久化到磁盘，这意味着如果您的 ruler 崩溃，您不会丢失任何数据。我们为了此功能而权衡了额外的内存使用和更慢的启动时间。

每个租户创建一个 WAL；这样做是为了防止跨租户交互。如果所有样本都写入单个 WAL，则一个租户可能会导致其他租户数据丢失的几率会增加。一个典型的场景是，如果这 100 个样本中只有 1 个以某种方式无效，Prometheus 将拒绝远程写入请求，例如包含 100 个样本的请求。

启动

当 ruler 启动时，它会加载拥有记录规则的租户的 WAL。这些 WAL 文件存储在磁盘上并加载到内存中。

注意
启动时 WAL 会一个接一个地加载。这是 Loki ruler 当前的限制。因此，建议将由 ruler 服务的规则组数量保持在合理的大小，因为在 WAL 重放期间不会进行规则评估（包括告警规则）。

截断

WAL 文件会定期截断以减少其在磁盘上的大小。这篇来自 Prometheus 维护者 Ganesh Vernekar 的指南详细介绍了 WAL 的截断、检查点和重放过程。

清理器

WAL 清理器是一个实验性功能。

WAL 清理器会监视已废弃的 WAL（不再关联记录规则的租户）并将其删除。仅当您遇到 WAL 过大而导致存储问题时才启用此功能。由于截断机制，WAL 不应过度增长。

伸缩

请参阅 Mimir 关于配置 Grafana Mimir 哈希环以使用环伸缩 ruler 的指南。

注意
ruler 按规则组进行分片，而不是按单个规则。这是 Prometheus 规则引擎（Loki 使用的）的一个特点，因为 Prometheus 记录规则需要按顺序运行，一个记录规则可以复用另一个规则——但这在 Loki 中是不可能的。

部署

ruler 需要将 WAL 文件持久化到磁盘，并且通过将这些 WAL 读取到内存中会产生一定的启动成本。因此，建议您尽量减少单个 ruler 实例的波动，因为在从磁盘读取 WAL 期间，规则评估会被阻塞。

Kubernetes

建议您使用 StatefulSet 运行 ruler。ruler 会将其 WAL 文件写入持久存储，因此应使用 Persistent Volume。

远程写入 (Remote-Write)

客户端配置

远程写入客户端配置与 prometheus 配置格式完全兼容。

remote_write:	
  clients:	
    mimir:	
      url: http://mimir/api/v1/push
      write_relabel_configs:
      - action: replace
        target_label: job
        replacement: loki-recording-rules

每租户限制

远程写入可以在基础配置中进行全局配置，并且某些参数可以在每个租户的基础上进行特定调整。这里定义的大多数配置选项都具有覆盖选项（这些选项也可以在运行时应用！）。

调优

如果默认配置不足（请参见下面的故障模式），可以对远程写入进行调优。

Prometheus 网站上有一篇指南，其中的内容也同样适用于 Loki。

通过使用 -ruler.enable-sharding=true 和 -ruler.sharding-strategy="by-rule"，规则可以均匀地分布到可用的 ruler 上。规则组按顺序执行；这是从 Prometheus 规则引擎（Loki 使用的）继承的功能，但 Loki 不需要此约束，因为规则之间不能互相依赖。默认的分片策略将按规则组分片，但这可能不太理想，因为某些规则组可能包含更耗时的规则，这会导致后续规则错过评估。by-rule 分片策略会为 ruler 实例“拥有”的每个规则（基于其哈希环）创建一个规则组，并且这些环会并发执行。

可观测性

由于 Loki 复用了 Prometheus 的记录规则和 WAL 代码，它也继承了 Prometheus 的所有可观测性。

Prometheus 为其 WAL 实现公开了一些指标，这些指标都以 loki_ruler_wal_ 为前缀。

例如：prometheus_remote_storage_bytes_total → loki_ruler_wal_prometheus_remote_storage_bytes_total

还暴露了其他指标，它们也带有 loki_ruler_wal_ 前缀。所有每租户指标都包含一个 tenant 标签，因此如果租户数量增长得足够大，需要注意基数可能会成为问题。

需要注意的一些关键指标是

loki_ruler_wal_appender_ready：WAL appender 是否准备好接受样本 (1) 或未准备 (0)
loki_ruler_wal_prometheus_remote_storage_samples_total：每个租户发送到远程存储的样本总数
loki_ruler_wal_prometheus_remote_storage_samples...
- loki_ruler_wal_prometheus_remote_storage_samples_pending_total：缓存在内存中等待发送到远程存储的样本
- loki_ruler_wal_prometheus_remote_storage_samples_failed_total：发送到远程存储时失败的样本
- loki_ruler_wal_prometheus_remote_storage_samples_dropped_total：因 relabel 配置而被丢弃的样本
- loki_ruler_wal_prometheus_remote_storage_samples_retried_total：重新发送到远程存储的样本
loki_ruler_wal_prometheus_remote_storage_highest_timestamp_in_seconds：追加到 WAL 的样本的最高时间戳
loki_ruler_wal_prometheus_remote_storage_queue_highest_sent_timestamp_seconds：发送到远程存储的样本的最高时间戳。

我们在 loki-mixin 中创建了一个基础仪表盘，您可以使用它来管理记录规则。

故障模式

远程写入延迟

远程写入可能因多种原因而延迟

远程写入存储 (Prometheus) 暂时不可用
租户从记录规则生成样本过快
远程写入调优过低，导致反压

可以通过将 loki_ruler_wal_prometheus_remote_storage_queue_highest_sent_timestamp_seconds 从 loki_ruler_wal_prometheus_remote_storage_highest_timestamp_in_seconds 中减去来确定延迟。

在情况 1 中，ruler 将继续重试发送这些样本，直到远程存储再次可用。请注意，如果远程存储停机时间长于 ruler.wal.max-age，则在截断发生后可能会丢失数据。

在情况 2 和 3 中，您应该考虑适当调整远程写入。

延伸阅读：请参阅 Prometheus 维护者 Callum Styan 的这篇博客文章。

Appender 未就绪

每个租户的 WAL 内部都有一个“appender”；此 appender 用于向 WAL 中追加样本。在启动时 WAL 重放完成之前，appender 会被标记为未就绪。如果 WAL 因某种原因损坏，或重放耗时较长，您可以通过对 loki_ruler_wal_appender_ready < 1 设置告警来确定此问题。