管理

在生产环境中运行

生产环境提示

开源

Grafana Mimir 生产环境提示

本主题提供在设置生产环境 Grafana Mimir 集群时需要考虑的提示和技巧。

Ingester

确保文件描述符最大打开数较高

Ingester 接收来自 distributor 的样本，并将接收到的样本附加到存储在 ingester 本地磁盘上的特定租户 TSDB 中。每个租户的 TSDB 由多个文件组成，ingester 为每个 TSDB 文件保持一个打开的文件描述符。用于加载 TSDB 文件的文件描述符总数与 Grafana Mimir 集群中的租户数量以及配置的 -blocks-storage.tsdb.retention-period 成线性增加。

我们建议调整以下设置以避免达到最大文件描述符打开数

将系统的 file-max ulimit 配置为至少 65536。当 Grafana Mimir 集群中有超过一千个租户时，将此限制增加到 1048576。
启用 ingester 的 shuffle sharding 以减少每个 ingester 的租户数量。

Ingester 磁盘空间要求

Ingester 将接收到的样本写入预写日志 (WAL)，默认情况下每两小时将它们压缩成一个新块。WAL 和块都临时存储在本地磁盘上。所需的磁盘空间取决于 ingester 中存储的时间序列数量以及配置的 -blocks-storage.tsdb.retention-period。

有关估计 ingester 磁盘空间要求的更多信息，请参阅容量规划。

Ingester 磁盘 IOPS

Ingester 磁盘的 IOPS（每秒输入/输出操作次数）和延迟会影响写入和读取请求。在写入路径上，ingester 将数据写入磁盘上的预写日志 (WAL)。在读取路径上，ingester 读取已写入磁盘的 chunk 的时间序列数据。

因此，建议在 SSD 等具有快速磁盘速度的磁盘上运行 ingester。

基于资源利用率的 ingester 读取路径限制

Ingester 支持根据资源（CPU/内存）利用率限制读取请求，以保护写入路径。在生产环境中，ingester 的写入路径通常被认为比读取路径更重要，因此在 ingester 负载过高时限制读取请求通常比导致写入失败（甚至崩溃）更好。

我们建议启用基于资源利用率的 ingester 读取路径限制，以保护 ingester 免受潜在的昂贵查询的压垮。有关其配置的更多信息，请参阅ingester。

Querier

确保缓存已启用

Querier 支持缓存以减少对长期存储的 API 请求数量。

我们建议在 querier 中启用缓存。有关配置缓存的更多信息，请参阅querier。

避免查询未压缩的块

在大规模运行 Grafana Mimir 时，查询未压缩的块可能会由于以下原因而效率低下

未压缩的块包含重复的样本，这是 ingester 复制的结果。
查询许多小的 TSDB 索引比查询少量压缩的 TSDB 索引要慢。

-querier.query-store-after、-querier.query-ingesters-within 和 -blocks-storage.bucket-store.ignore-blocks-within 的默认值设置确保只查询已压缩的块。在大多数情况下，不需要额外的配置。

配置 Grafana Mimir，以便 compactor 可以并行处理大型租户

为每个拥有超过 2000 万个活动时间序列的租户配置 compactor 的 -compactor.split-and-merge-shards 和 -compactor.split-groups。有关配置 compactor 分割和合并分片的更多信息，请参阅compactor。

如何估算 `-querier.query-store-after`

如果你不使用默认设置，将 -querier.query-store-after 设置为一个足够长的持续时间，以便 compactor 有足够的时间压缩新上传的块，并且 querier 和 store-gateway 有足够的时间发现和同步新压缩的块。

以下图表显示了估算中涉及的所有时间点。此图表仅应作为模板使用，你可以根据你的 Mimir 集群中的实际测量值修改假设。本示例做出以下假设

一个 ingester 将一个块上传到存储需要长达 30 分钟
Compactor 将所有 ingester 发送的两小时块压缩需要长达三小时
Querier 和 store-gateway 发现和加载新压缩块需要长达 15 分钟

基于这些假设，在最坏的情况下，从样本被摄取到样本被附加到刷新到存储的块中，并且该块与所有从 ingester 发送的其他重叠的两小时块进行垂直压缩，最多需要六小时四十五分钟。

Store-gateway

确保缓存已启用

Store-gateway 支持缓存，可以减少对长期存储的 API 调用次数并提高查询性能。

我们建议在 store-gateway 中启用缓存。有关配置缓存的更多信息，请参阅store-gateway。

确保文件描述符最大打开数较高

Store-gateway 将每个块的索引头存储在本地磁盘上，并通过内存映射加载。Store-gateway 为在给定时间加载的每个索引头保持一个打开的文件描述符。用于加载索引头的文件描述符总数与 store-gateway 实例拥有的块数量成线性增加。

我们建议将系统的 file-max ulimit 配置为至少 65536，以避免达到最大文件描述符打开数。

Store-gateway 磁盘 IOPS

