Prometheus监控（更新中）

Posted 2021-09-28 水木，年華

Prometheus监控

• 一、常用监控简介

一、常用监控简介

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

2、Nagios
Nagios是一款开源的免费网络监视工具，能有效监控windows、Linux和Unix的主机状态，交换机路由器等网络设备打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知

nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文本配置的，不支持web方式管理和配置,这样很容易出错,不宜维护。

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

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

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

①agent代理:专门的代理服务方式进行监控，专属的协议，装有zabbix-agent的主机就可以被zabix-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:
软件实现监控的核心程序，主要功能是与zabbix proxies和Aents进行交互、触发器计算、发送告警通知;并将数据集中保存。与prometheus的类似可以保存收集到的数据，但是prometheus告警需要使用alter manager组件
②Database storage :
存储配置信息以及收集到的数据
③web Interface:
Zabbix的GUI接口，通常与server运行在同一台机器上
④Proxy:
可选组件，常用于分布式监控环境中，一个帮助zabbix Server收集数据,分担zabbix Server的负载的程序
⑤Agent:
部署在被监控主机上，负责收集数据发送给server

4、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语言开发，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可拓展并且高性能的监控方案。

二、监控系统背景和分类
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、基础/逻辑概念前提(一) :
监控系统的四个基础功能
以监控系统的主体而言
使用/管理者所关注的被监控"系统”(端）的相关组件，例如路由器、交换机、网关、应用、基础设施服务、业务特征等
3、基础/逻辑概念(二) :
但以上对象必须允许在基础设施层，例如物理主机、vm、container
那么我们就需要对这些基础设施层中关键的，伴随时间变化而变化的数据，进行采集分析，而此类数据称之为【指标】

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

6、满足布尔值表达式的要求（true）的指标我们认为时异常指标，而此时我们就可以通过触发一种"媒介”(media)，把异常信息通知给用户，例如钉钉、webchat、短信、邮件等等此为

小结:
指标数据采集—》样本数据存储—》可视化展示—》指标数据过滤—》异常指标判断—》告警通知——》用户

二、运维监控平台设计思路（什么层面的监控)
1.数据收集模块
2.数据提取模块
3.监控告警模块
可以细化为6层

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

三、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信息

③应用层监控
用于衡量应用程序代码状态和性能
#监控的分类#:黑盒监控，白盒监控( promtheus)
PS:
白盒监控，自省指标（可自己产生指标，自治功能），等待被获取白盒监控支持通过三种途径从目标抓取(scrape）指标数据，如下:
exporters:指标暴露器，（当服务不支持pro格式，借助于exporter来响应给pro
instumentation :测量系统，指的是应用程序内置本身兼容pro采集格式的指标暴露器
pushgateway:短期、批处理任务，本身此类业务不会产生指标数据，同时难于使用exporter来获取指标数据的任务
以上为pro典型的采集数据的方式

黑盒指标:基于探针的监控方式，不会主动干预、影响数据

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