Prometheus Direct Instrumentation与Custom Collector选型及性能咨询

无第三方系统指标代理需求时是否需要部署Custom Collector #

绝大多数场景下完全不需要。
Custom Collector的核心适用边界非常清晰，只覆盖两类没法直接做原生埋点的场景：

• 对接本身不支持Prometheus指标暴露的第三方组件、老旧系统、硬件设备，把这些目标的非标准监控数据（比如SNMP数据、JMX未暴露的指标、老旧业务的日志/接口返回值）转换成Prometheus兼容的指标格式，也就是你提到的代理其他系统指标的场景
• 完全无法修改被监控目标的代码：比如采购的商业软件没有源码、历史遗留服务改代码的成本远高于搭旁路采集的成本，只能靠外部Collector旁路拉取、计算生成指标

如果你既不需要对接外部非Prometheus兼容的系统，又能掌控业务源码做直接埋点，额外部署Custom Collector纯属于多此一举，平白多一层运维链路和故障点。

Direct Instrumentation 与 Custom Collector 对采集性能的影响维度 #

两种方案的性能差异主要来自采集链路的架构区别，核心影响维度有四个：

• 运行时资源开销
  Direct Instrumentation是内嵌在业务进程里的埋点逻辑，指标直接存在业务进程内存中，Prometheus拉取时直接从内存读数据返回，没有额外的网络跳转、跨进程数据交互开销，只要不是无节制埋高基数指标，整体CPU、内存额外开销基本能控制在业务进程总资源的5%以内。
  Custom Collector是独立运行的进程，不管是采数据时调用被监控目标的接口、读日志、执行系统命令，还是拿到原始数据后做格式转换、指标计算，都要额外消耗独立的CPU、内存资源；如果Collector的采集逻辑写得不合理（比如每次拉取都全量扫描几GB日志、做无缓存的全量聚合），很容易出现采集超时、进程OOM的问题。就算是sidecar模式和业务实例1:1部署，整体资源开销也比直接内嵌埋点高20%~40%。
• 指标时效性与准确性
  Direct Instrumentation的指标计算和业务逻辑同步执行，比如请求计数、接口耗时、错误数这些指标都是业务请求处理过程中实时累加的，指标时间和业务实际发生时间完全对齐，没有额外延迟，不会出现数据断层。
  Custom Collector属于旁路采集，不管是轮询业务接口还是异步解析日志，都受采集间隔限制，天然存在几秒到几十秒的延迟；如果采集间隔内业务实例重启、Collector和目标之间网络闪断，还会直接丢失这段时间的指标，出现数据断点、毛刺，这部分虽然不算硬件资源层面的性能损耗，但会直接降低监控数据的可信度，间接增加排障成本。
• 扩缩容适配成本
  Direct Instrumentation完全跟着业务实例生命周期走，业务扩多少副本，埋点逻辑就跟着自动起多少，不需要单独为采集层做扩缩容配置，只要业务实例能正常对外提供服务，指标端点就能正常响应拉取请求，没有额外的运维适配成本。
  Custom Collector需要单独设计部署拓扑：如果是集中式部署，业务实例规模上涨后，Collector的采集并发、资源配额都要单独调优，很容易出现Collector成为整个采集链路的瓶颈，拖慢所有关联目标的采集速度；如果是sidecar模式部署，又要额外处理sidecar的生命周期管理、资源配置，运维复杂度高很多。
• 故障影响半径
  Direct Instrumentation的埋点逻辑和业务代码同进程运行，只要埋点逻辑没有低级错误（比如死循环、无限制内存分配），最多就是指标端点响应慢，不会影响核心业务逻辑；就算单个实例的埋点逻辑异常，也只会丢这一个实例的指标，不会波及其他服务。
  Custom Collector如果出现异常（比如采集逻辑死循环、请求频率配置过高、权限配置错误），轻则自己挂掉导致它负责的所有采集目标丢指标，重则高频采集请求把被监控的业务接口打挂，故障影响范围比直接埋点大得多。

内容的提问来源于stack exchange，提问作者johnydoey