Prometheus原理和源码分析.docxVIP

Prometheus原理和源码分析 Go客户端实现了Prom数据协议，定义了时序数据模型和采集监控数据的接口（源码分析基于/prometheus/client_golang/tree/661e31bf844dfca9aeba15f27ea8aa0d485ad212）。 全体结构分析 无论是Prom拉取(pull)数据，还是客户端自动推送(push)数据，都可以从Collector猎取Metric的定义，图1.1.1中UML图描述了Go客户端中次要结构和接口之间的关系。 图 1.1.1 Go客户端UML图 先看Collector接口的定义，如图1.1.2所示。 图1.1.2 Collector Collector中Describe和Collect方法都是无形态的函数，其中Describe暴露全部可能的Metric描述列表，在注册（Register）或登记（Unregister）Collector时会调用Describe来猎取完整的Metric列表，用以检测Metric定义的冲突，另外在 /prometheus/client_golang/prometheus/promhttp 下的Instrument Handler中，也会通过Describe猎取Metric列表，并检查label列表（InstrumentHandler中只支持code和method两种自定义label）；而通过 Collect 可以猎取采样数据，然后通过HTTP接口暴露给Prom Server。另外，一些临时性的进程，如批处理任务，可以把数据push到Push Gateway，由Push Gateway暴露pull接口，此处不赘述。 客户端对数据的收集大多是针对标准数据结构来进行的： Counter：收集大事次数等单调递增的数据 Gauge：收集当前的形态，比如数据库连接数 Histogram：收集随机正态分布数据，比如响应延迟 Summary：收集随机正态分布数据，和Histogram是类似的 每种标准数据结构还对应了Vec结构，通过Vec可以简约的定义一组相同性质的Metric，在采集数据的时候传入一组自定义的Label/Value猎取具体的Metric（Counter/Gauge/Histogram/Summary），最终都会落实到基本的数据结构上，这里不再赘述。 Counter和Gauge Gauge和Counter基本实现上看是一个进程内共享的浮点数，基于value结构实现，而Counter和Gauge仅仅封装了对这个共享浮点数的各种操作和合法性检查规律。 先看Counter中Inc函数的实现，图1.2.1为value结构中Inc函数的实现。 图1.2.1 value.Inc value.Add中修改共享数据时接受了“无锁”实现，相比“有锁(Mutex)”实现可以更充分利用多核处理器的并行计算力量，功能相比加Mutex的实现会有很大提升。图1.2.2中是Go Benchmark的测试结果，对比了“有锁”（用defer或不用defer来释放锁）和“无锁”实现在多核场景下对功能的影响。 图1.2.2 Go Benchmark测试结果 留意图1.2.2中针对“有锁”的实现，进行了两组试验，其中一组用defer来释放锁，可见在多核场景下“无锁”实现的功能最好也最稳定。 Counter和Gauge中的其他操作都很简约，不赘述。 Histogram Histogram实现了Observer接口，用来猎取客户端形态初始化（重启）到某个时间点的采样点分布，监控数据常需要听从正态分布。 图1.3.1 Oberver接口定义 先看通过Histogram采集一个float64数据的Observe方法实现（图1.3.2）。 图1.3.2 histogram.Observe 此处每个bucket对应的count是不相互包含的，bucket的计数器之和应当等于全局计数器，即h.count == sum(h.counts)是成立的。然而为了便于服务端存储和计算，最终服务端收集到的数据是向下包含的，这是在histogram.Write（图1.3.3）中实现的。 图1.3.3 histogram.Write实现 图1.3.4中用表格方式给出了Histogram采集和整理数据的过程。 图1.3.4 Histogram采集整理数据过程实例 Histogram在客户端也是无锁的，由于每个采样点只更新一个具体bucket内的Counter（float64），因而客户端功能开销相比Counter和Gauge而言没有明显转变，适合高并发的数据收集。 图1.3.5为Go客户端的Histogram默认bucket设置，可以用来采集Web服务响应时间，实际应用中通常需要为监控对象选择合理的bucket