我们知道zabbix在监控界占有不可撼动的地位，功能强大。但是对容器监控显得力不从心。为解决监控容器的问题，引入了prometheus技术。prometheus号称是下一代监控。接下来的文章打算围绕prometheus做一个系列的介绍，顺便帮自己理清知识点。

---

一、简介

　　prometheus是由谷歌研发的一款开源的监控软件，目前已经被云计算本地基金会托管，是继k8s托管的第二个项目。

二、优势

　　易于管理

　　轻易获取服务内部状态

　　高效灵活的查询语句

　　支持本地和远程存储

　　采用http协议，默认pull模式拉取数据，也可以通过中间网关push数据

　　支持自动发现

　　可扩展

　　易集成

三、prometheus运行流程

prometheus根据配置定时去拉取各个节点的数据，默认使用的拉取方式是pull，也可以使用pushgateway提供的push方式获取各个监控节点的数据。将获取到的数据存入TSDB，一款时序型数据库。此时prometheus已经获取到了监控数据，可以使用内置的PromQL进行查询。它的报警功能使用Alertmanager提供，Alertmanager是prometheus的告警管理和发送报警的一个组件。prometheus原生的图标功能过于简单，可将prometheus数据接入grafana，由grafana进行统一管理。

四、监控的目的

　　google指出，监控分为白盒监控和黑盒监控之分。

　　白盒监控：通过监控内部的运行状态及指标判断可能会发生的问题，从而做出预判或对其进行优化。

　　黑盒监控：监控系统或服务，在发生异常时做出相应措施。

　　监控的目的如下：

　　　　1、根据历史监控数据，对为了做出预测

　　　　2、发生异常时，即使报警，或做出相应措施

　　　　3、根据监控报警及时定位问题根源

　　　　4、通过可视化图表展示，便于直观获取信息

五、常用概念

　　prometheus采集到的监控数据均以metric（指标）形式保存在时序数据库中（TSDB）

　　每一条时间序列由 metric 和 labels 组成，每条时间序列按照时间的先后顺序存储它的样本值。

　　默认情况下各监控client向外暴露一个HTTP服务，prometheus会通过pull方式获取client的数据，数据格式如下：

1 2 3 4 5 6

#  HELP node_cpu Seconds the cpus spent in each mode. #  TYPE node_cpu counter node_cpu{cpu="cpu0",mode="idle"}    362812.7890625 #  HELP node_load1 1m   load    average. #  TYPE node_load1 gauge node_load1 3.0703125

　　以#开头的表示注释信息，解释了每一个指标的监控目的和类型

　　node_cpu表示监控指标的名称

　　{}内的内容是标签，以键值对的方式记录 

　　数字是这个指标监控的数据

　　下图横坐标代表的是时间（时间戳的方式记录在TSDB中），纵坐标代表了各种不同的指标名称，坐标系中的黑点代表了各个指标在不同时间下的值。

　　每一个横线 就是时间序列

　　每个黑点就是样本（prometheus将样本以时间序列的方式保存在内存中，然后定时保存到硬盘上）

　

 　　指标（metric）的格式如下：

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

　　指标名称反映的是监控了什么。

　　标签反映的是样本的维度，可以理解成指标的细化。比如：

1	api_http_requests_total{method="POST",  handler="/messages"}

　　指标是“api_http_requests_total”，含义是通过api请求的http总数。

　　标签“method="POST"” "handler="/messages""代表了这些http请求中 POST 请求 并且 handler是/messages的数量

　　上述指标等同于：

1	{__name__="api_http_requests_total"，method="POST",  handler="/messages"}

　　

　　指标有四种类型

　　1、Counter　　只增不减  计数器

　　2、Gauge　　可增可减    仪表盘

　　3、Histogram　　直方图

　　4、Summary　　摘要型