普罗米修斯监控概述

---

一、常用监控的简介

1.1cacti

• Cacti(英文含义为仙人掌〉是一套基于 PHP、MySQL、SNMP和 RRDtool开发的网络流量监测图形分析工具。
  它通过snmpget来获取数据，使用RRDTool绘图，但使用者无须了解RRDTool复杂的参数。它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP 结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。
• Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能)

1.2Nagios

• Nagios是一款开源的免费网络监视工具，能有效监控windows、Linux和Unix的主机状态，交换机、打印机、路由器等网络设备。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
• nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文本配置的，不支持web方式管理和配置，这样很容易出错，不宜维护。

1.3Zabbix

• zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营;并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。

• zabbix由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix,agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux，Solaris，HP-UX，AIX,Free BSD,Open BSD,os x等平台上。

• zabbix解决了cacti没有告警的不足，也解决了nagios不能通过web配置的缺点，同时还支持分布式部署，这使得它迅速流行起来，zabbix也成为目前中小企业监控最流行的运维监控平台。当然，zabbix也有不足之处，它消耗的资源比较多，如果监控的主机非常多时（服务器数量超过500台)，可能会出现监控超时、告警超时、告警系统单点故障等现象，不过也有很多解决办法，比如提高硬件性能、改变zabbix监控模式等。

① agent代理：专门的代理服务方式进行监控，专属的协议，装有zabbix-agent的主机就可以被zabbix-server监控，主
动或被动的方式，把数据给到server进行处理。
② ssh/telent：linux主机支持ssh/telent协议
③ snmp：网络设备路由器、交换机不能安装第三方程序（agent），使用简单网络协议。大多数的路由器设备支持SNMP协议
④ ipmi：通过ipmi接口进行监控，我们可以通过标准的ipmi硬件接口，监控被监控对象的物理特征，比如电压，温度，
风扇状态电源情况，被广泛使用服务监控中，包括采集cpu温度，风扇转速，主板温度，及远程开关机等等，而且ipmi独立于硬件和操作系统，无论是cpu，bios还是os出现故障，都不会影响ipmi的工作，因为ipmi的硬件设备BMC（bashboard management controller）是独立的板卡，独立供电
⑤ zabbix核心组件介绍
Zabbix Server:
Zabbix软件实现监控的核心程序，主要功能是与Zabbixproxies和Agents进行交互、触发器计算、发送告警通知;并将数据集中保存。与prometheus的类似可以保存收集到的数据，但是prometheus告警需要使用altermanager组件
Database storage:
存储配置信息以及收集到的数据
web Interface:
Zabbix的GUI接口，通常与server运行在同一台机器上
Proxy:
可选组件，常用于分布式监控环境中，一个帮助zabbix Server收集数据，分担zabbix Server的负载的程序
Agent:
部署在被监控主机上，负责收集数据发送给server

1.5Prometheus

