从 Kubernetes 成为容器治理畛域的事实标准开始，基于云原生也就是基于 Kubernetes 原生。在云的体系下，根底硬件基本上都被抽象化、模糊化，硬故障须要人为干涉的频次在逐步升高，健康检查、失败自愈、负载平衡等性能的提供，也使得简略的、毁灭性的故障变少。而随着服务的拆分和模块的重叠，不可形容的、含糊的、莫名其妙的故障却比以前更加的频繁。
“看到指标”只是对于数据简略的出现，在目前云的环境下，并不能高效地帮忙咱们找到问题。而“可观测性”体现的是对数据的再加工，旨在挖掘出数据背地暗藏的信息，不仅仅停留在展示数据层面，更是通过对数据的解析和再组织，体现出数据的上下文信息。
为了达成“可观测性”的指标，就须要更加_标准化、简洁化的指标数据，以及更便捷的收集形式，更强更丰盛的语义表达能力，更快更高效的存储能力。_本篇文章将次要探讨时序指标的采集构造和采集形式，数据也是指时序数据，存储构造以及 tracing、log、event 等监控模式不在本次探讨范畴之内。
提到时序数据，让咱们先看看几个目前监控零碎比拟罕用的时序数据库：_opentsdb，influxdb，prometheus_ 等。
经典的时序数据根本构造大家都是有对立认知的：
- 惟一序列名标识，即指标名称；
- 指标的标签集，详细描述指标的维度；
- 工夫戳与数值对，详细描述指标在某个工夫点的值。
时序数据根本构造为指标名称 + 多个 kv 对的标签集 + 工夫戳 + 值，然而在细节上各家又各有不同。
1[
2{
3 "metric": "sys.cpu.nice",
4 "timestamp": 1346846400,
5 "value": 18,
6 "tags": {
7 "host": "web01",
8 "dc": "lga"
9 }
10},
11{
12 "metric": "sys.cpu.nice",
13 "timestamp": 1346846400,
14 "value": 9,
15 "tags": {
16 "host": "web02",
17 "dc": "lga"
18 }
19}
20]< 左右滑动以查看残缺代码 >
opentsdb 应用大家耳熟能详的 json 格局，可能是用户第一反馈中结构化的时序数据结构。只有理解根本时序数据结构的人一眼就能晓得各个字段的含意。
1<measurement>[,<tag_key>=<tag_value>[,<tag_key>= <tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]
2 例如：3cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000
< 左右滑动以查看残缺代码 >
1metric_name [2"{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"`} [","] "}"
3] value [timestamp]
4 例如：5http_requests_total{method="post",code="200"} 1027 1395066363000
< 左右滑动以查看残缺代码 >
5&wx_lazy=1&wx_co=1)
influxdb 和 prometheus 都应用了自定义文本格式的时序数据形容，通过固定的语法格局将 json 的树状层级构造打平，并且没有语义的失落，行级的表述模式更便于浏览。
- 文本格式劣势
○ 更合乎人类浏览习惯
○ 行级的表述构造对文件读取的内存优化更敌对
○ 缩小了层级的嵌套
- 文本格式劣势
○ 解析老本更高
○ 校验绝对更麻烦
wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)
应用过 Prometheus 的同学可能会留神到其实 Prometheus 的采集构造不是单行的，每类指标往往还随同着几行正文内容，其中次要是两类 HELP 和 TYPE，别离示意指标的简介阐明和类型。格局大略是：
1# Anything you want to say
2# HELP http_requests_total The total number of HTTP requests.
3# TYPE http_requests_total counter
4http_requests_total{method="post",code="200"} 1027 1395066363000
5http_requests_total{method="post",code="400"} 3 1395066363000
< 左右滑动以查看残缺代码 >
Prometheus 次要反对 4 类指标类型：
- Counter：只增不减的计数器。
- Gauge：可增可减的数值。
- Histogram：直方图，分桶采样。
- Summary：数据汇总，分位数采样。
其中 Counter 和 Gauge 很好了解，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 集群版本计划为商业版，暂不做探讨。
![]
上图为 opentsdb 架构图，其中：
- Servers：示意被采集数据的服务，C 则是示意采集指标的工具，能够了解为 opensdb 的 agent，servers 通过 C 将数据推送到上游的 TSD。
- TSD：对应理论过程名 TSDMain 是 opentsdb 组件，了解为接管层，每个 TSD 都是独立的，没有 master 和 slave 的辨别，也没有共享状态。
- HBase：opentsdb 理论的最终数据存储在 hbase 中。
从架构图能够看出，如果推送模式的数据量大量增长的状况下，能够通过多级组件，或者扩容无状态的接管层等形式较为简单的进行吞吐量的降级。
&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)
上图为 prometheus 架构图，次要看上面几个局部：
- Prometheus Server：用于抓取和存储工夫序列化数据。
- Exporters：被动拉取数据的插件。
- Pushgateway：被动拉取数据的插件。
拉取的形式，通常是监控端定时从配置的各个被监控端的 Exporter 处拉取指标。这样的设计形式能够升高监控端与被监控端的耦合水平，被监控端不须要晓得监控端的存在，这样将指标发送的压力从被监控端本义到监控端。
比照一下 pull 和 push 形式各自的优劣势：
- pull 的劣势
○ 上下游解耦
○ 被监控端不会因为 push 数据到监控端失败，而导致本身不稳固。
○ 监控端本身的压力状况基本上能够预测，升高因为被监控端突增的发送流量导致的本身危险，例如 DDoS。
○ 能够做到被监控端的主动发现机制。
○ 主动权在监控端这边，能够更灵便的配置须要监控什么，尤其是在调试过程中。
- pull 的劣势
○ 周期性不显著，或者周期显著短于采集周期的指标缺失精度。
○ 实时性较差。
○ 可能因为防火墙等简单的网络环境设置，导致拉取不到数据。
○ 如果数据有缺失，很难进行补数据。
简略比照了 pull 和 push 各自的特点，在云原生环境中，prometheus 是目前的时序监控规范，为什么会抉择 pull 的模式，这里有官网的解释（https://prometheus.io/docs/in…）。
下面简略介绍了一下从监控端视角对待数据采集形式的 pull 和 push 模式，而从被监控端来看，数据获取的形式就多种多样了，通常能够分为以下几种类型：
- 默认采集
- 探测采集
- 组件采集
- 埋点采集
上面一一举例说明。
默认采集通常是艰深意义上的所有人都会须要察看的根底指标，往往与业务没有强关联，例如 cpu、memory、disk、net 等等硬件或者零碎指标。通常监控零碎都会有特定的 agent 来固定采集这些指标，而在云原生中十分不便的应用 node_exporter、CAdvisor、process-exporter，别离进行节点机器、容器以及过程的根底监控。
探测采集次要是指 从内部采集数据的形式 。 例如域名监控、站点监控、端口监控等都属于这一类。采集的形式对系统没有侵入，因为对网络的依赖比拟强，所以通常会部署多个探测点，缩小因为网络问题造成的误报，然而须要特地小心的是，肯定要评估探测采集的频次，否则很容易对被探测方造成申请压力。
通常是指 曾经有现成的采集计划，只须要简略的操作或者配置就能够进行具体的指标采集，例如 mysql 的监控，redis 的监控等。在云原生环境中，这种采集形式比拟常见，得益于 prometheus 的发展壮大，常见的组件采集 exporter 层出不穷，prometheus 官网认证的各种 exporter。对于以下比拟非凡或者定制化的需要，也齐全能够依照 /metrics 接口标准本人实现自定义 exporter 的编写。
对于一个零碎的关键性指标，自身的研发同学是最有发言权的，通过埋点的形式能够 精准的获取相干指标。在 prometheus 体系中能够十分不便的应用 github.com/prometheus/client_* 的工具包来实现埋点采集。
本文对监控零碎的第一个阶段“采集”，从 “采集构造” 和“采集形式”两方面做了简略的介绍和梳理。相比于以往，在云原生的环境中，服务颗粒度拆分的更粗疏，迭代效率更高，从开发到上线造成了更快节奏的反馈循环，这也要求监控零碎可能更疾速的反映出零碎的异样，“采集构造”和“采集形式”尽管不是监控零碎最外围的局部，然而简洁的采集构造和便捷的采集形式也为后续实现“可观测性”提供了根底。目前在云原生环境中，应用 prometheus 能够十分方便快捷的实现监控，尽管仍有许多工作须要做，例如集群化、长久化存储等，然而随着 Thanos 等计划的呈现，prometheus 也在慢慢饱满中。