目录
引言
Prometheus是一个开源的系统监控和报警系统，现在已经加入到CNCF基金会，成为继k8s之后第二个在CNCF托管的项目，在kubernetes容器管理系统中，通常会搭配prometheus进行监控，同时也支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。
一．prometheus结构图（可分三层）
（1）提取采集（三种）
- pushgatway
它的存在允许短暂和批量作业将其指标暴露给 Prometheus。由于这些工作的生命周期可能不足够长，不能够存在足够的时间以让 Prometheus 抓取它们的指标。Pushgateway 允许它们可以将其指标推送到 Pushgateway，然后 Pushgateway 再将这些指标暴露给 Prometheus 抓取。
pushgateway实际上式短周期，元数据http/https方式输出的数据，一次性任务的模块
- instrumention
测量系统,指应用系统内置的，本身就兼容Prometheus 格式的置标数据，内建了Prometheus 格式兼容的指标暴露器。
例如：nginx的vts监控模块
- exporter
内键暴露器，将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可以获取到需要采集的监控数据
（2）数据提取，存储
1.默认存储在自身的tsdb中，即本地存储
2.也可以存储在分布式存储中
3.或者其他的TSDB中例如：inflxDB，OPENTSDB
展示：
1.默认使用表达式浏览器（ui）来展示数据
2.可以借用其他的展示工具/服务/插件来帮助实现可视化，例如kibana，grafana告警平台（集成）
pro-server SD (server discover)自动发现，被监控端
1.静态层面 static-config（配置什么就监控什么）
2.基于文件形式（fd-config file discover）定义如何输出，通过代码形式来定义将数据放在哪个文件中
3.注册中心，例如consul nacos
4.基于k8s方式的自动发现，通过宇api-server继承，采集metrice-server和cadvisor来自动发现pod状态
（3）告警模块
1.pro-server产生告警逻辑
2.通过布尔值表达式产生告警逻辑，定义告警阈值
3.altermanager/garfana告警通知
4.通过路由分组+告警通知功能，实现触发式的监控告警给receivers（接受“人”）
二．pull和push
1.首先普罗米修斯式使用pull来主动拉取数据的，Prometheus同其他时序数据库相比有一个非常典型的特性：它是主动从各TARGET（客户端）上拉取（pull）数据，而非等待监控端的推送（push）
2.pull的优势在于，集中控制有利于配置集在Prometheus server上完成，包括指标和采集的速率。
3.Prometheus的目标是收集在TARGET上预先完成聚合的聚合性数据，而非事件性驱动的存储系统。
三．prometheus的生态组件
1. Prometheus Server
Prometheus组件中的核心部分，收集和存储时间序列数据，提供PromQL查询语言的支持。内置的 Express Browser UI，通过这个 UI 可以直接通过 PromQL 实现数据的查询以及可视化。
2.Exporters
将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可以获取到需要采集的监控数据
3.PushGateway
主要是实现接收由 Client push 过来的指标数据，在指定的时间间隔，由主程序来抓取。由于 Prometheus 数据采集基于 Pull 模型进行设计，因此在网络环境的配置上必须要让 Prometheus Server 能够直接与 Exporter 进行通信。当这种网络需求无法直接满足时，就可以利用 PushGateway 来进行中转。可以通过 PushGateway 将内部网络的监控数据主动 Push 到 Gateway 当中。而 Prometheus Server 则可以采用同样 Pull 的方式从 PushGateway 中获取到监控数据。
4.Alertmanager
管理告警，主要是负责实现报警功能。在 Prometheus Server 中支持基于 PromQL 创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由 AlertManager 进行管理。在 AlertManager 中我们可以与邮件，Slack 等等内置的通知方式进行集成，也可以通过 Webhook 自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。
5. Service Discovery
Service Discovery：服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。
服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持
6. client Library
client Library：客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。
7. grafana
Grafana：是一个跨平台的开源的度量分析和可视化工具，可以将采集的数据可视化的展示，并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
Prometheus数据流向
1. Prometheus server定期从配置好的jobs或者exporters中拉取metrics，或者接收来自 Pushgateway发送过来的metrics，或者从其它的Prometheus server中拉metrics。
2. Prometheus server在本地存储收集到的metrics，并运行定义好的alerts.rules，记录新的时间序列或者向Alert manager推送警报。
3. Alertmanager根据配置文件，对接收到的警报进行处理，发出告警。
4. 在图形界面中，可视化采集数据。
四．prometheus数据模型（查询方式）
Prometheus 仅用于以“键值”(key)形式储存时序式的聚合数，不支持存储文本信息。
1.其中的“键”称为指标，它通常意味着cpu速率、内存使用率、负载等；
2.同一指标可能会适配到多个目标，比如cpu使用率这个指标，我们需要对100台服务器设备进行使用。所以它使用“标签”（labels）作为元数据，从而为指标添加更多的信息描述；
3.这些标签可以作为过滤器进行指标过滤及运算。
例如：cpu_usage{core=“1”,ip=“128.0.0.1”} 14.04
cpu_usage为指标名称，{core=“1”,ip=“128.0.0.1”}为标签（标签内的条件可以多个，用逗号分隔），14.04 为 表达式返回的值
五．Zabbix和Prometheus区别
1.和Zabbix类似，Prometheus也是一个近年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂。
2.zabbix的客户端agent可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而Prometheus的上报客户端则分为不同语言的SDK和不同用途的exporter两种，比如如果你要监控机器状态、mysql性能等，有大量已经成熟的exporter来直接开箱使用，通过http通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集。
3.zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据。
4.界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路
六．Prometheus的特点
多维数据模型：由度量名称和键值对标识的时间序列数据
时序数据，是在一段时间内通过重复测量（measurement）而获得的观测值的集合；将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴；
服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据；
1.内置时间序列（pime series）数据库：Prometheus；外置的远端存储通常会用：InfluxDB、openTsDB等
2.promQL一种灵活的查询语言，可以利用多维数据完成复杂查询
3.基于HTTP的pull（拉取）方式采集时间序列数据
4.同时支持PushGateway组件收集数据
5.通过服务发现或者静态配置，来发现目标服务对象
6.支持作为数据源接入Grafana
七．prometheus工作流程
1.Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
2.Prometheus server 把采集到的监控指标数据通过TSDB存储到本地HDD/ssD中。
3.Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager。
4.Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
5.Prometheus 自带的Web UI 界面提供PromQL 查询语言，可查询监控数据。
6.Grafana 可接入Prometheus 数据源，把监控数据以图形化形式展示出。
总结：
告警数据采集、告警信息提取、告警通知
1、首先，需要采集监控数据，pro会周期性的pull或被push指标数据，数据采集的方式主要包括exporters、instrumentation、pushgateway 3种方式，前两者为pull方式获取，pushgateway借助于push方式推送给prometheus。
2、根据prometheus配置文件中（K8S-configmap的配置种），获取被监控端的数据之后，保存在TSDB中，我们可以借助Grafana或者告警平台来展示数据，grafana的展示是通过PromQL来获取数据。
3、prometheus通过rule配置来借助于PromQL来定义布尔值表达式，产生告警信息
4、一旦出现告警，prometheus产生告警信息，发送给alertmanager,alertmanager根据自定义的告警路由，来进行告警通知，对接第三方平台，例如告警平台、邮件、钉钉。
分层
第一层：三种采集方式，三种不同的使用场景，数据采集
第二层：收集信息后保存，然后浏览器展示，grafana优化，告警逻辑，服务发现，数据提取，展示
第三层：gurafana有展示和告警，altermanager以分组形势来发送告警通知，然后定义端口，数据告警
###############################数据采集模块###################################
数据采集：通过指标暴露器和push网关来采集数据
1）.exproters
适合吧例如mysql redis' nodes的指标数据转为pro可以识别的格式（http）
2）.pushgatway（push模型）
短周期，元数据http/https方式输出的数据，一次性任务
3）.instrumtation
cadvisor，mysql内建的检测模块，nginx-vts
##############################prometheus-server端##############################
数据提取，存储：
1）默认存储在自身的tsdb中，即本地存储
2）也可以存储在分布式存储中
3）或者其他的TSDB中例如：inflxDB，OPENTSDB
展示：
1.默认使用表达式浏览器（ui）来展示数据
2.可以借用其他的展示工具/服务/插件来帮助实现可视化，例如kibana，grafana告警平台（集成）
pro-server SD (server discover)自动发现，被监控端
1.静态层面 static-config（配置什么就监控什么）
2.基于文件形式（fd-config file discover）定义如何输出，通过代码形式来定义将数据放在哪个文件中
3.注册中心，例如consul nacos
4.基于k8s方式的自动发现，通过宇api-server继承，采集metrice-server和cadvisor来自动发现pod状态
##################################展示告警模块################################
pro-server产生告警逻辑：
1.通过布尔值表达式产生告警逻辑，定义告警阈值
altermanager/garfana告警通知
通过路由分组+告警通知功能，实现触发式的监控告警给receivers（接受“人”）