borg.kubernetes
borgmon(监控系统) 对应克隆的版本：prometheus(go语言)
所以prometheus 特别适合K8S 的架构上
而作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提交和7200个拉取请求
Prometheus具有以下特性:
① 多维的数据模型(基于时间序列的Key、value键值对)
② 灵活的查询和聚合语言PromQL（难）
③ 提供本地存储和分布式存储
④ 通过基于HTTP和HTTPS的Pull模型采集时间序列数据（pull数据的拉取，时间序列：每段
时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图）
⑤ 可利用Pushgateway (Prometheus的可选中间件）实现Push模式
⑥ 可通过动态服务发现或静态配置发现目标机器（通过consul自动发现和收缩）
⑦ 支持多种图表和数据大盘
open-Falcaon是小米开源的企业级监控工具，用GO语言开发，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可拓展并且高性能的监控方案。

二、监控系统背景

2.1监控系统“三代”

• 第一代：以监控网络设备、网络流量为主的时代，代表协议（SNMP，监控交换机、路由、网关、操作系统等）
  以上的系统/设备需要内置对SNMP协议的支持
  SNMP：网络管理协议，在监控手段、技术的不断迭代的过程中，虽然可以使用、兼容SNMP协议，但很多技术都"抛弃"了内置
  对SNMP协议的兼容
• 第二代（当今）： zabbix prometheus cacti nagios open-falcaon 等等
  通常具备：数据采集、存储、告警+展示/可视化等基本功能
• 第三代（大厂）：基于data驱动、ai驱动 datavops aivops，（立体监控）
  需要了解在立体监控系统支撑下对系统运行状态的分析、监控、反馈到系统展示
  监控，分为事前监控和事后监控
  事：异常状态
  设定：磁盘使用率来看（80%）
  事前监控（运行状态，趋势分析）： 当我门系统的磁盘负载从10%~30% 呈现了一种并发式的增长速率，通过机器学习、监控预判、预测到未来2个小时—3个小时期间，会直接飙到 80%+ ，就会进行告警
  事后监控： 固定死了80%，没超过80% 不会告警，仅当超过时，才会告警
  不稳定是常态、稳定（区间范围）是特殊的表现形式
  大多数系统不是自治的，所以即使使用控制起来进行系统管理，但随着时间推移，依然无发保证持续性的自治，所以做为使用者而言，通过监控来了解系统的运行特性，来做对应的处理决策是相当重要的，而监控以细致化划分，会划分为事前监控、事后监控（例如体检）

2.2基础/逻辑概念前提

监控系统的四个基础功能,以监控系统的主体而言
使用/管理者所关注的被监控“系统”（端）的相关组件，例如路由器、交换机、网关、应用、基础设施服务、业务特征等

2.3基础/逻辑概念（二）：

但以上对象必须允许在基础设施层，例如物理主机、vm、container,那么我们就需要对这些基础设施层中关键的，伴随时间变化而变化的数据，进行采集分析，而此类数据称之为【指标】

1、指标数据采集到之后，作为“点状数据”，而此类点状数据称之为【样本数据】
2、而此类【样本数据】做为事后的分析(趋势分析)，那么如果我们所需要监控的目标特别多，那么我们就需要存储大量数据
3、那么在持续存储性能表现上必须要强【TSDB数据库】，那么接下来对此类样本数据进行分析，明确系统运行状态、特性，来预测、判断未来的某一时间、时刻是否会出现问题时我们的目的
4、同时为了结果的可观测及清晰性，我们会做一些【可视化】处理分析功能，所以需要控制台（例如grafana）（目前的形式，可视化与低代码趋势）过滤手段：PromQL（数据过滤语句）
5、我们也需要有一个守护进程，实时监测特定的样本序列、指标时间序列是否有异常状态,而通常此类异常状态的判断会以一种【布尔值表达式】的方式来做为判断依据
6、满足布尔值表达式的要求（true）的指标我们认为时异常指标，而此时我们就可以通过触发一种“媒介”（media）,把异常信息通知给用户，例如钉钉、webchat、短信、邮件等

三、运维监控平台设计思路

• 数据收集模块
• 数据提取模块
• 监控告警模块
• 细化分为6层：
  第六层:用户展示管理层：同一用户管理、集中监控、集中维护
  第五层:告警事件生成层：实时记录告警事件、形成分析图表（趋势分析、可视化)
  第四层:告警规则配置层：告警规则设置、告警伐值设置（定义布尔值表达式，筛选异常状态）
  第三层:数据提取层：定时采集数据到监控模块
  第二层:数据展示层：数据生成曲线图展示（对时序数据的动态展示）
  第一层:数据收集层：多渠道监控数据（网络、硬件、应用、数据，物理环境）
  prometheus监控体系

四、prometheus监控体系

(一)监控体系

① 系统层监控（需要监控的数据）

1.CPU、Load、Memory、swap、disk i/o、process等
2.网络监控：网络设备、工作负载、网络延迟、丢包率等

② 中间件及基础设施类监控 端监控（移动APP、特定程序等）

1.消息中间件：kafka、RocketMQ、等消息代理
2.WEB服务器容器：tomcat
3.数据库/缓存数据库：MySQL、PostgreSQL、MogoDB、es、redis
redis监控内容：
redis所在服务器的系统层监控
redis 服务状态
RDB AOF日志监控
日志——>如果是哨兵模式——>哨兵共享集群信息，产生的日志——>直接包含的其他节点哨兵信息及redis信息

③ 应用层监控

用于衡量应用程序代码状态和性能
监控的分类：黑盒监控，白盒监控（pro）
白盒监控，自省指标（可自己产生指标，自治功能），等待被获取
白盒监控支持通过三种途径从目标抓取（scrape）指标数据，如下：
exporters ：指标暴露器，（当服务不支持pro格式，借助于exporter来响应给pro）
instumentation ：测量系统（被监控’端’），指的是应用程序内置本身兼容pro采集格式的指标暴露器
pushgateway ：短期、批处理任务，本身此类业务不会产生指标数据，同时难于使用exporter来获取指标数据的任务 ，以上为pro典型的采集数据的方式
linux mysql redis 资源负载/状态 持续性的过程状态
一次性、短期的、批量的业务，处理完后，进程直接退出
pushgateway 将以上短期的业务指标数据，收集到网关处，然后定期cron 推送给pro-server
黑盒指标：基于探针的监控方式，不会主动干预、影响数据

④ 业务层监控

用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，
业务接口：登入数量，注册数、订单量、搜索量和支付量
云原生时代的可观测性
可观测性系统（立体监控）以下为三个维度：
① 指标监控：随时间推移产生的一些与监控相关的可聚合的数据点（离散数据）——》pro做为代表
② 日志监控：离散式的日志或事件（日志结构化、非结构化概念）
③ 链路跟踪：分布式应用调用链跟踪（时长、状态数据）
以上是可观测性系统应具有的三个概念，而pro 只是其中一个维度

