开发者学堂课程【3天吃透 Prometheus：Prometheus 基础应用】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18445
Prometheus 基础应用
内容介绍:
一、 Prometheus 的介绍
二、 Prometheus 的部署
一、 Prometheus 的介绍
Prometheus 是其位于监控系统生态的中心，但其需要很多组件协同工作以实现更好的功能。
下面以一种轻松的方式回顾 Prometheus 监控系统的基础工作逻辑及其他用到的核心概念，之后部署和使用Prometheus 。
Prometheus 是如何进行工作的?
1. 时序数据
首先是时序数据。时序数据是在一段时间内通过重复测量而获得的观测值的集合，这些集合能够根据固定时间周期串联起来，对于同一指标而言称为时序数据，因此将这些观测值绘制于图形之上，他会有一个数据轴和一个时间轴。
下图为黄石公园2014-1至2016-7每个月的游客的统计数，横向为时间轴，纵轴为数据。需要说明的是采样的样本数并不是连续的，只是绘图时连在了一起，他们是各个点的连线。天气数据、经济指标数据、人体的健康指标数据等都是时序数据。
对于监控系统，服务器的指标数据、应用程序性能监控数据、网络数据、每一时刻的通信量也属于时序数据，因此 Prometheus 抓的数据属于时序数据。
2. Prometheus 是如何抓数据的
在整个监控生态圈中，Prometheus Server 是核心，它有四个组件，分别是数据采集器scrap、TSDB、Promo QL、Service Discovery，其中数据采集器是基于HTTP协议实现的，即每个待被抓取的指标暴露的服务必须为HTTP 协议，HTTS 也可以要确认对方是做单向还是双向认证，如果是单向认证需要配置对方的 CA，如果是双向需要配置客户端证书才能抓取数据。
在 Prometheus 语境中，所有的数据抓取都是以Pull 的方式进行的，且每一个能生成指标数据的被采集端在Prometheus 语境中称为一个 Target （一个网络端点），每一个待被抓取的 Target 末端上都可能有不止一个被抓取的指标，例如一个主机是一个 Target，那么它含有 CPU 指标、内存指标、磁盘指标等。每个指标每次抓取都会得到一个数据称为样本值或样本数据。
显然，对应的 Target 有很多个，因此 metrics 指标会更多，而抓取操作是基于 HTTP call 实现的，所以暴露指标的一端一定是基于HTTP 形式提供，Prometheus Server 目前不支持，这也是为什么它不能抓取内核数据的原因，因为内核数据没有自带服务器，必须部署一个 Exporters。
Prometheus 支持通过三种类型的途径从目标上抓取数据。目标必须暴露一个 HTTP 服务，但并非所有被监控对象都有 all，因此有三种途径暴露其指标。
（1）第一是内件不支持的 Exporters，无法进行指标暴露，或可以暴露但不是 HTTP 服务格式，可以在前面部署一个 HTTP 服务格式的指标暴露器，由它负责兼容、对应被监控的 Target 指标数据并转为 Prometheus 的格式，且要通过HTTP 服务提供给 Prometheus。
（2）第二是 Instrumentation，这是应用程序内件的测量系统，通过内件程序输出只能通过 HTTP 协议，内件必须有 Web 服务，大部分应用程序都是通过 HTTP/HTTS 服务协议工作。
（3）第三是 Pushgateway，已介绍，便不再赘述。
3. “拉取”与“推送”
无论是哪种方式，斯沃端一定是 pulls metrics。Prometheus 只能工作于 Pull模式，其优势在于便于集中控制，只需将配置集中在 Prometheus Server 上完成，包括指标及采集速率等；Prometheus 根本目标在于收集在 Target 上预先完成聚合的聚合型数据，避免在 Prometheus 上做复杂的聚合计算，Prometheus 服务端有很高的技术参数，需要二次、跨指标聚合，单指标聚合在 Target 上即可完成。
4. Prometheus 的生态组件
下图为 Prometheus 的生态组件及其功能。
Prometheus生态圈中包含了多个组件，其中部分组件可选
（1）Prometheus Server：收集和存储时间序列数据；
（2）ClientLibrary：客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径；
（3）Push Gateway：接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作；
（4）Exporters：用于暴露现有应用程序或服务（不支持Instrumentation）的指标给Prometheus Server；
（5）Alertmanager：从Prometheus Server接收到"告警通知"后，通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送；
（6）Data Visualization：Prometheus Web UI （Prometheus Server内建），及Grafana等；
（7）Service Discovery：动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用；该组件目前由Prometheus Server内建支持；
5. Prometheus 的数据模型
下面介绍 Prometheus 的数据模型。对 Prometheus 而言，需要到每个 Target 上抓取不止一个时序数据，每一个时间序列对 CPU 这一个设备来说只有一个指标维度。
比如定义一个名为 cpu-usage 的指标，对于 cpu 的使用率有多个维度，比如内核空间使用率、用户空间使用率、因为中断占去的使用率等，因此 cpu-usage 是一个统称指标，需要在其背后附加许多标签以代表不同指标序列。这是一个指标，而在一个指标下会生成 n 个时间序列，这是一个值得注意的地方。
每个指标都是一个数据库，数据库中有多张表，表中的字段靠标签定义，即一个指标加一个标签代表了一张单字段的表。对应的cpu-usage 代表一个指标时序，代表一个时序时首先要说明代表哪一个指标；其次对于这个指标时序而言内部最关键的是有标签及其值组成的代表着系统维度的属性值，这些属性及其值即为标签，整个组合起来称为时序，如下图最大红色矩形圈起来的部分。
因此但将维度去掉之后，一个指标可能有多个时序，每一个核心 core 都有各自的样本数据。同一指标可能会适配到多个目标或1设备，因此其使用标签作为元数据，从而为Metric添加更多的信息描述纬度。
在未来查询时，一样采取这种方式：使用指标名和需要查询的纬度。一个指标名称加上完整的标签代表一个时序，但要看核心一的指标使用率时需要把核心一过滤出来。但要定义过滤表达式时，使用指标名和标签，但此时标签要和所有指标标记名做比较操作的。
下图中 ~ 符号代表正则表达式方向匹配，不匹配为真，匹配为假，即要过滤出所有核心不是2的其他数据核心相关序列，对应的指标序列不止一个。因此下面这钟形式可以既代表一个时序，又可作为时序选择器，使用标签值进行选择。在Prometheus 内部每一次样本都是将序列名称标识和时序值同时存放，每一数据都有对应的时序，蓝色部分为样本值，其余部分为时序标识。要过滤存下来的样本中的其中一部分，需要使用到过滤表达式定义。
6. 指标类型
在 Prometheus 中，存储指标数据时也有指标类型。数据时展成为双精度浮点存放，而指标数据是指双精度浮点数据是以怎样的方式存放的。
（1）第一种是计数器，在时序上未重置时是单调递增的，例如站点的访问次数不能为负值，且不能减少，但可以重置为0，重置通常是由于服务器故障或重启导致的；
（2）第二种是仪表盘，可以理解为是一个可增可减的数据，例如内存的空闲空间，它是一个上下互动的数据。第三种和第四种是摘要和直方图，主要是做分位数统计。直方图是指在一段时间范围内对数据进行采样，并将其计入可配置的存储桶中；
（3）直方图能存储更多信息，包括样本值分布在每个存储桶中的数量、所有样本值之和以及总的样本数量，从而 Prometheus 能够使用内置的函数计算样本平均值和分位数，分段统计求平均，避免纯粹平均值的坏处。
（4）摘要和直方图的区别在于直方图的分位数是后期计算的，而摘要是直接存下来的，不需要二次计算。
7. 作业和实例
在 Prometheus 上进行监控，每一个能生成指标的 Exporter 或Instrumentation 都可以被独立识别为一个的数据采集目标。例如有一个 lingus 系统，不能基于 HTTP 协议输出指标，需要部署一个Exporter，Prometheus 需要基于监听的端口抓取数据，这种能够基于数据和端口暴露数据的采集点即为一个 target ，显然在系统范围内的100个主机都是主机型的采集点，可以将同类型的采集点归类起来进行统一管理，这些能暴露同类型指标的所有采集点的集合在prob 内部称为一个 job。再举一个例子，现在监控一个 Metric，其中有11个采集点的主从复制集群，每个采集点都会暴露一个指标，所以说每一个采集点都叫做一个 target，但是这11个 target 跟节点 target 的采用指标数不一样，它们的内存类别不一样，所以它们定义成一种类别，也称作一个 job。综上所述，能向外暴露指标的就叫做 traget。
8、PromQL
PromQL,Prometheus 提供了内置的数据查询语言PromQL（全称为Prometheus Query Language）,支持用户进行实时的数据查询及聚合操作。Prometheus 会周期性采集数据，每一个数据都是 KV 型数据，其中K为所处时间序列的标识，V为样本值。
希望得到某一特定时序样本值时需要基于 key 做构率，整个 key 是由指标名称和标签组成的，因此可以针对指标名称做构率，也可以针对标签做构率，此时 PromQL 是针对这些 key 所描述出来的查询表达条件，对应的数据在其内部查询出来的结果肯可能会有多种数据类型，包括标量、向量。在 PromQL 中支持处理两种向量，一种是即时向量，它是指最近一次时间戳上跟踪的数据指标，当然也可以使用时间偏移的方式指定过去某时刻的数据，此时称为瞬时向量，统一称为即时向量，即时向量时间未必对齐，前后会交错几毫秒或几微秒，原因是在 Prometheus 中采集一万个指标时压力较大，会分散开进行采集，但时间范围是相同的。第二是范围向量，它是指查询一段时间范围内的数据，也可能是多个时序同一段时间上的数据，因为每个时序上有多个样本值，因此最后会组成一个行列式。
9、Alerts
下面讲解 Alerts。对 Prometheus 而言，告警分为两部分。第一Prometheus 可触发告警操作，将触发的告警交给 Alert Manager由 Alert Manager 真正执行此告警。
监控系统自身需纳入监控中，且要对监控和告诫系统等每一个重要组件进行冗余。故障管理是核心职能，但应避免故障时间过长，应尽量减少故障，所以应确保采集和告警之间周期有合理的取值。告警是由 Alert Manager 完成的，在告警时将不同的故障传给对应的接收人，Alerts 可将像消息中间键的故障传给消息中间键的运营团队 对于存储故障告警给存储团队，对于告警需路由。
