Prometheus 批处理失败

给 OpenTelemetry Collector 的 prometheus exporter 加上 sending_queue.batch，启动校验却报 num_consumers must be positive；补上消费者数量后，又报 queue_size must be positive。同样的批处理片段用在 OTLP exporter 能通过时，应检查各组件是否初始化了相同的队列默认值。

contrib 0.161.0 的 Prometheus exporter 没有初始化标准队列配置。已核对的稳定版 0.162.0 工厂也保留这一差别，因此仅填写 batch 不能假定消费者数量和队列容量会自动采用推送型 exporter 的默认值。

显式填写启用的队列参数

Prometheus exporter 默认没有这份可选队列配置。添加 sending_queue 后，队列校验要求 num_consumers 和 queue_size 都为正数；修正第一项不代表第二项也已满足。

如果确实需要这一层队列与批处理，可以在已有 exporters.prometheus 配置中补齐参数。下面只是队列片段，保留原 endpoint、访问控制、指标处理和 service pipeline：

sending_queue:
  num_consumers: 10
  queue_size: 1000
  sizer: items
  batch:
    flush_timeout: 5s
    min_size: 512

这些数值说明参数关系，不是生产容量建议。sizer: items 表示队列按遥测条目计量，不是 1000 字节，也不是 1000 个请求。未另设 batch sizer 时，它会采用队列的计量方式；同一计量方式下，queue_size 不能小于 min_size。

消费者数量、条目大小、采集速率与等待时间都影响资源和延迟，应该按应用需求选择。不要只把零改成一个很大的数，再以配置通过证明运行没有问题。

先确认是不是需要增加这一层

这里的 prometheus 是提供抓取端点的 exporter，与将数据主动推送到远端的 OTLP 或 Prometheus Remote Write exporter 不同。它们可以共享部分队列校验代码，但配置工厂与传输方式并不相同。

若这份队列是新迁移时误加、原流程并不要求它，可以撤回此次新增的 sending_queue，恢复之前的接收与指标暴露方式。保留已有处理器和 pipeline，不必为了一个队列默认值问题重写整条指标链路。

是否采用批处理要结合实际摄入、积累和抓取行为判断，不能由一次校验失败推导为“所有 Prometheus 指标都必须批处理”，也不能把它当成已经证实的性能优化。

校验通过后，再看指标是否可抓取

记录实际运行的 Collector 二进制或镜像版本，确认包含 prometheus exporter，用同一版本校验完整配置。文件可解析、进程能启动，只说明配置和启动阶段通过。

继续检查预定抓取端点是否能返回需要的指标，batch 等待后的指标新鲜度是否符合要求，队列与其他 pipeline 是否保持健康。保持原来的网络、TLS 和认证限制，不要把端点改为公网开放来方便验收。

入队成功不等于下游已看到数据。增加的队列也不自动表示数据持久化；应按实际 storage 配置和部署行为判断进程退出时的影响。

修改前保留完整配置与可恢复构建。若新增队列造成指标延迟或资源回归，按原部署方式恢复本次调整，保留错误与抓取结果作对照；不要清空持久存储来消除校验错误。