Prometheus第一篇：Prometheus架构解析

Prometheus是新一代的监控系统解决方案，原生支持云环境，和kubernetes无缝对接，的却是容器化监控解决方案的不二之选。当然对传统的监控方案也能够兼容，通过自定义或是用开源社区提供的各种exporter无疑又为prometheus丰满羽翼。那么从今天开始我将会持续更新我对prometheus使用过程中的了解和踩坑记录，一是为了沉淀自己，二是为同学们提供个思路。

1、架构介绍

上图就是prometheus的一个整体的架构图，这篇文章就围绕这张图展开，介绍prometheus的工作机制和各组件提供的功能。

1.1 Prometheus server组件介绍

a. Prometheus server:
它是prometheus的主程序，本身也是一个时序数据库，它来负责整个监控集群的数据拉取、处理、计算和存储。和zabbix采取push监控数据的方式不同，
1、prometheus的设计是使用pull方式由服务端主动拉取监控数据。关于push和pull两种方式的优缺点争论一直存在，这里不再过多赘述，只需知道即可。
当prometheus拉取到数据之后首先进行的操作是数据的处理：根据配置的数据格式或者标签转换/删除等操作。
2、数据处理完成后是根据rule中配置的规则进行计算：比如CPU使用率达到80%是一条告警规则，则prometheus会对数据进行计算看是否命中规则，命中则发送消息给alertmanager组件，否则不做操作。
3、完成上面的一些操作之后，prometheus会根据配置时间周期保存数据到本地或者是第三方存储中
以上便是prometheus server做的比较重要的事情(大致流程是这样，细节方面未做探讨。)

1.2 Alertmanager 组件介绍

b. Alertmanager:
它是prometheus的告警组件，负责整个集群的告警发送、分组、调度、警告抑制等功能。
需要知道的是alertmanager本身是不做告警规则计算的，简单来说就是，alertmanager不去计算当前的监控取值是否达到我设定的阈值，上面已经提过该部分规则计算是prometheus server来计算的，alertmanager监听prometheus server发来的消息，然后在结合自己的配置，比如等待周期，重复发送告警时间，路由匹配等配置项，然后把接收到的消息发送到指定的接收者。同时他还支持多种告警接收方式，常见的如邮件、企业微信、钉钉等。

1.3 Pushgateway 组件介绍

c. Pushgateway
它是prometheus的一个中间网管组件，类似于zabbix的zabbix-proxy。它主要解决的问题是一些不支持pull方式获取数据的场景，比如：自定义shell脚本来监控服务的健康状态，这个就没办法直接让prometheus来拉数据，这时就可以借助pushgateway，它是支持推送数据的，我们可以把对应的数据按照prometheus的格式推送到pushgateway，然后配置prometheus server拉取pushgateway即可。

1.4 数据展示组件介绍

上图右下角的几个组件,grafana、prometheus-ui是用来图形化展示数据的组件，其中prometheus-ui是prometheus项目原生的ui界面，但是在数据展示方面不太好用，因此推荐grafana来展示你的数据，grafana支持prometheus的PromQL语法，能够和prometheus数据库交互，加上grafana强大的ui功能，我们可以很轻松的获取到很多好看的界面，同时也有很多做好的模版可以使用。

1.5 服务发现组件介绍

对一个监控系统来说，自动发现肯定是一个最基础的功能，试想如果没有自动发现，添加10000台主机到监控系统该是中什么体验？还好，prometheus是有该组件的，而且还很多，支持多种自动发现机制，比如基于文件、DNS、consul、zookeeper、etcd、kuberbetes等服务自动发现的方式,这些服务发现方式后面都会写到。

本篇写到这里就要结束了，主要是简要介绍了下prometheus中各组件的大致功能，对prometheus又一个大致的了解。下一篇会写几种prometheus的安装方式。