Prometheus 监控入门了解的基础常识知识（运维自学入手）

1、Prometheus 基础

一、定义

• prometheus 是一个开源系统监控和报警的工具集合，由 SoundCloud创建(http://soundcloud.com)。
• 独立运行的 开源的 由各公司自行维护的监控项目。拥有大量的积极参与开发建设的 研发人员以及社区用户。
• 为了让项目更充实更清晰 2016 年 prometheus 加入了 Clound Native Computing Fondation(CNCF) 组织。

二、Prometheus 特性

• 基于 time series 时间序列模型

  • 时间序列（time series X,Y）是一系列有序的数据，通常是时间间隔的采样数据。

• 基于 K/V 的数据模型

  • Key/Value 键值存储，例如：{ disk_size : 80 }。数据格式简单，速度快，易于维护

• 采样数据的查询，完全基于数学运算，并提供专有的查询输入 console

  • 所有的查询都基于数学运算公式，例如：（增量A + 增量B / 总增量C > 固定百分比 => ?）

• 采用 HTTP pull/push 两种对应的数据采集传输方式

  • 所有的数据采集 都基于采用HTTP，而且分为 pull push 推、拉两种方式去写采集程序，方便

• 开源，且大量的社区成品插件

  • 很多 prometheus 社区开发的差距已经异常强大和完善，如果公司对监控要求不是特别高，装上几个成品插件就可以用到底了，监控成型速度很快。

• 本身自带图形调试

  • prometheus 本身就自带了 形成的图形成型界面
  • 虽然最终肯定不能与 Grafana 的效果相比，但是这种自带图形可以帮助运维人员做调试工作

• 最精细的数据采样

  • 大多数市面上的开源监控，采样至多精确到半分钟、一分钟的程序
  • Prometheus 理论上可以达到 秒级别 采样。而且可以自行定义频率（但是不建议使用）

三、prometheus 缺点

• 不支持集群化（最迫切的需求）
• 被监控集群过大后，本身性能有一定的瓶颈（如果有集群，则可以解决问题）
• 中文支持不够友好，资料不全

四、prometheus 对于运维的要求

要求对操作系统有深入扎实的了解
对数学思维有一定的要求，因为基本的内核就是数学公式
对监控的经验有很高要求，监控项需要很细的定制

学监控如果你是为了涨钱，面试要工资，那么我建议你别学了，因为这不是一个看文档就会的东西。
学监控是为了帮助你工作，帮助公司/客户以最低延迟，最高效率发现问题，解决问题。
学监控是为了让你在运维道路上变得更加出色，有用，不至于每天往座位上倚靠，混吃等死。

2.Prometheus 框架

组件

Prometheus生态系统包含多个组件，其中许多是可选的，以下是最重要的：

• Server：负责定时在目标上抓取 Metrics(指标)数据。
• Target：暴露一个HTTP服务接口用户Server抓取数据。
• Exporter：客户端向服务端推送 Metrics 数据，并以 key/value 格式呈现。
• Pushgateway：服务端自定义抓取数据的脚本，放在被监控的主机，由pushgateway进行推送。
• AlertManager ：接收server推送的告警信息，并触发告警。
• Grafana：监控数据展示。

架构图

一、Pushgateway

prometheus 服务端与客户端之间数据采集有两种方式

• pull：主动拉取
• push：被动推送

pull - exporter 拉取

​指的是客户端先安装各类已有 exporters
开发的监控客户端插件在系统上之后，exporters 以守护进程的模式运行，并开始采集数据。 默认工作端口号：9100
exporter 本身也是一个 http_server,可以对 http请求做出响应，返回数据。

prometheus 用 pull 这种主动拉取的方式 (HTTP GET) 去访问每个节点上 exporter 并采样回需要的数据

push - Pushgateway 推送

指的是 在客户端 ( 或者服务器 ) 安装 Pushgateway 插件

然后使用我们运维自行开发的各种脚本，把监控数据组织成 key/value 的形式，或者 metrics 形式发送给 Pushgateway，之后由 Pushgateway 再推送给 prometheus

二、Altermanager

当监控数据达到一个阈值，prometheus 会把报警信息推送到 Altermanager 软件上，Altermanager 再次推送到报警平台。

但是 Altermanager 的报警功能有很多不足，可以采用 Grafana 4.0 以后提供的报警功能来替代 Altermanager。

三、Metrics

prometheus 监控中 对于采集过来的数据，统一称为 metrics 数据。

Metrics：当我们需要为某个系统某个服务做监控、统计、就要用到 Metrics，Metrics 是一种对采样数据的总称 （ metrics 并不代表某一种具体的数据格式，而是一种对于度量计算单位的抽象）

Metrics 监控指标

<metric name>{<label name>=<label value> , ...},

• 指标名称（metric name）：用于说明指标的含义，指标名称必须有 字母 数字 下划线 冒号 组成。符合正则表达式[a-zA-Z][a-zA-Z0-9]

• 标签（label）：体现指标的维度特性，用于过滤和聚合。通过标签名和标签值组成，键值对形式形成多种维度。

• 键值（value）：标签的具体键值。

实例：以下两个指标是一样的，下划线开头的标签是系统内部使用的。

指标1 http_request_total{status="200",method="POST"}
指标2 {\__name__="http_request_total",status="200",methos="POST"}

HTTP请求状态的总和{ status 值 200，代表状态为 200 }

四、Metrics 的几种主要的类型：

Ⅰ、Gauges

​ 最简单的度量指标，只有一个简单的返回值，或者叫瞬时状态。例如，衡量一个待处理队列中任务的个数。

例如：如果要监控硬盘容量或者内存的使用量，那么就应该使用 Gauges 的 Metrics 格式来度量。

​ 因为 硬盘的容量 或者 内存的使用量 是随着时间的推移，不断地瞬时变化
​ 这种变化没有规律，当前是多少采集回来就是多少。既不能肯定是一直增长，也不能肯定是一直降低。

这种没有固定规律，数值是多少就是多少，为 Gauges 适用类型的代表。

如图所示：CPU 的上下浮动就是采集使用 Gauges 形式的 Metrics 数据，没有规则，得到多少为多少，然后显示。

Ⅱ、Counters

Counter 代表计数器，从数据量 0 开始累计计算，在理想状态下只能是永远的增长，不会降低

Counter => 数字++ 特例：2:00 将数据清零，那么会下跌

例如：对用户访问量的采样数据

​ 我们的产品被用户访问一次就是1，过了10分钟后，累计到100
​ 过了一天之后，累计到 20000 , 一周之后积累到 100000~1500000


如下图所示：Counter 数据是从 0 开始，一直不断的积累，累加下去的，所以理想状态下不可能出现任何降低的状况，最多只可能是一直保持不变。（当用户不在访问，当前累计访问数会以一条水平线状态保持）

Ⅲ、Histograms

Histogram 统计数据的分布情况。比如最小值，最大值，中间值，中位数。75%，90%，92%，99.9% ，百分位值。特殊的 Metrics 数据类型，比例型数据，百分比估算数值。

企业工作中 需要经常接触这种数据。

​ Http_response_time HTTP响应时间

​ 代表的是一次用户 Http请求 在系统传输和执行过程中，总共花费的时间。Nginx 中也会记录这一项数值，在日志当中。

问题：

问题2：

为了解决以上两个问题，可以采用 Histogram 的 Metrics

通过 Histogram 算法的函数，可以直接使用并 分别统计 出全部用户的响应式中：
~=0.05秒的有多少，~=0.5秒的有多少 >2秒的有多少 >10秒的有多少

我们可以很清晰的看到，当我们的系统中处于基本正常状态的有多少百分比的用户 ( 或者是请求)，多少处于极快速度的用户，多少处于慢请求 或者有问题的请求。

一般最常用的，最主要的就是 Counter(计数器) Gauge(基本度量) Histogram(百分比分布)

五、Key / Value 的数据形式

Metrics 是数据逻辑的概念，包含多种数据类型

Key / Value 是数据具体的格式，供用户使用查看

第一个代表的是 当前采集的 最大文件句柄 65535
第二个代表的是 当前采集的 被打开的文件句柄 10

如图所示：一个 exporter 给我们采集来的服务器上 key/value 形式的 Metrics 数据

​ 当一个 node_exporter 被安装和运行在被监控的服务器上后
​ 使用简单的 curl命令 就可以看到 exporter 帮我们采集到的 metrics 数据的样子，以 key/value 形式展现和保存。curl localhost:9100/metrics9100 exporter 默认端口号

六、exporter 的使用

官网提供了丰富的 成型的 exporter 插件，官网地址：https://prometheus.io/docs/instrumenting/exporters/

最常用 node_exporter 所有 Linux 系统中和系统自身相关的监控数据全部都可以抓取出来。

点击这个官网，里面有全网所有的 exporter 的插件的使用方法。

七、Pushgateway 对比 exporter

1. exporter 虽然采集类型已经很丰富了，但是我们依然需要很多自制的监控数据，非规则化的自定制的。
2. exporter 由于数据类型采集量大，其实大部分数据在监控中是用不到的，而pushgateway是定义一项数据，就只采集这一种资源。
3. 一个新的自定义的 pushgateway 脚本开发，比去开发一个全新的 exporter 简单快速的多。
4. exporter 虽然已经很丰富了，但是依然有很多的采集形式exporter无法提供。但是 pushgateway
   相比较更加灵活，想做什么都可以做到，简单、效率高。