0002: 远程规则评估
作者： Danny Kopping ( danny.kopping@grafana.com)
日期 01/2023
赞助者： @dannykopping
类型： Feature
状态： Accepted
相关问题/PR： https://github.com/grafana/mimir/pull/1536
来自邮件列表的帖子： N/A
背景
ruler 是一个评估警报和记录规则的组件。Loki 重用了 Prometheus 的规则评估引擎。`ruler` 当前通过内部初始化 `querier` 并“本地”评估所有规则（即不依赖于其他组件）来运行。每个规则组并发执行，规则组内的规则顺序评估（这是 Prometheus 的一个实现细节）。
记录规则生成指标序列，并将其发送到 Prometheus 兼容的源。警报规则在满足条件时向 Alertmanager 发送通知。这两种规则类型在组织的可观测性策略中都起着至关重要的作用，因此其可靠的评估至关重要。
问题陈述
规则评估可能包含昂贵的查询。`ruler` 初始化一个 `querier`，但 `querier` 没有查询加速能力；`query-frontend` 组件负责通过分割、分片、缓存和其他技术来加速查询。
一个昂贵的规则查询可能导致整个 `ruler` 实例占用过多资源甚至崩溃。这带来的问题非常严重，原因如下：
- 缓慢的规则评估可能导致规则组中的后续规则延迟或遗漏，从而导致警报丢失或记录规则指标出现空隙
- 过多的资源占用会阻碍其他租户的规则评估（“噪音邻居”问题）
目标
- 更快、更高效的规则评估
- 租户之间更好的隔离
- 更可靠的服务
非目标
本提案不旨在将此选项设为默认评估模式；它应是可选的，因为它会增加运维复杂性。
提案
提案 0: 不做任何事
对于运行相对简单或廉价查询的小型安装，Loki 当前的 `ruler` 实现已足够。
优点:
- 无需做任何事
缺点
- 当在大型多租户环境中使用昂贵查询时，Loki 的 `ruler` 将继续不可靠且低效。
提案 1: 远程执行
借鉴 Grafana Mimir 的实现，`ruler` 将配置为通过 gRPC 将其规则查询发送到 `query-frontend` 组件。接收来自 `query-frontend`（或可选地通过 `query-scheduler`）查询的 `querier` 实例将处理请求，并将响应发送回 `query-frontend` 进行合并。`ruler` 将接收并处理这些响应，就像查询是本地执行的一样。
优点
- 充分利用 Loki 的查询加速技术，实现更快、更高效的规则评估
- 操作简单，可沿用现有的 `query-frontend`/`query-scheduler`/`querier` 设置
- Loki 查询路径中提供的每租户隔离（shuffle-sharding、每租户队列）可用于减少或消除“噪音邻居”问题
缺点
- 组件间相互依赖性增强，跨组件网络通信增加
- 重用相同的 `query-frontend`/`query-scheduler`/`querier` 设置可能导致昂贵的查询耗尽规则评估的查询资源，反之亦然
- 如果需要为规则评估复制此设置，则会引入额外的复杂性（建议：参见下方的其他注意事项部分）
其他注意事项
如果此功能与 基于规则的分片结合使用，可能会带来进一步优化，但同时也要考虑一些额外的挑战。
旁注：`ruler` 默认按规则组进行分片，这意味着如果某些规则组的查询比其他规则组更昂贵，则规则在 `ruler` 实例之间可能分布不均。另一个后果是规则组顺序执行，因此昂贵的查询可能导致组中的后续规则延迟甚至遗漏。规则组并发评估。
基于规则的分片将规则均匀分布在所有可用的 `ruler` 实例上，每个规则在其自己的规则组中。因此，属于 `ruler` 实例的每个规则将并发评估（因为它们各自在自己的规则组中）。对于拥有数百或数千个规则的租户，如果这些规则都使用相同的间隔或恰好重叠，这可能导致大量查询快速连续地发送到 `query-frontend`。
假设远程规则评估发生在用于执行租户查询的同一读取路径上，运行大型多租户设置的操作员必须谨慎，确保大量查询能够在可接受的时间范围内接收、排队和处理。强烈建议在这种情况下使用 `query-scheduler` 组件，因为它将使 `query-frontend` 和 `query` 组件能够横向扩展以适应负载。还应实施 shuffle-sharding，以确保工作负载特别大的租户不会耗尽其他租户的查询资源。还应设置警报，以便在规则评估例行遗漏或租户的查询队列已满时通知操作员。
如果规则评估和租户查询相互拖慢，则需要复制读取路径设置，以便租户查询和规则评估不共享相同的查询执行资源。
基于规则的分片和远程评估可以（并且应该）分开实施。操作员应首先实施远程评估以提高 `ruler` 的可靠性，然后再进一步调查基于规则的分片，如果规则评估仍因规则组的顺序执行而被遗漏，或建议其租户拆分这些规则组。
