目录
引言
一.prometheus结构图(可分三层)
(1)提取采集(三种)
(2)数据提取,存储
(3)告警模块
二.pull和push
三.prometheus的生态组件
1. Prometheus Server
2.Exporters
3.PushGateway
4.Alertmanager
5. Service Discovery
6. client Library
7. grafana
Prometheus数据流向
四.prometheus数据模型(查询方式)
五.Zabbix和Prometheus区别
六.Prometheus的特点
七.prometheus工作流程
总结:
Prometheus是一个开源的系统监控和报警系统,现在已经加入到CNCF基金会,成为继k8s之后第二个在CNCF托管的项目,在kubernetes容器管理系统中,通常会搭配prometheus进行监控,同时也支持多种exporter采集数据,还支持pushgateway进行数据上报,Prometheus性能足够支撑上万台规模的集群。
它的存在允许短暂和批量作业将其指标暴露给 Prometheus。由于这些工作的生命周期可能不足够长,不能够存在足够的时间以让 Prometheus 抓取它们的指标。Pushgateway 允许它们可以将其指标推送到 Pushgateway,然后 Pushgateway 再将这些指标暴露给 Prometheus 抓取。
pushgateway实际上式短周期,元数据http/https方式输出的数据,一次性任务的模块
测量系统,指应用系统内置的,本身就兼容Prometheus 格式的置标数据,内建了Prometheus 格式兼容的指标暴露器。
例如:nginx的vts监控模块
内键暴露器,将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server,Prometheus Server通过访问该Exporter提供的Endpoint端点,即可以获取到需要采集的监控数据
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状态
1.pro-server产生告警逻辑
2.通过布尔值表达式产生告警逻辑,定义告警阈值
3.altermanager/garfana告警通知
4.通过路由分组+告警通知功能,实现触发式的监控告警给receivers(接受“人”)
1.首先普罗米修斯式使用pull来主动拉取数据的,Prometheus同其他时序数据库相比有一个非常典型的特性:它是主动从各TARGET(客户端)上拉取(pull)数据,而非等待监控端的推送(push)
2.pull的优势在于,集中控制有利于配置集在Prometheus server上完成,包括指标和采集的速率。
3.Prometheus的目标是收集在TARGET上预先完成聚合的聚合性数据,而非事件性驱动的存储系统。
Prometheus组件中的核心部分,收集和存储时间序列数据,提供PromQL查询语言的支持。内置的 Express Browser UI,通过这个 UI 可以直接通过 PromQL 实现数据的查询以及可视化。
将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server,Prometheus Server通过访问该Exporter提供的Endpoint端点,即可以获取到需要采集的监控数据
主要是实现接收由 Client push 过来的指标数据,在指定的时间间隔,由主程序来抓取。由于 Prometheus 数据采集基于 Pull 模型进行设计,因此在网络环境的配置上必须要让 Prometheus Server 能够直接与 Exporter 进行通信。当这种网络需求无法直接满足时,就可以利用 PushGateway 来进行中转。可以通过 PushGateway 将内部网络的监控数据主动 Push 到 Gateway 当中。而 Prometheus Server 则可以采用同样 Pull 的方式从 PushGateway 中获取到监控数据。
管理告警,主要是负责实现报警功能。在 Prometheus Server 中支持基于 PromQL 创建告警规则,如果满足PromQL定义的规则,则会产生一条告警,而告警的后续处理流程则由 AlertManager 进行管理。在 AlertManager 中我们可以与邮件,Slack 等等内置的通知方式进行集成,也可以通过 Webhook 自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。
Service Discovery:服务发现,用于动态发现待监控的Target,Prometheus支持多种服务发现机制:文件、DNS、Consul、Kubernetes等等。
服务发现可通过第三方提供的接口,Prometheus查询到需要监控的Target列表,然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持
client Library:客户端库,目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径,用于基于应用程序内建的测量系统。
Grafana:是一个跨平台的开源的度量分析和可视化工具,可以将采集的数据可视化的展示,并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
1. Prometheus server定期从配置好的jobs或者exporters中拉取metrics,或者接收来自 Pushgateway发送过来的metrics,或者从其它的Prometheus server中拉metrics。
2. Prometheus server在本地存储收集到的metrics,并运行定义好的alerts.rules,记录新的时间序列或者向Alert manager推送警报。
3. Alertmanager根据配置文件,对接收到的警报进行处理,发出告警。
4. 在图形界面中,可视化采集数据。
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 为 表达式返回的值
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还是二者的必走之路
多维数据模型:由度量名称和键值对标识的时间序列数据
时序数据,是在一段时间内通过重复测量(measurement)而获得的观测值的集合;将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴;
服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据;
1.内置时间序列(pime series)数据库:Prometheus;外置的远端存储通常会用:InfluxDB、openTsDB等
2.promQL一种灵活的查询语言,可以利用多维数据完成复杂查询
3.基于HTTP的pull(拉取)方式采集时间序列数据
4.同时支持PushGateway组件收集数据
5.通过服务发现或者静态配置,来发现目标服务对象
6.支持作为数据源接入Grafana
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(接受“人”)