云原生在易迅|云原生时代下的监控：如何基于云原生进行指标采集？

　　云原生在易迅|云原生时代下的监控：如何基于云原生进行指标采集？

　　Prometheus主要支持4类：

　　Counter：只增不减的计数器

　　Gauge：可增可减的数值

　　Histogram：直方图，分桶取样

　　Summary：数据汇总，分位数取样

　　其中 Counter 和 Gauge 很好理解，Histogram 和 Summary 可能一时间会使人蒙蔽。其实 Histogram 和 Summary 都是为了从不同维度解决和过滤长尾问题。

　　例如，我和首富的平均身家并不能真实反映出我自己的身家。因此分桶或则分位数能够更准确的描述数据真实的分布状态。

　　而 Histogram 和 Summary 主要区别就在于对分位数的估算上，Histogram 在客户端只进行分桶估算，因此可以在服务端进行整体的分位数估算。Summary 则是在客户端环境下估算了分位数，因此丧失了在整体视图上进行分位数估算的可能性。官方也给下来 Histogram 和 Summary 的区别：

　　Histogram

　　Summary

　　所需配置

　　需要设置期望的分桶范围

　　需要设置期望的分位数以及滑动窗口大小

　　客户端性能消耗

　　消耗较低，只须要增量估算

　　比较费性能，因为须要流式分位数估算

　　服务器端性能消耗

　　需要估算分位数，消耗较高，如果耗费时间很长，可以尝试使用预聚合

　　消耗较低

　　时间序列

　　一个分桶一个

　　一个分位数一个

　　分位数偏差

　　误差取决于分桶的数目和桶的大小

　　误差取决于分位数的值

　　分位数与时间窗口

　　查询时指定

　　采集时指定

　　聚合

　　查询时指定

　　通常不可做聚合

　　需要说明的是，截止到目前为止的 Prometheus 版本 2.20.1，这些 metric types 仅仅使用在客户端库（client libraries）和传输合同（wire protocol）中，服务端暂时没有记录那些信息。所以假如你对一个 Gauge 类型的指标使用 histogram_quantile(0.9,xxx) 也是可以的，只不过由于没有 xxx_bucket 的存在，计算不下来值而已。

　　采集方式

　　时序监控数据的采集，从监控端来看，数据获取的方式只有两种，pull 和 push，不同的采集方式也决定了布署形式的不同。

　　还是通过 opentsdb，prometheus 来举例，因为 influxdb 集群版本方案为商业版，暂不做讨论。

　　push形式

　　上图为 opentsdb构架图 ，其中：

　　Servers：表示被采集数据的服务，C则是表示采集指标的工具，可以理解为 opensdb 的agent，servers通过C将数据推送到下游的TSD；

　　TSD：对应实际进程名TSDMain是opentsdb组件，理解为接收层，每个TSD都是独立的，没有master和slave的分辨，也没有共享状态；

　　HBase：opentsdb实际的最终数据储存在hbase中；

　　从构架图可以看出，如果推送方式的数据量大量下降的情况下，可以通过多级组件，或者扩容无状态的接收层等方法较为简单的进行吞吐量的升级。

　　pull形式

　　上图为prometheus构架图，主要看下边几个部份：

　　Prometheus Server：用于抓取和储存时间序列化数据

　　Exporters：主动拉取数据的插件

　　Pushgateway：被动拉取数据的插件

　　拉取的方法，通常是监控端定时从配置的各个被监控端的 Exporter 处拉取指标。这样的设计方法可以减少监控端与被监控端的耦合程度，被监控端不需要晓得监控端的存在，这样将指标发送的压力从被监控端通配符到监控端。

　　对比一下pull和push形式各自的优劣势：

　　l pull的优势

　　n 上下游前馈

　　n 被监控端不会由于push数据到监控端失败，而造成自身不稳定

　　n 监控端自身的压力情况基本上可以预测，降低由于被监控端突增的发送流量造成的自身风险，例如DDoS

　　n 可以做到被监控端的手动发觉机制

　　n 主动权在监控端那边，可以更灵活的配置须要监控哪些，尤其是在调试过程中

　　l pull的劣势

　　n 对于周期性不显著，或者周期显著短与采集周期的指标缺位精度

　　n 实时性较差

　　n 可能因为防火墙等复杂的网路环境设置，导致拉取不到数据

　　n 如果数据有缺位，很难进行补数据

　　简单对比了pull和push各自的特征，在云原生环境中，prometheus 是目前的时序监控标准，为什么会选择pull的方式，这里有（）。

　　上面简单介绍了一下从监控端视角看待数据采集方式的pull和push方式，而从被监控端来看，数据获取的方法就多种多样了，通常可以分为以下几种类型：

　　1.默认采集

　　2.探测采集

　　3.组件采集

　　4.埋点采集

　　下面一一举例说明。

　　默认采集

　　默认采集通常是浅显意义上的所有人就会须要观察的基础指标，往往与业务没有强关联，例如cpu、memory、disk、net等等硬件或则系统指标。通常监控系统就会有特定的agent来固定采集这些指标，而在云原生中十分便捷的使用 node_exporter、CAdvisor、process-exporter，分别进行节点机器、容器以及进程的基础监控。

　　探测采集

　　探测采集主要是指从外部采集数据的形式。例如域名监控、站点监控、端口监控等都属于这一类。采集的形式对系统没有侵入，因为对网路的依赖比较强，所以一般会布署多个侦测点，减少由于网路问题引起的误报，但是须要非常当心的是，一定要评估侦测采集的频次，否则很容易对被探测方导致恳求压力。

　　组件采集

　　通常是指早已有现成的采集方案，只须要简单的操作或则配置就可以进行详尽的指标采集，例如mysql的监控，redis的监控等。在云原生环境中，这种采集方式比较常见，得益于prometheus的发展壮大，常见的组件采集exporter层出不穷，prometheus官方认证的各类exporter。对于以下比较特殊或则多样化的需求，也完全可以根据/metrics插口标准自己完成自定义exporter的编撰。

　　埋点采集

　　对于一个系统的关键性指标，本身的研制朋友是最有发言权的，通过埋点的形式可以精准的获取相关指标。在prometheus体系中可以十分便捷的使用/prometheus/client_*的工具包来实现埋点采集。

　　总结

　　本文对监控系统的第一个阶段“采集”，从“采集结构”和“采集方式”两方面做了简单的介绍和梳理。相比于往年，在云原生的环境中，服务颗粒度分拆的更细致，迭代效率更高，从开发到上线产生了更快节奏的反馈循环，这也要求监控系统才能更快速的反映出系统的异常，“采集结构”和“采集方式”虽然不是监控系统最核心的部份，但是简约的采集结构和方便的采集方式也为后续实现“可观测性”提供了基础。目前在云原生环境中，使用 prometheus 可以十分便捷快捷的实现监控，虽然仍有许多工作须要做，例如集群化、持久化储存等，但是随着 Thanos 等方案的出现，prometheus也在逐渐丰腴中。