云优采集接口( _本篇、简洁化的指标数据基本结构(组图))

　　云优采集接口(

_本篇、简洁化的指标数据基本结构(组图))

　　

　　由于 Kubernetes 成为容器管理的事实标准，云原生就是 Kubernetes 原生。云系统下，基础硬件基本被抽象化和模糊化，需要人为干预的硬故障发生频率逐渐降低。更少的失败。随着服务的拆分和模块的堆叠，难以描述、模棱两可、莫名其妙的故障比以前更加频繁。

　　“看指标”只是数据的简单呈现。在当前的云环境下，它并不能有效地帮助我们发现问题。“可观察性”体现的是对数据的再加工，旨在挖掘出数据背后隐藏的信息，不仅在展示数据的层面，还通过对数据的分析和重组来体现数据的上下文信息. .

　　为了实现“可观察性”的目标，需要更规范、更简洁的指标数据，以及更便捷的采集方式、更强更丰富的语义表达能力、更快更高效的存储能力。_本文文章将主要讨论时间序列指标的采集结构和采集方法。数据也指时间序列数据。跟踪、日志、事件等存储结构和监控形式不在本文讨论范围之内。之内。

　　

　　说到时序数据，我们来看看监控系统中常用的几个时序数据库：_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[,=[,= ]] =[,=] []

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可能会让人一时糊涂。事实上，Histogram 和 Summary 都是为了解决和过滤不同维度的长尾问题而设计的。

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

　　直方图和摘要之间的主要区别在于分位数的计算。Histogram 只在客户端进行桶计算，所以整体分位数计算可以在服务端进行。Summary 在客户端环境中计算分位数，因此失去了在整体视图上计算分位数的可能性。官方还给出了Histogram和Summary的区别：

　　

　　需要注意的是，截至目前的Prometheus版本2.20.1，这些metric类型只用在客户端库和wire协议中，服务器暂时不记录这些信息。所以如果使用 histogram_quantile(0.9,xxx) 作为 Gauge 类型的指标，也是可以的，但是因为没有 xxx_bucket，所以无法计算数值。

　　

　　对于时序监控数据的采集，从监控端来说，数据获取只有拉取和推送两种形式。不同的采集方法也决定了不同的部署方式。

　　我们以opentsdb和prometheus为例，因为influxdb集群版方案是商业版，所以暂不讨论。

　　![]

　　

　　

　　上图为opentsdb架构图，其中：

　　从架构图中可以看出，如果推送形式的数据量大幅增加，通过使用多级组件或扩展无状态接收层，可以相对简单地提升吞吐量。

　　

　　&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

　　

　　上图为prometheus架构图，主要看以下几部分：

　　拉取方式通常是监控终端定期从各个监控终端配置的Exporter中拉取指标。这种设计方法可以降低监控终端与被监控终端之间的耦合度，被监控终端不需要知道监控终端的存在，从而摆脱了监控终端向监控终端发送指标的压力。

　　比较 pull 和 push 方法的优缺点：

　　拉和推特性的简单比较。在云原生环境中，prometheus 是目前的时序监控标准。为什么选择拉的形式？这里是官方的解释（）。

　　以上从监控端的角度简单介绍了数据采集的拉取和推送形式。从被监控端来看，获取数据的方式有很多种，通常可以分为以下几种：

　　默认采集探头采集组件采集埋点采集

　　下面是一个例子。

　　

　　默认的采集通常是通俗意义上大家需要观察的基本指标，往往和业务没有强关联，比如cpu、内存、磁盘、net等硬件或系统指标。通常监控系统会有专门的agent来修复采集这些指标，使用云原生的node_exporter、CAdvisor、process-exporter分别对节点机器、容器、进程进行基本的监控非常方便。

　　

　　探测采集主要是指从外部采集获取数据的手段。比如域名监控、站点监控、端口监控等都属于这一类。采集 的方法不会侵入系统。由于其对网络的依赖性强，通常会部署多个检测点，以减少网络问题导致的误报。但是，有必要非常小心。一定要评估检测采集@采集的频率，否则容易对被检测方造成请求压力。

　　

　　通常是指已有的采集方案，详细的指标采集可以通过简单的操作或者配置进行，比如mysql监控、redis监控等。在云原生环境下，这个采集 方法比较常见。得益于prometheus的发展壮大，通用组件采集exporters层出不穷，各种exporter都通过prometheus官方认证。对于以下特殊或定制的需求，您也可以根据/metrics接口标准完成自定义导出器的编写。

　　

　　对于一个系统的关键指标，研发学生自己是最有发言权的，通过埋点可以准确得到相关指标。在prometheus系统中，使用/prometheus/client_*工具包实现埋点采集非常方便。

　　

　　本文从“采集结构”和“采集方法”两个方面对监控系统第一阶段“采集”进行了简要介绍和梳理。与以往相比，在云原生环境下，服务粒度更细化，迭代效率更高。从开发到上线形成了一个更快节奏的反馈回路，这也要求监控系统能够更快地反映。系统异常，虽然“采集结构”和“采集方法”不是监控系统的核心部分，但简洁的采集结构和方便的采集方法也在后续“可观察性”的实现提供了基础。目前，在云原生环境中，