五种度量器类型与拉取推送两种采集方式及Prometheus的折中设计

度量指标收集要解决两个问题。”如何定义指标”：不管目标系统是什么，指标 的数据类型都逃不出几种共性形态——计数度量器（Counter，可加减的合计量， 如服务调用次数）、瞬态度量器（Gauge，某时点的数值，不涉及加减，如JVM 堆内存当前用量）、吞吐率度量器（Meter，单位时间内事件发生次数，如TPS）、 直方图度量器（Histogram，样本与某属性的二维分布，如历年GDP变化）、 采样点分位图度量器（Quantile Summary，验证实际值与理论分布的拟合度， 如高考成绩是否符合正态分布）；Prometheus支持其中Counter/Gauge/Histogram/ Summary四种。”如何把指标告诉服务端”有拉取式（度量系统主动去目标系统 拉）和推送式（目标系统主动推给度量系统）两条路线，没有绝对优劣—— Ganglia/Graphite/StatsD等老牌系统偏推送，Prometheus/Datadog/Collectd 等新一代系统偏拉取；一个度量系统通常只专注支持一种，因为采集方式直接 决定了整个系统要处理的连接数量级和线程/协程架构设计。Prometheus本身 坚持拉取式，但用一个独立的中介模块Push Gateway来有限度兼容推送场景—— 目标系统把指标推给Push Gateway暂存，再等Prometheus Server按正常节奏 去拉。这个设计专门针对拉取式的固有缺陷：目标系统在NAT后的内网，外部 Prometheus根本连不进去；或者是生命周期极短的小型服务，可能等不到 Prometheus来拉就已经退出运行了——这两种场景只能靠目标系统自己主动推送。