Prometheus---不是每一个监控都能盗火

---

引言

我们知道 zabbix 在监控界占有不可撼动的地位，功能强大。但是对容器监控显得力不从心。为解决监控容器的问题，引入了 Prometheus 技术。

---

一、Prometheus 概述

1. 简介

Prometheus是一个开源的系统监控和警报工具包。自2012年启动以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。Prometheus于2016年加入云原生计算基金会，成为继Kubernetes之后的第二个托管项目。

2. 特性

• 可以自定义多维数据模型，储存更加高效
• 具有灵活且强大的查询语句（PromQL）
• 提供本地存储和分布式存储
• 通过基于HTTP和HTTPS的Pull模型采集时间序列数据（pull数据的推送，时间序列：每段时间点的数据值指标，持续性的产生。横轴标识时间，纵轴标识数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图）
• 可以通过push gateway进行时序列数据库推送
• 可以通过服务发现或静态配置去获取要采集的目标服务器（通过consul自动发现和收缩）
• 支持多种可视化图表及仪表盘

3. 监控三大核心步骤

① 数据收集模块 ② 数据提取模块 ③ 监控告警模块

• 可以细化为下面6层
  第一层：数据收集层 （多渠道监控数据）
  第二层：数据展示层 （数据生成曲线图展示，对时序数据的动态展示)
  第三层：数据提取层 （定时采集数据到监控模块）
  第四层：告警规则配置层 （告警规则设置、告警伐值设置）
  第五层：告警事件生成层 （实时记录告警事件、形成分析图表，趋势分析、可视化）
  第六层：用户展示管理层 （同一用户管理、集中监控、集中维护）

二、Prometheus 监控体系

1. 系统层监控

• CPU、load、Memory、swap、disk、I/O、process 等

• 网络监控：网络设备、工作负载、网络延迟、丢包率等

2. 中间件及基础设施类监控

• 消息中间件：Kafka、RocktMQ 等消息代理
• web 服务器容器：tomcat、weblogic、apache、php、spring 系列
• 数据库/缓存数据库：MySQL、PostgreSQL、MogoDB、es、redis

redis监控的内容：
redis 所在服务器的系统层监控
redis 服务状态
RDB AOF 日志监控
日志——》如果是哨兵模式——》哨兵共享集群信息，产生的日志——》直接包含的其他节点哨兵信息及redis信息
key 的数量
key被命中的数据/次数
redis和系统的最大连接数

• 补充：

#redis 的最大连接数查询
redis-cli 登录
config get maxclients 

3. 应用层监控

用于衡量应用程序代码状态和性能

4. 业务层监控

用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等
业务接口：登入数量，注册数、订单数、搜索量和支付量

三、Prometheus 时序数据

时序数据，是在一段时间内通过重复测量(measurement)而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据。

1. 数据来源

• prometheus 基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口）上周期性获取指标数据
• 很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，prometheus-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式)

2. 收集数据

收集数据分为白盒监控、黑盒监控
白盒监控： 自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可
黑盒监控： 对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议）

• Prometheus属于白盒监控，支持通过以下三种类型的途径从木板上抓取指标数据：

① Exporters ：指标暴露器；工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送
② Instrumentation：应用程序内置的指标暴露器；指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
③ Pushgateway：专用于收集短周期（5~10s的数据收集）、临时的任务，等待prometheus拉取

3. prometheus 获取方式

Prometheus 同其它 TSDB 相比有一个非常典型的特性：它主动从各 Target 上拉取(pull)数据，而非等待被监控端的推送(push)

• 两个获取方式各有优劣，其中，pull 模型的优势在于：
  ① 集中控制：有利于将配置集中在 Prometheus server 上完成，包括指标及采取速率等
  ② Prometheus 的根本目标在于收集在 target 上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统
  ③ 通过targets（标识的是具体的被监控端）

四、Prometheus 生态组件

• Prometheus Server：服务端；收集和储存时间序列数据；
• Client Library：客户端库；目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径
• Exporters ：指标暴露器
• Push Gateway：接收那些通常由短期作业生成的指标数据的网关
• Prometheus Service Discovery(sd)：服务动态发现待监控的Target，发送告警信息
• Prometheus scrape：数据采集器
• Alertmanager：由告警规则对接
• Instrumentation：应用程序内置的指标暴露器
  Data Visualization（Dashboards）：(prome-UI界面)

五、Prometheus 数据模型

1. 概述

• Prometheus 仅用键值方式存储时序式的聚合数据，不支持文本信息

• 其中的 “键” 称为指标（metric），通常意味着CPU速率、内存使用率或分区空闲比例等

• 同一指标可能适配到多个目标或设备、因而它使用 “标签”作为元数据，从而为metric添加更多的信息描述维度

• Prometheus 每一份样本数据都包含了：
  ① 时序列标识：key+lables
  ② 当前时间序列的样本值value
  ③ 这些标签可以作为过滤器进行指标过滤及聚合运算，如何从上万的数据过滤出关键有限的时间序列，同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们想要的样本数据

2. 指标类型

• 默认都是以双精度浮点型数据（服务器端无数据量类型数据）
  ① counter：计数器单调递增
  ② gauge：仪表盘:有起伏特征的
  ③ histogram：直方图
  在一段时间范围内对数据采样的相关结果，并记入配置的bucket中，他可以存储更多的数据，包括样本值分布在每个bucket的数量，从而prometheus就可以使用内置函数进行计算：
  计算样本平均值：以值得综合除以值的数量
  计算样本分位值：分位数有助于了解符合特定标准的数据个数，例如评估响应时间超过1秒的请求比例，若超过20侧则进行告警等
  ④ summary：摘要，histogram的扩展类型，它是直接由监控端自行聚合计算出分位数，同时将计算结果响应给prometheus server的样本采集请求，因而，其分位数计算是由监控端完成

3. 作业 job 和实列 targets/instance

① job：能够接收 prometheus server 数据 scrape ，如 “mysql nodes” “mysql master slave”
② targets：每一个可以被监控的系统，成为 targets 多个相同的 targets 的集合（类）称为 job
③ instance：实例与 targets 类似
与 target 相比，instance 更趋近于一个具体可以提供监控数据的实例，而 targets 则更像一个对象、目标性质

4. PrometheusQL（数据查询语言也是时序数据库使用语言)

支持两种向量，同时内置提供了一组用于数据处理的函数

① 即时向量：最近以此时间戳上跟踪的数据指标，表示的是一个时间刻度；
即时向量选择器：返回0个1个或者多个时间序列上在给定时间戳上的各自的一个样本，该样本成为即时样本
② 时间范围向量：指定时间范围内所有时间戳上的数据指标，表示的是一组时间区间；
范围向量选择器：返回0个1个或多个时间序列上在给定时间范围内的各自的一组样本(范围向量选择器无法用于绘图)