四个黄金指标 谷歌出了sre书
① 延迟：
服务请求时长
区分失败与成功的请求 code!=“200” 请求失败的数据
② 流量
应用服务容量需求，如每秒处理HTTP请求或数据库系统的事务数量
③ 错误
请求失败的速率、衡量错误发送的情况
例如：HTTP 500
④ 饱和度
资源使用情况、负载情况
例如 5大负载等资源
监控：五大负载、应用状态、主从状态、sql语句数量

五、Prometheus简介

谷歌的内部大型集群系统borg，是kubernetes的前身。其监控系统是borgmon，而prometheus是其克隆版，所以非常契合k8s的监控对容器非常适用。
Prometheus本身为一种时序数据库（TSDB），还具备开源的监控、报警、时间序列、数据库的组合。其设计用于进行目标（target）监控的关键组件
⭐⭐TSDB：pro通过采集的样本以时间序列的方式保存在内存（TSDB时序数据库）中并定时保存到硬盘中（持久化）
⭐⭐⭐target：主要指可输出、产生指标数据的组件/对象，包括但不限于主机、应用、服务、K8S ingress（逻辑组件）等
小结：能正常输出指标数据的对象称为target 或网络端点（表现形式，例如：192.168.226.128:9100,192.168.226.128:8500）
⭐⭐时序数据：一段时间内通过《重复》测量而获得的观测值的集合，并且可将这些观测值绘制与图形之上，以数据轴（纵轴）和时间轴（横轴）来表示随着时间流逝而产生的“渐变”变化（类似与股票）
小结：能随着时间流逝，而能不断采集到的点数据称为时序数据
时序数据库不属于sql数据库也并不是nosql数据库
官网：https://prometheus.io/docs/concepts/data_model/

5.1Prometheus特点：

• 自定义多维数据模型（时序列数据由metric名和一组key/value标签组成）
• 非常高效的储存平均一个采样数据占大约3.5bytes左右，320万的时间序列，每30秒采样，默认保持60天，消耗磁盘大概228G
• 在多维上灵活且强大的查询语句（PromQL）
• 不依赖分布式储存，支持单主节点工作
• 通过基于HTTP的pull方式采集时序数据
• 可以通过push gateway进行时序列数据库推送（pushing）
• 可以通过服务发现或静态配置去获取要采集的目标服务器（sd server discover）
• 多种可视化图表及仪表盘支持
• prometheus 最难的两个部分
• promQL 查询语句
• 重打标签
• 监控开发
• 语言，python、java

5.2使用场景

• Prometheus可以很好地记录任何纯数字时间序列。它既适用于以机器为中心的监视，也适用于高度动态的面向服务的体系结构的监视。在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。（云原生 k8s）
• Prometheus是为可靠性而设计的，它是您在中断期间监控使用的系统，可让您快速诊断问题。每个Prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您可以依靠它，并且无需设置广泛的基础结构即可使用它

5.3不适合的场景

• 普罗米修斯重视可靠性。即使在故障情况下，您始终可以查看有关系统的可用统计信息。如果您需要100%的准确性（例如按请求计费)，则Prometheus并不是一个不错的选择，因为所收集的数据可能不会足够详细和完整。在这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余的监视。数据准确性要求极高的场景，不适合使用prome

六、prometheus时序数据

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

6.1数据来源:

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

6.2收集数据:

• 监控概念:白盒监控、黑盒监控
• 白盒监控:自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可
  黑盒监控:对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议）
• Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控);
• Exporters ——>工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送
• Instrumentation ——>指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
• Pushgateway ——>短周期5s—10s的数据收集 脚本

6.3prometheus(获取方式)

• Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据，而非等待被监控端的推送(push)
• 两个获取方式各有优劣，其中，Pull模型的优势在于:
• 集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等;
• Prometheus的根本目标在于收集在rarget上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统
• 通过targets（标识的是具体的被监控端）

七、prometheus生态组件

prometheus生态圈中包含了多个组件，其中部分组件可选

7.1Prometheus Server：收集和储存时间序列数据

通过scraping以刮擦的方式去获取数据放入storge（TSDB时序数据库），制定Rules/Alerts：告警规则，service discovery是自动发现需要监控的节点
时间序列数据，按照事件推移，在某一个时间刻度，同一个样本数据采集的时间不会绝对的一直，会随机延迟或提前一点进行采集

7.2Client Library:客户端库

目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径;

7.3Push Gateway

接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作;

7.4Exporters

• 用于暴露现有应用程序或服务（不支持Instrumentation)的指标给Prometheus Server
• 而pro内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus 采集过后，会存储在自己内建的TSDB数据库中，提供了promQL 支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具（grafana）来展示数据
• 采集、抓取数据是其自身的功能，但一般被抓去的数据一般来自于:
  export/instrumentation （指标数据暴露器） 来完成的，或者是应用程序自身内建的测量系统（汽车仪表盘之类的，测量、展示）来完成

7.5Alertmanager

由告警规则对接，从Prometheus Server接收到"告警通知"后，通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送

7.6Data Visualization（Dashboards）

与TSDB对接并且展示数据库中的数据，Prometheus web UI (Prometheus Server内建)，及Grafana等;

7.7Service Discovery

动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用;该组件目前由PropetheusServer内建支持