Store-gateway 磁盘的 IOPS 和延迟会影响查询。Store-gateway 将块的索引头下载到本地磁盘，并在需要从长期存储获取数据的每次查询时读取它们。

因此，建议在 SSD 等具有快速磁盘速度的磁盘上运行 store-gateway。

Compactor

确保 compactor 有足够的磁盘空间

Compactor 需要大量磁盘空间来从长期存储下载源块，并在将压缩块上传到存储之前临时存储。有关所需磁盘空间的更多信息，请参阅Compactor 磁盘利用率。

缓存

确保 Memcached 已正确扩容

我们建议确保 Memcached 驱逐不频繁发生。如果你的 Memcached 集群频繁驱逐项目，Grafana Mimir 查询性能可能会受到负面影响。我们建议增加 Memcached 集群副本数量，为集群添加更多内存并减少驱逐。

我们还建议为每种类型的缓存运行一个专用的 Memcached 集群，因为 Mimir 对每种缓存的使用方式不同，并且它们的扩缩容方式也不同。分离还可以隔离每种缓存，以便一种类型的缓存条目不会挤占其他条目并降低性能。

元数据缓存存储关于对象存储中文件的信息、辅助文件（如 bucket 索引）的内容以及关于对象存储的发现信息（如租户列表）。这导致 CPU 和带宽使用率相对较低。

查询结果缓存存储查询响应。此缓存中的条目通常较小，Mimir 每次只获取少量条目。这导致 CPU 和带宽使用率相对较低。

索引缓存存储从对象存储获取的 TSDB 索引的一部分。此缓存中的条目大小从几百字节到几兆字节不等。Mimir 可以单独或批量获取条目。单个查询可能会从缓存中获取许多条目。与其他缓存相比，这导致 CPU 使用率更高。

Chunk 缓存存储从对象存储获取的时间序列样本的一部分。此缓存中的条目通常较大（几千字节），并由 store-gateway 组件批量获取。与其他缓存相比，这导致带宽使用率更高。

缓存大小

Memcached 的 extstore 功能允许将 Memcached 的内存空间扩展到闪存（或类似）存储上。

请参阅我们如何将 Grafana Cloud Logs 的 Memcached 集群扩展到 50TB 并提高可靠性。

安全

我们建议保护 Grafana Mimir 集群的安全。有关保护 Mimir 集群的更多信息，请参阅保护 Grafana Mimir 安全。

网络

Mimir 组件之间的大多数通信通过 gRPC 进行。gRPC 连接默认不使用任何压缩。

如果网络吞吐量是一个问题或成本较高，你可以在组件之间的 gRPC 连接上启用压缩。这会降低网络吞吐量，但会增加 CPU 使用率。你可以选择 gzip 和 snappy。Gzip 提供比 snappy 更好的压缩率，但会消耗更多的 CPU。

你可以使用 Squash Compression Benchmark 来选择 snappy 和 gzip。对于 protobuf 数据，snappy 的压缩比约为 5，压缩速度约为 400MiB/s。对于相同的数据，gzip 的压缩比在 6 到 8 之间，速度在 50MiB/s 到 135 MiB/s 之间。

要配置 gRPC 压缩，请使用以下 CLI 标志或其 YAML 等效项。可接受的值为 snappy 和 gzip。如果将标志设置为空字符串（''），则会明确禁用压缩。

CLI 标志	YAML 选项
`-query-frontend.grpc-client-config.grpc-compression`	`alertmanager.alertmanager_client.grpc_compression`
`-query-scheduler.grpc-client-config.grpc-compression`	`frontend.grpc_client_config.grpc_compression`
`-ruler.client.grpc-compression`	`frontend_worker.grpc_client_config.grpc_compression`
`-ruler.query-frontend.grpc-client-config.grpc-compression`	`ingester_client.grpc_client_config.grpc_compression`
`-alertmanager.alertmanager-client.grpc-compression`	`query_scheduler.grpc_client_config.grpc_compression`
`-ingester.client.grpc-compression`	`ruler.query_frontend.grpc_client_config.grpc_compression`

高度多租户

对于每个租户，Mimir 会在内存中打开并维护一个 TSDB。如果你有大量租户，内存开销可能会变得非常大。为了减少相关的开销，请考虑以下几点

减小 -blocks-storage.tsdb.head-chunks-write-buffer-size-bytes，默认值为 4MB。例如，尝试 1MB 或 128KB。
减小 -blocks-storage.tsdb.stripe-size，默认值为 16384。例如，尝试 256，甚至 64。
配置shuffle sharding

切割块时出现周期性延迟尖峰

根据工作负载的不同，你可能会在 Mimir 切割块时看到延迟尖峰。为了减少此行为的影响，请考虑以下几点

升级到 2.15+。请参阅 https://github.com/grafana/mimir/commit/03f2f06e1247e997a0246d72f5c2c1fd9bd386df。
减小 -blocks-storage.tsdb.block-ranges-period，默认值为 2h。例如，尝试 1h。