本文详细介绍了Prometheus监控系统，从常用监控工具对比、运维监控平台设计思路到Prometheus的特点、生态组件、数据模型、部署过程和服务发现机制。此外，还探讨了Prometheus的告警功能、Grafana的部署以及如何对接邮件告警，为读者提供了一个全面的Prometheus监控体系视图。
目录
6、Data Visualization (Dashboards)
5、prometheusQL（数据查询语言也是时序数据库使用语言)
一、常用监控简介
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监控模式等。
（1）agent代理:专门的代理服务方式进行监控，专属的协议，装有zabbix-agent的主机就可以被zabix-server监控，主动或被动的方式，把数据给到server进行处理。
（2）ssh/telent: linux主机支持ssh/telent协议
（3）snmp:网络设备路由器、交换机不能安装第三方程序(agent），使用简单网络协议。大多数的路由器设备支持SNMP协议
（4）ipmi:通过ipmi接口进行监控，我们可以通过标准的ipmi硬件接口，监控被监控对象的物理特征，比如电压，温度，风扇状态电源情况，被广泛使用服务监控中，包括采集cpu温度，风扇转速，主板温度，及远程开关机等等，而且ipmi独立于硬件和操作系统，无论是cpu，bios还是os出现故障，都不会影响ipmi的工作，因为ipmi的硬件设备BMC( bashboard management controller）是独立的板卡，独立供电。
（5）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、监控层面
（1）数据收集模块
（2）数据提取模块（prometheus-TSDB查询语言时PromQL）
（3）监控告警模块（布尔值表达式判断是否需要告警PromQL（CPU使用率）>80%）
2、细化为6层监控
第六层:用户展示管理层 同一用户管理、集中监控、集中维护
第五层:告警事件生成层 实时记录告警事件、形成分析图表（趋势分析、可视化)
第四层:告警规则配置层 告警规则设置、告警伐值设置（定义布尔值表达式，筛选异常状态）
第三层:数据提取层 定时采集数据到监控模块
第二层:数据展示层 数据生成曲线图展示（对时序数据的动态展示)
第一层:数据收集层 多渠道监控数据（网络，硬件，应用，数据，物理环境）
三、Prometheus监控体系
1、系统层监控（需要监控的数据)
（1）CPU、Load、Memory、swap、disk i/o、process等
（2）网络监控：网络设备、工作负载、网络延迟、丢包率等
2、中间件及基础设施类监控端监控（移动APP、特定程序等)
（1）消息中间件:kafka、RocketMQ、等消息代理
（2）WEB服务器容器:tomcat、weblogic、apache、php、spring系列
（3）数据库/缓存数据库:MysQL、PostgresQL、MogoDB、es、redis
redis监控内容：reids所有服务器的系统层监控；redis服务状态；RDB AOF日志监控（日志：如果是哨兵模式，哨兵共享集群信息，产生的日志，直接包含的其他节点哨兵信息及redis信息）
key的数量：key被命中的数据/次数，最大连接数（redis：redis-cli登录，config get maxclients查看最大连接和系统：ulimit -a）
3、应用层监控
用于衡量应用程序代码状态和性能，其中监控的分类为黑盒监控，白盒监控( promtheus)。
（1）白盒监控，自省指标（可自己产生指标，自治功能），等待被获取白盒监控支持通过三种途径从目标抓取(scrape）指标数据，如下:
①exporters：指标暴露器，（当服务不支持pro格式，借助于exporter来响应给prometheus)；
②instumentation：测量系统(被监控端)，指的是应用程序内置本身兼容pro采集格式的指标暴露器；
③pushgateway：短期、批处理任务，本身此类业务不会产生指标数据，同时难于使用exporter来获取指标数据的任务，pushgateway 将以上短期的业务指标数据，收集到网关处，然后定期crontab推送给pro-server。
以上为pro典型的采集数据的方式
（2）黑盒指标:基于探针的监控方式，不会主动干预、影响数据
4、业务层监控
用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，业务接口：登入数量，注册数、订单量、搜索量和支付量。
四、Prometheus简介
谷歌的内部大型集群系统borg，是kubernetes的前身。其监控系统是borgmon，而iprometheus是其克隆版，所以非常契合k8s的监控对容器非常适用。
Prometheus本身为一种时序数据库(TSDB)，还具备开源的监控、报警、时间序列、数据库的组合。其设计用于进行目标(target）监控的关键组件。
TSDB：pro通过采集的样本以时间序列的方式保存在内存（TSDB时序数据库）中并定时保存到硬盘（持久化)
target：主要指可输出、产生指标数据的组件/对象，包括但不限于主机、应用、服务、K8S ingress(逻辑组件)等，能正常输出指标数据的对象称为target或网络端点（表现形式，例如:192.168.32.11:9100,192.168.32.11:8500)
时序数据：一段时间内通过重复测量而获得的观测值的集合，并且可将这些观测值绘制与图形之上，以数据轴（纵轴〉和时间轴（横轴）来表示随着时间流逝而产生的"渐变"变化（类似与股票)
小结：能随着时间流逝，而能不断采集到的点数据称为时序数据，时序数据库不属于sql数据库也并不是nosql数据库。
1、Prometheus特点
（1）自定义多维数据模型（时序列数据由metric名和一组key/value标签组成)；
（2）非常高效的储存平均一个采样数据占大约3.5.bytes左右，320万的时间序列，每30秒采样，默认保持60天，消耗磁盘大概228G；
（3）在多维上灵活且强大的查询语句( PromQL)；
（4）不依赖分布式储存，支持单主节点工作；
（5）通过基于HTTP的pull方式采集时序数据；
（6）可以通过push gateway进行时序列数据库推送(pushing）；
（7）可以通过服务发现或静态配置去获取要采集的目标服务器（server discover）；
（8）多种可视化图表及仪表盘支持。
2、使用场景
Prometheus可以很好地记录任何纯数字时间序列。它既适用于以机器为中心的监视，也适用于高度动态的面向服务的体系结构的监视。在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。(云原生，k8s)
Prometheus是为可靠性而设计的，它是您在中断期间要使用的系统，可让您快速诊断问题。每个Pronetheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您可以依靠它，并且无需设置广泛的基础结构即可使用它。
3、不适合的场景
普罗米修斯重视可靠性。即使在故障情况下，您始终可以查看有关系统的可用统计信息。如果您需要100%的准确性（例如按请求计费)，则Prometheus并不是一个不错的选择，因为所收集的数据可能不会足够详细和完整。在这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余的监视。
五、prometheus时序数据
时序数据，是在一段时间内通过重复测量(measurement）而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据。
1、数据来源
（1）prometheus基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口)上周期性获取指标数据。
（2）很多环境、被监控对象，本身是没有直接响应处理http请求的功能，promethens-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式)。2、收集数据
（1）监控概念：白盒监控、黑盒监控
（2）白盒监控：自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可
（3）黑盒监控：对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议)
（4）Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控)
①Exporters：工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送
②Instrumentation：指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
③Pushgateway：短周期5s-10s的数据收集脚本
2、prometheus（获取方式）
（1）Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据，而非等待被监控端的推送(push)
（2）两个获取方式各有优劣，其中，Pull模型的优势在于
①集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等；
②Prometheus的根本目标在于收集在rarget上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统通过targets(标识的是具体的被监控端)，比如配置文件中的targets : [ ‘localhost:9090’]
六、prometheus生态组件
prometheus生态圈中包含了多个组件，其中部分组件可选
1、Prometheus server
收集和储存时间序列数据，通过scraping以刮擦的方式去获取数据放入storge (TSDB时序数据库），制定Rules/Alerts:告警规则，service discovery是自动发现需要监控的节点时间序列数据，按照事件推移，在某一个时间刻度，同一个样本数据采集的时间不会绝对的一致，会随机延迟或提前一点进行采集。
2、client Library
客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径。
3、Push Gateway
接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作。
4、Exporters
用于暴露现有应用程序或服务（不支持Instrumentation)的指标给Prometheus Server）而prometheus内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus采集过后，会存储在自己内建的TSDB数据库中，提供了promQL支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具( grafana）来展示数据采集、抓取数据是其自身的功能，但一般被抓去的数据一般来自于:export/instrumentation(指标数据暴露器）来完成的，或者是应用程序自身内建的测量系统（汽车仪表盘之类的，测量、展示）来完成。
5、Alertmanager
由告警规则对接，从Prometheus Server接收到"告警通知"后，通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送。
6、Data Visualization (Dashboards)
与TSDB对接并且展示数据库中的数据，Prometheus web UI (Prometheusserver内建)，及Grafana等。
7、service
Discovery:动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用;该组件目前由PropetheusServer内建支持
8、架构图
（1）prometheus-server
retrieval(获取数据pull/discover），TSDB存储，HTPserver控制台接口，内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus采集过后，会存储在自己内建的TSDB数据库中(默认为2个月时间))，提供了prompL支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析
最低0.47元/天 解锁文章
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
