问题场景

OpenTelemetry Collector 常部署在应用与后端之间，承担 traces、metrics、logs 的接收、批处理和导出。当上游突发流量、后端响应变慢或导出队列堆积时，Collector 进程内存可能快速上涨；如果只依赖容器内存上限，进程可能被 OOM Kill，导致遥测数据中断。

memory_limiter 处理器的作用是在采集侧施加背压：按 check_interval 周期检查内存，当使用量接近配置上限时拒绝新数据，让上游重试或降速，为垃圾回收和队列排空争取时间。它本身不是丢弃器，被拒绝的数据是否丢失，取决于上游是否重试以及重试策略。

配置思路

• check_interval：检查周期。设置过短会增加开销，过长则可能在两次检查之间冲高。建议从 1s 起步，结合容器内存和流量特征调整。
• limit_mib：Collector 进程可用的内存预算，不是容器全部内存。应给操作系统、页缓存、Go 运行时、导出器缓冲和批处理留出余量。
• spike_limit_mib：可选的突发余量，使处理器在接近硬上限前开始拒绝数据，降低瞬时冲高风险。
• ballast_size_mib：预留一块常驻堆内存，用于稳定堆行为、减少 GC 抖动。它应明显小于 limit_mib，并且需要验证；部分 Collector 版本和运行时配置下不一定需要 ballast，不能盲目照搬。

示例值只用于演示，实际值要按进程内存预算和压测结果调整。

最小可运行示例

保存为 otelcol-config.yaml：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
    spike_limit_mib: 128
    ballast_size_mib: 128
  batch:
    timeout: 5s
    send_batch_size: 8192

exporters:
  debug:
    verbosity: basic

service:
  telemetry:
    logs:
      level: info
    metrics:
      level: detailed
      address: 0.0.0.0:8888
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [debug]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [debug]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [debug]

如果本地 Collector 版本不识别 debug 导出器，可将其改为 logging，并删除 verbosity 字段。处理器的顺序建议让 memory_limiter 尽量靠前，使背压更早生效；batch 放在其后，避免批处理缓存继续扩大。

运行与验证

使用本地二进制启动：

otelcol --config otelcol-config.yaml

如果安装的是 contrib 发行版，可执行 otelcol-contrib --config otelcol-config.yaml。随后让应用把 OTLP 数据发送到 localhost:4317 或 localhost:4318，并访问 http://localhost:8888/metrics 查看 Collector 自身指标。

重点观察两类指标：

1. 拒绝量：otelcol_processor_refused_spans、otelcol_processor_refused_metric_points、otelcol_processor_refused_log_records。可用 rate(...[5m]) 观察拒绝速率是否随流量或后端延迟上升。
2. 内存量：otelcol_process_runtime_heap_alloc_bytes、otelcol_process_runtime_total_sys_memory_bytes、otelcol_process_memory_rss。将内存曲线与拒绝量对照，判断限制是否生效。

不同版本的指标名称可能略有差异，应以 /metrics 实际输出为准。若拒绝量持续升高但内存仍然逼近上限，应检查 limit_mib 是否超过容器预算、check_interval 是否过长、ballast 是否设置不当，以及导出器和队列是否占用了额外内存。

边界与限制

memory_limiter 提供的是进程级背压，不是容量规划替代品。它不能限制所有内存来源，也不能保证被拒绝的数据一定不丢；如果上游不重试，拒绝就可能变成数据丢失。上游重试也可能带来流量放大，需要配合退避、队列和限流策略。

limit_mib 不要设置成容器内存上限，应留出安全余量；check_interval 过长会在检查间隔内 overshoot，过短则增加检查开销。ballast_size_mib 不是越大越好，设置前应确认目标版本的行为，并通过压测验证。最后，仍应保留容器内存限制、告警和日志监控，避免把 memory_limiter 当作唯一的 OOM 防护手段。