Prometheus快速入门
一、什么是Prometheus
Prometheus是一套开源的系统监控报警框架。
二、优点
基于time series时间序列模型
基于K/V的数据模型，时间序列数据通过metric名和键值对来区分
数据格式 简单 速度快 易维护开发
采样数据的查询 完全基于数学运算 而不是其他的表达式 并提供专有的查询输入console，这个特点很独特，所有的查询基于数学运算公式 例如：（增量(A)+增量(B))/总增量(C)>固定百分比
采用HTTP pull/push两种对应的数据采集传输方式 方便
开源，且大量的社区成品插件（如果公司对监控要求不是特别高的话，默认的介个成品插件，装上就可以用到底，监控成型速度很快）
本身自带图形调试，虽然最终肯定不能跟grafana的效果相比，但是这种自带图形的成图 可以大大帮助运维调试
最精细的数据采样。Prometheus理论上可以达到每秒采集！！！而且可以自行定制频率（不过强大的同时，本人不建议细到这个程度，因为数据量太大，1s采样一次的话就）
三、不足
不支持集群化（这是当前迫切需要的）
被监控集群过大后，本身性能有一定瓶颈（如果有集群 就可以解决这个问题）
中文支持不好（往往新的很牛的国外工具，都不支持中文）
四、适用场景
适用于记录文本格式的时间序列，
适用于以机器为中心的监控
适用于高度动态的面向服务架构的监控
在微服务世界中，对多维数据收集和查询的支持有特殊优势
Prometheus 是专为提高系统可靠性而设计的，它可以在断电期间快速诊断问题，每个 Prometheus Server 都是相互独立的，不依赖于网络存储或其他远程服务。当基础架构出现故障时，你可以通过 Prometheus 快速定位故障点，而且不会消耗大量的基础架构资源。
五、不适合什么场景
Prometheus 非常重视可靠性，即使在出现故障的情况下，你也可以随时查看有关系统的可用统计信息。如果你需要百分之百的准确度，例如按请求数量计费，那么 Prometheus 不太适合你，因为它收集的数据可能不够详细完整。这种情况下，你最好使用其他系统来收集和分析数据以进行计费，并使用 Prometheus 来监控系统的其余部分。
六、Prometheus框架结构
6.1 Prometheus的服务器，也是核心
prometheus本身是一个以进程方式启动，之后以多进程和多线程实现监控数据收集、计算、查询。更新、存储的这样一个C/S模型运行模式。
解压缩之后：./prometheus即可，默认监听9090端口用来访问
6.2 Prometheus存储形式
prometheus采用的是time-series(时间序列)的方式，以一种自定义的格式存储在本地硬盘上
prometheus的本地T-S（time-series）数据库以每两个小时为间隔来分block块存储，每一个块中又分为多个chunk文件，chunk文件是用来存放采集过来的数据的T-S数据，metadata和索引文件（index）
index文件是对metrics（prometheus中的一次KV采集数据叫做一个metric）和lables（标签）进行索引之后存储在chunk中，chunk是作为存储的基本单位，index and metadata是作为子集
prometheus平时是将采集过来的数据先都存放在内存之中（prometheus堆内存的消耗 还是不小的）以类似缓存的方式用于加快搜索和访问
当出现宕机时，prometheus有一种保护机制叫做WAL，可以将数据定期存入硬盘中以chunk来标识，并在重新启动时用以回复进入内存
6.3 prometheus服务发现功能
prometheus本身跟其他的开源软件类似，也是通过定义配置文件来给prometheus本身规定需要被监控的项目和被监控节点。
如果prometheus配合例如consul这种服务发现软件
prometheus的配置文件就不再需要人工去手工定义出来，而是能自定发现集群中有那些新机器以及新机器上出现了那些新服务 可以被监控
6.4 采集客户端
主要两种方式采集：
a. pull主动拉取的形式
指的是客户端（被监控机器）先安装各类已有exporters（监控客户端插件）在系统上之后，exporters以守护进程的模式运行并开始采集数据
exporter本身也是一个http_server可以对http请求做出响应返回数据（K/V metrics)
prometheus用pull这种主动拉的方式（Http get）去访问每个节点上exporter并采样回需要的数据
b. push被动推送的形式
指的是在客户端（或者服务端）安装这个官方提供的pushgateway插件，然后，使用我们运维自行开发的各种脚本把监控数据组织成K/v的形式metrics形式发送给pushgatewawy之后pushgateway会再推送给prometheus
这种是一种被动的数据采集模式
6.5 报警部分
七、prometheus监控数据格式
7.1 prometheus metrics的概念
metrics是一种对采样数据的总称（metrics并不代表某一种具体的数据格式，是一种对于度量计算单位的抽象）
metrics的几种主要的类型：
Gauges
最简单的度量指标，只有一个简单的返回值，或者叫瞬时状态。例如：cpu某个时间的使用率
Counters类型metrics
Counter就是计数器，从数据量0开始计算在理想状态下，只能是永远的增长不会降低（一些特殊情况另说）、例如：对用户的访问量的采样数据，是一个积累的数据不断的累加
Histograms
统计数据分布情况，比如最小值，中间值，中位数，百分数等的值。
是一种特殊的metrics数据类型，代表的是一种近似的百分比估算数值
7.2 K/V的数据格式
prometheus的数据类型就是依赖于这种metrics的类型来计算的，而对于采集回来的数据类型，要以一种具体的数据格式供我们查看和使用以及保存就是k/v形式。
八、监控实例
实例：cpu使用率
实际上cpu是多核的，在运维实际监控中不关注每个核的状态，是关注整体的状态。
(1-((sum(increase(node_cpu{mode=“idel”}[1m])) by (instance)) / (sum(increase(node_cpu[1m])) by (instance)))) * 100
其实就是
九、prometheus计算函数
increase()
用来针对Counter这种持续增长的数值，截取其中一段时间的增量
increase(node_cpu[1m]) =>> 这样就获取了cpu总使用时间在1分钟内的增量
sum()
把所有数值加到一块，默认情况下，是把所有数据 不管什么内容 全部进行加合了，例如sum(node_cpu) 不光把每台机器的多少个核加在一起了，还把所有的机器cpu全加到一起了。变成服务器集群总cpu平均值了
sum (increase(node_cpu[1m])) =>> 表示把所有核数值加和
sum(node_cpu[1m])
by()
按照指定的方式进行一层的拆分，by(instance) instance代表的是机器名
rate()
rate(http_requests_total{job=“api-server”}[5m])
专门搭配counter类型数据使用的函数
功能：按照设置的时间段，取counter在这个时间段中的平均每秒的增量
例子：rate(node_network_receive_bytes_total[1m] )
node_network_receive_bytes_total本身是一个counter类型，表示网络接收字节数。
被tate(. [1m])包上之后，就可以获取到在1分钟内，平均每秒钟的增量。
注意：以后在使用任何counter数据类型的时候，永远记得别的先不做，先给它加上一个rate()或者increase()，取单位时间内的增量。
increase()和rate()区别：
rate（）是取一段时间增量的平均每秒数量
increase()是取一段时间增量的总量
比如：increase(node_network_receive_bytes[1m])取得是1分钟内的增量总量。rate(node_network_receive_bytes[1m])取得是1分钟的增量除以60秒 每秒的数量
监控第一步，获取采集数据源，采样频率
采样频率比较粗糙时候例如5m采集一次，使用rate形成的图形就会有断链的情况，相较于increase就可以，用于采集频率粗糙的情况下
rate适用于采集比较频繁的时候
rate->cpu，IO，网络流量
topk()
Gauge类型的使用
topk(3,count_netstat_wait_connections)
Counter类型的使用
topk(3,rate(node_network_receive_bytes[20m]))
根据给定的数字，取数值最高>=x的数值
注意：一般使用时，只适合于在console查看，graph的意义不大。因为对于每一个时间点，都只取前三高的数值，那么必然会造成单个机器的采集数据不连贯，实际使用时候一般用topk()进行瞬时报警，而不是为了观察曲线图。
count()
定义：把数值符合条件的 输出数目进行加合
一般用它进行一些模糊的监控判断，比如：企业中100台服务器，那么当只有10台服务器cpu高于80%的时候这个时候不需要报警，但是当符合80%CPU的服务器数量超过30台的时候那么就会触发报警。
