OpenTelemetry Collector memory_limiter 限制内存峰值的配置方法

OpenTelemetry Collector 的内存峰值控制，核心不是把 batch 队列调小，而是在目标 pipeline 前面启用 memory_limiter。它会按周期检查进程堆内存，接近软限制时对上游施加回压，超过硬限制时拒绝新的遥测数据。官方配置入口可复制查看：https://opentelemetry.io/docs/collector/configuration/。

先分清 memory_limiter 管的是什么

memory_limiter 管的是 Collector 进程堆内存，不是某个 exporter 的发送成功率。导出端不可用时，队列可能继续保留数据；如果队列、批处理和输入速率叠加，进程就会出现内存压力。因此它应该是整个数据管道的保护层，而不是故障后才临时添加的开关。

参数含义可以先按下面的关系理解：

用 limit_mib 配置一个可解释的上限

单机规格固定时，优先用绝对值便于和容器 limit、节点余量对照。下面的 YAML 是静态配置示例，注释说明了关键边界：

processors:
  memory_limiter:
    # 硬限制：目标是限制 Go 堆，不等于进程全部 RSS
    limit_mib: 2048
    # 为两次检查之间的突发流量预留约 20% 余量
    spike_limit_mib: 400
    # 高频检查能更早发现内存压力
    check_interval: 1s

service:
  pipelines:
    traces:
      # 处理器必须在 pipeline 中引用，声明本身不会启用
      processors: [memory_limiter, batch]
      receivers: [otlp]
      exporters: [otlp]

这个例子里，软限制可近似理解为 2048 - 400 = 1648 MiB。Collector 的总进程占用通常会高于堆限制，所以不要把 limit_mib 直接写成容器内存上限；还要给运行时、组件和系统留空间。

把处理器放进正确的 pipeline

常见失误是只写了 processors: 配置，却没有在 service.pipelines 中引用；另一种失误是把它放在 batch 后面。更稳妥的顺序是先限制内存，再批量整理，最后交给 exporter。这样批处理器产生的缓存也处在保护范围内。

如果 traces、metrics、logs 都可能打满内存，需要分别在对应 pipeline 引用它。每个 pipeline 会得到自己的处理器实例，不能因为 traces 已配置，就默认 metrics 也被保护。

用拒绝指标判断参数是否过紧

不要只看进程有没有重启。Collector 的内部指标可以帮助定位“保护生效”和“保护过度”的区别，例如 otelcol_processor_refused_spans、otelcol_processor_refused_metric_points 和 otelcol_processor_refused_log_records。短时上升说明 limiter 正在施加压力；如果持续增长且下游健康，应检查输入峰值、队列容量和容器资源，而不是简单把硬限制调到最大。

官方处理器文档还建议配合 GOMEMLIMIT 使用，让 Go 运行时的目标与 Collector 的内存保护策略保持一致。两者不是同一个参数：前者影响运行时回收节奏，后者在 pipeline 层面对数据施加保护。

常见问题

limit_mib 和 limit_percentage 该选哪个？

容器规格稳定、需要固定预算时选 limit_mib；部署规格随节点变化时可考虑百分比，但仍要核对容器实际可用内存和峰值余量。

refused 指标偶尔增加就是配置错误吗？

不一定。短时突发中拒绝少量数据可能正是保护机制在工作；持续增长才需要结合流量、队列和下游可用性判断是否过紧。

为什么配置了 memory_limiter 仍然会 OOM？

它限制的是目标堆内存，不是全部进程占用；如果容器额度过小、队列过大或检查周期不合适，仍可能越过实际资源边界。