管理大型生产部署

当需要由于日志量增加而扩展 Loki 时，操作员应考虑按角色（接收器、分发器、查询器等）划分运行多个 Loki 进程，而不是单个 Loki 进程。Grafana Labs 的生产设置包含 .libsonnet 文件，这些文件演示了如何配置独立组件并根据资源使用情况进行扩展。

独立的 Query Scheduler

Query frontend 有一个内存队列，可以将其移出到单独的进程中，类似于 Grafana Mimir 的 query-scheduler。这允许运行多个 query frontend。

要使用 Query Scheduler 运行，需要通过 -frontend.scheduler-address 将调度器的地址传递给 frontend，并且 querier 进程需要通过将 -querier.scheduler-address 设置为相同地址来启动。这两个选项也可以通过配置文件进行定义。

使用配置的 frontend 和调度器地址同时启动 querier 是无效的。

Query scheduler 进程本身可以通过 Loki Docker 镜像的 -target=query-scheduler 选项启动。例如，docker run grafana/loki:latest -config.file=/etc/loki/config.yaml -target=query-scheduler -server.http-listen-port=8009 -server.grpc-listen-port=9009 将启动 Query scheduler，监听端口 8009 和 9009。

内存 Ballast

在计算资源受限的环境中，垃圾回收可能成为重要的性能因素。频繁运行的垃圾回收会占用 CPU 资源，干扰应用程序的运行。使用内存 ballast 可以缓解这个问题。内存 ballast 会分配额外但未使用的虚拟内存，以增大存活堆空间的大小。垃圾回收由堆空间使用量的增长触发。增大的堆空间量会降低感知到的增长，从而减少垃圾回收的频率。

使用 ballast_bytes 配置选项配置内存 ballast。

远程规则评估

此功能最初在 LID-0002 中提出；其中包含指导实现的设计决策。

默认情况下，ruler 组件会嵌入一个查询引擎来评估规则。这通常工作正常，除非规则复杂或需要定期处理大量数据。ruler 性能不佳的表现是记录规则的指标出现空隙或遗漏警报。当 loki_prometheus_rule_group_iterations_missed_total 指标值非零时，可以通过对其设置警报来检测这种情况。

解决此问题的一种方法是将规则评估从 ruler 进程中外部化。ruler 内嵌的查询引擎是单线程的，这意味着规则不会像常规 Loki 查询那样被拆分、分片或以其他方式加速。query-frontend 组件专门为此目的而存在，与多个 querier 实例结合使用时，可以显著提高规则评估性能并减少遗漏的迭代。

通常建议创建一个独立的 query-frontend 部署和 querier 池，与您现有的（通过 Grafana、logcli 或 API 处理临时查询）分开。规则应优先于临时查询，因为它们用于生成对于服务可靠运行至关重要的指标或警报；如果您为两者使用相同的 query-frontend 和 querier 池，您的规则将与临时查询以相同的优先级执行，这可能导致不可预测的性能。

要启用远程规则评估，请设置以下配置选项

ruler:
  evaluation:
    mode: remote
    query_frontend:
      address: dns:///<query-frontend-service>:<grpc-port>

有关更多配置选项，请参见此处。

启用远程规则评估后，ruler 组件将成为 query-frontend 服务的 gRPC 客户端；这将导致 ruler 资源使用量大幅降低，因为大部分工作已外部化。来自 ruler 的 LogQL 查询将针对指定的 query-frontend 服务执行。如果使用 dns:/// 前缀，请求将在所有 query-frontend IP 之间进行负载均衡。