Prometheus-----1
文章目录
- Prometheus
-
- zabbix与prometheus区别
- Prometheus概述
-
- Prometheus具有以下特性
- Prometheus核心组件
- 运维监控平台设计思路
- prometheus监控体系
-
- **监控体系**
- 系统层监控（需要监控的数据)
- 中间件及基础设施类监控端监控（移动APP、特定程序等)
- 应用层监控
- 业务层监控
- prometheus时序数据
-
- 数据来源
- 收集数据
- prometheus(获取方式)
- prometheus的部署
-
- 修改配置文件
- 配置系统启动文件，设置开机自启
- 开启prometheus,并访问网页验证
- prometheus生态组件
-
- prometheus-server
- pushgateway (短期周期任务)
- exporters (常规任务—守护进程)
- service discovery:原生支持k8s的服务发现,支持consul、DNS等
- prometheus内置TSDB数据库作为存储（时序数据的储存，promtheus的TSDB数据库默认保存15天，可以自行调整)
- alertmanagr
- data visualization
- PrmoQL (告警规则编写)
- UI : 表达式浏览器（调试)
- 总结
-
- prometheus如何收集k8s/服务的–三种方式收集
- 如何防止告警信息轰炸
- prometheus 工作流程
- prometheus监控什么
-
- 网络监控
- 存储监控
- 服务器监控
- 中间件监控
- 常见的时间序列数据库
- 四个黄金指标
-
- 延迟：服务请求所需时间
- 通讯量：监控当前系统的流量，用于衡量服务的容量需求
- 错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率
- 饱和度：衡量当前服务的饱和度
Prometheus
zabbix与prometheus区别
- 和Zabbix类似，Prometheus也是一个近年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂
- zabbix的客户端agent可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而Prometheus的上报客户端则分为不同语言的SDK和不同用途的exporter两种，比如如果你要监控机器状态、mysql性能等，有大量已经成熟的exporter来直接开箱使用，通过http通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集
- zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据
- 界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路
Prometheus概述
- borgmon (监控系统) 对应克隆的版本:prometheus(go语言)
- 所以prometheus 特别适合K8S 的架构上,作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提交和7200个拉取请求
Prometheus具有以下特性
- 多维的数据模型(基于时间序列的Key、value键值对)
- 灵活的查询和聚合语言PromQL
- 提供本地存储和分布式存储
- 通过基于HTTP和HTTPS的Pull模型采集时间序列数据（pull数据的拉取，时间序列:每段 时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图)
- 可利用Pushgateway (Prometheus的可选中间件）实现Push模式
- 可通过动态服务发现或静态配置发现目标机器（通过consul自动发现和收缩)
- 支持多种图表和数据大盘
- 补充: apen-Falcaon(夜莺)是小米开源的企业级监控工具，用Go语言开发，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可拓展并且高性能的监控方案
Prometheus核心组件
整个Prometheus生态包含多个组件，除了Prometheus server组件其余都是可选的
- Prometheus Server：主要的核心组件，用来收集和存储时间序列数据
- Client Library:：客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics
- push gateway：主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter
- Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus
- Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等
- 各种支持工具
运维监控平台设计思路
-
数据收集模块
-
数据提取模块(prometheus-TSDB,查询语言是promQL)
-
监控告警模块（布尔值表达式判断是否需要告警，不成立是健康状态）
-
可以细化为6层
第六层:用户展示管理层 同一用户管理、集中监控、集中维护
第五层:告警事件生成层 实时记录告警事件、形成分析图表（趋势分析、可视化)
第四层:告警规则配置层 告警规则设置、告警伐值设置（定义布尔值表达式，筛选异常状态）
第三层:数据提取层 定时采集数据到监控模块
第二层:数据展示层 数据生成曲线图展示（对时序数据的动态展示)
第一层:数据收集层 多渠道监控数据（网络，硬件，应用，数据，物理环境）
prometheus监控体系
监控体系
系统层监控（需要监控的数据)
- CPU、Load、Memory、swap、disk i/o、process等
- 网络监控 ：网络设备、工作负载、网络延迟、丢包率等
中间件及基础设施类监控端监控（移动APP、特定程序等)
- 消息中间件:kafka、RocketMQ、等消息代理
- WEB服务器容器:tomcat、weblogic/apache/php/spring系列
- 数据库/缓存数据库:MysQL、PostgresQL、MogoDB、es、redis
监控数据库哪些东西？例如redis监控内容:
- redis所在服务器的系统层监控
- redis 服务状态
- RDB AOF日志监控
- 日志—>如果是哨兵模式—>哨兵共享集群信息，产生的日志—>直接包含的其他节点哨兵信息及redis信息
- key的数量
- key被命中的数量/次数
- 最大连接数——>redis 和 系统：
- 系统：ulimit -a redis :redis-cli 登陆——> config get maxclients 查看最大连接
应用层监控
- 用于衡量应用程序代码状态和性能
- 监控的分类:黑盒监控，白盒监控( promtheus)
白盒监控 ：自省指标，等待被下载（只需要去拿就行）
黑盒指标： 基于探针的监控方式，不会主动干预、影响数据（摄像头这种）
业务层监控
- 用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，业务接口:登入数量，注册数、订单量、搜索量和支付量
prometheus时序数据
- 时序数据，是在一段时间内通过重复测量(measurement）而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据;
数据来源
- prometheus基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口)上周期性获取指标数据
- 很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，promethens-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式）
收集数据
- 监控概念 : 白盒监控、黑盒监控
- 白盒监控 : 自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可
- 黑盒监控 : 对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（ snmp协议)
Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控)
Exporters一>工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送
Instrumentation一>指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
Pushgateway —>短周期5s-10s的数据收集脚本
prometheus(获取方式)
Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据，而非等待被监控端的推送(push)
两个获取方式各有优劣，其中，Pull模型的优势在于:
- 集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等;
- Prometheus的根本目标在于收集在target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统通过targets(标识的是具体的被监控端)
- 比如配置文件中的targets : [ ‘localhost:9090’]
prometheus的部署
上传prometheus-2.39.1.linux-amd64.tar.gz /opt 目录中，并解压
tar xf prometheus-2.39.1.linux-amd64.tar.gz
mv prometheus-2.39.1.linux-amd64 /usr/local/prometheus
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6DUieAVW-1666694481613)(F:\typorase\jpg\962.png)]](http://img.e-com-net.com/image/info8/d2ca29eef9a94a85b75bdfc313ce49e8.jpg)
修改配置文件
vim prometheus.yml
global: #用于prometheus的全局配置，比如采集间隔，抓取超时时间等
scrape_interval: 15s #采集目标主机监控数据的时间间隔，默认为1m
evaluation_interval: 15s #触发告警生成alert的时间间隔，默认是1m
# scrape_timeout is set to the global default (10s).
scrape_timeout: 10s #数据采集超时时间，默认10s
alerting: #用于alertmanager实例的配置，支持静态配置和动态服务发现的机制
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
rule_files: #用于加载告警规则相关的文件路径的配置，可以使用文件名通配机制
# - "first_rules.yml"
# - "second_rules.yml"
scrape_configs: #用于采集时序数据源的配置
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: "prometheus" #每个被监控实例的集合用job_name命名，支持静态配置（static_configs）和动态服务发现的机制（*_sd_configs）
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs: #静态目标配置，固定从某个target拉取数据
- targets: ["localhost:9090"]
配置系统启动文件，设置开机自启
vim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \
--storage.tsdb.path=/usr/local/prometheus/data/ \
--storage.tsdb.retention=15d \
--web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target
开启prometheus,并访问网页验证
systemctl start prometheus
systemctl enable prometheus
netstat -natp | grep :9090
浏览器访问：http://192.168.116.134:9090
状态为up，说明prometheus能正常采集到数据
http://192.168.116.134:9090/metrics 可以查看监控的数据
prometheus生态组件
prometheus架构图：
prometheus-server
- etrieval(获取数据pull/discover） ，TSDB存储，HTPserver
- 控制台接口，内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus采集过后，会存储在自己内建的TSDB数据库中(默认为2个月时间))，提供了prompL支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具(grafana）来展示数据
pushgateway (短期周期任务)
- 允许短暂和批量作业将其指标暴露给普罗米修斯，由于这些类型的作业可能存在时间不足而被删除，因此他们可以将其指标推送到pushgateway，然后pushgateway将这些指标暴露给Prometheus-server端，主要用于业务数据汇报
exporters (常规任务—守护进程)
- 专门采集一些web服务，nginx，mysgl服务。因为不适合直接通过nttp的方式采集数据，所以需要通过exporter采集数据（下载mysqgl_exporter，采集mysql数据指标）cadvisor: docker数据收集工具(docker也有自己内置的监控收集方式)
exporter和instrumtations，负责专门服务数据的收集然后暴露出来等待promtheus收集
service discovery:原生支持k8s的服务发现,支持consul、DNS等
prometheus内置TSDB数据库作为存储（时序数据的储存，promtheus的TSDB数据库默认保存15天，可以自行调整)
- ps:时间序列数据库（时序数据库）主要用于指处理代表签（按照时间的顺序变化，既时间序列化）的数据，带时间标签的数据也成为时间序列数据，这是一种特殊类型的数据库，一般不会保存长时间的数据（与mysql相比）
- 数据保存时间storge.tsdb.retention=90d参数中修改即可（或启动时间指定)
alertmanagr
- prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件altermanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸
data visualization
- prometheus web ui (prometheus-server内建，表达式浏览器），也可以使用grafana
PrmoQL (告警规则编写)
- 通常告警规则的文件指定输出到展示界面（grafana）
UI : 表达式浏览器（调试)
总结
prometheus如何收集k8s/服务的–三种方式收集
- Exporters（指标暴露器） ：收集节点的信息、将数据格式化或转化为promtheus可识别的http这种转化方式/镜像拉取方式
- Instrumentation （应用内置的指标暴露器）： 收集有内置指标暴露器的信息
- Pushgateway ： 收集短周期的数据
如何防止告警信息轰炸
alertmanagr: prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件altermanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸
- 把这条告警规则中的支持静默开启，让它必须，配置文件里直接改alertmanagr改一个单词
prometheus 工作流程
- Prometheus server定期从配置好的jobs或者exporters中拉取metrics，或者接收来自 Pushgateway发送过来的metrics，或者从其它的Prometheus server中拉metrics
- Prometheus server在本地存储收集到的metrics，并运行定义好的alerts.rules，记录新的时间序列或者向Alert manager推送警报
- Alertmanager根据配置文件，对接收到的警报进行处理，发出告警
- 在图形界面中，可视化采集数据
基本原理
服务发现：Prometheus周期性得以pull的形式对target进行指标采集，而监控目标集合是通过配置文件中所定义的服务发现机制来动态生成的。也可以静态配置；
relabel：当服务发现得到所有target后，Prometheus会根据job中的relabel_configs配置对target进行relabel操作，得到target最终的label集合。
采集：进行完上述操作后，Prometheus为这些target创建采集循环，按配置文件里配置的采集间隔进行周期性拉取，采集到的数据根据Job中的metrics_relabel_configs进行relabel，然后再加入上边得到的target最终label集合，综合后得到最终的数据。
存储：Prometheus不会将采集到的数据直接落盘，而是会将近2小时的series缓存在内存中，2小时后，Prometheus会进行一次数据压缩，将内存中的数据落盘。
流程：服务发现 ==> targets ==> relabel ==> 抓取 ==> metrics_relabel ==> 缓存 ==> 2小时落盘
- Prometheus Server 可定期从活跃的目标主机上（target）拉取监控指标数据，目标主机的监控数据可以通过配置静态job或者服务发现的方式被Prometheus server采集到，这种方式默认是pull方式拉取指标；也可以通过pushgateway把采集的数据上报到Prometheus server中；还可以通过一些组件自带的exporter采集相应组件的数据；
- Prometheus server的时间序列把采集到的监控指标数据整合并保存到本地的磁盘或者数据库中；
- Prometheus采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager；
- Alertmanager 通过配置报警接受方，发送报警到邮件，微信等；
- Prometheus 自带的web ui界面提供PromQL查询语言，可查询监控数据；
- Grafana 可接入Prometheus数据源，把监控数据以图形化展示出；
prometheus监控什么
| 级别 | 监控什么 | Expoer |
|---|---|---|
| 网络 | 网络协议:http、dns、tcp、icmp；网络硬件；路由器、交换机 | BlckBox Exporter；SNMP Exporter |
| 主机 | 资源用量 | node exporter |
| 容器 | 资源用量 | cAdvisor |
| 应用 | 延迟，错误，QPS，内部状态等 | 代码中集成Prmometheus Client |
| 中间件状态 | 资源用量，以及服务状态 | 代码中集成Prmometheus Client |
| 编排工具 | 集群资源用量，调度等 | Kubernetes Components |
网络监控
- 网络性能监控：主要涉及网络监测，网络实时流量监控（网络延迟、访问量、成功率）和历史数据统计、汇总和历史数据分析等功能
- 网络检测：主要针对内网或者外网的网络。如DDoS的。通过分析异常流量来确定网络行为。
设备监控：主要针对数据中心内的多种网络设备进行监控。包括路由器，防火墙和交换机等硬件设备，可以通过snmp等协议收集数据
存储监控
- 存储性能监控方面：存储通常监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储通常监控文件系统inode。读写速度、目录权限等
- 存储系统监控方面：不同的存储系统有不同的指标，例如，对于ceph存储需要监控OSD, MON的运行状态，各种状态pg的数量以及集群IOPS等信息
- 存储设备监控方面：对于构建在x86服务器上的存储设备，设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，通常自带监控功能，可监控设备的运行状态，性能和容量的
服务器监控
- CPU：涉及整个 CPU 的使用量、用户态百分比、内核态百分比，每个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等
- 内存：涉及内存的使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常等
- 网络 I/O：涉及每个网卡的上行流量、下行流量、网络延迟、丢包率等
- 磁盘 I/O：涉及硬盘的读写速率、IOPS、磁盘用量、读写延迟等
中间件监控
- 消息中间件： RabbitMQ Exporter、Kafka Exporter
- Web 服务中间件：Apache Exporter、Nginx Exporter
- 数据库中间件：MySQL Exporter、PostgreSQL Exporter、Redis Exporter
常见的时间序列数据库
| TSDB项目 | 官网 |
|---|---|
| influxDB | InfluxDB: Open Source Time Series Database | InfluxData |
| RRDtool | RRDtool - About RRDtool |
| Graphite | Graphite |
| OpenTSDB | OpenTSDB - A Distributed, Scalable Monitoring System |
| Kdb+ | KX: The Leading Provider of Time-Series Database Technology |
| Druid | Druid | Database for modern analytics applications |
| KairosDB | KairosDB |
| Prometheus | Prometheus - Monitoring system & time series database |
四个黄金指标
4个黄金指标可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。主要关注与以下四种类型的指标：延迟，通讯量，错误以及饱和度：
延迟：服务请求所需时间
记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。 例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此以外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的
通讯量：监控当前系统的流量，用于衡量服务的容量需求
流量对于不同类型的系统而言可能代表不同的含义。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数；
错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率
对于失败而言有些是显式的(比如, HTTP 500错误)，而有些是隐式(比如，HTTP响应200，但实际业务流程依然是失败的)。
对于一些显式的错误如HTTP 500可以通过在负载均衡器(如Nginx)上进行捕获，而对于一些系统内部的异常，则可能需要直接从服务中添加钩子统计并进行获取
饱和度：衡量当前服务的饱和度
主要强调最能影响服务状态的受限制的资源。 例如，如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘I/O，那就主要观测磁盘I/O的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，比如，“磁盘是否可能在4个小时候就满了”