Prometheus介绍
目录
一、常用监控简介
1.1 cacti
1.2 Nagios
1.3 Zabbix
1.4 Prometheus
二、运维监控平台设计思路
三、Prometheus 概述
3.1 什么是Prometheus
3.2 Prometheus特点
3.3 使用场景
3.4 不适合的场景
四、Prometheus监控体系
4.1 系统层监控（需要监控的数据）
4.2 中间件及基础设施类监控
4.3 应用层监控
4.4 业务层监控
4.5 硬件层面监控
五、prometheus时间序列数据
5.1 数据来源
5.2 收集数据
5.3 prometheus(获取方式)
六、Prometheus的生态组件
七、prometheus工作原理
7.1 prometheus工作模式
7.2 prometheus工作流程
7.3 prometheus的局限性
一、常用监控简介
1.1 cacti
- Cacti(英文含义为仙人掌〉是一套基于 PHP、MySQL、SNMP和 RRDtool开发的网络流量监测图形分析工具。
- 它通过snmpget来获取数据，使用RRDTool绘图，但使用者无须了解RRDTool复杂的参数。它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP 结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。
- Cacti
- 通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能)
1.2 Nagios
- Nagios是一款开源的免费网络监视工具，能有效监控windows、Linux和Unix的主机状态，交换机路由器等网络设置打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
- nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文本配置的，不支持web方式管理和配置，这样很容易出错，不宜维护。
1.3 Zabbix
- 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监控模式、多套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告警需要使用alter manager组件
- Database storage:存储配置信息以及收集到的数据
- web Interface: Zabbix的GUI接口，通常与server运行在同一台机器上
- Proxy:可选组件，常用于分布式监控环境中，一个帮助zabbix Server收集数据，分担zabbix Server的负载的程序
- Agent:部署在被监控主机上，负责收集数据发送给server
1.4 Prometheus
- borg.kubernetes
- borgmon(监控系统) 对应克隆的版本：prometheus(go语言)
- 所以prometheus 特别适合K8S 的架构上
- 而作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提交和7200个拉取请求
二、运维监控平台设计思路
1.数据收集模块
2.数据提取模块（prometheus-TSDB,查询语言是promQL）
3.监控告警模块（布尔值表达式判断是否需要告警，不成立是健康状态）
可以细化为6层
第六层: 用户展示管理层 同一用户管理、集中监控、集中维护
第五层: 告警事件生成层 实时记录告警事件、形成分析图表（趋势分析、可视化)
第四层: 告警规则配置层 告警规则设置、告警伐值设置
第三层: 数据提取层 定时采集数据到监控模块
第二层: 数据展示层 数据生成曲线图展示（对时序数据的动态展示）
第一层: 数据收集层 多渠道监控数据
三、Prometheus 概述
3.1 什么是Prometheus
Prometheus 是一个开源的服务监控系统和时序数据库，其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的自标中进行拉取数据，当新拉取到的数据大于配置的内存缓存区时，数据就会持久化到存储设备当中。
- 每个被监控的主机都可以通过专用的exporter 程序提供输出监控数据的接口，它会在目标处收集监控数据，并暴露出一个HTTP接口供Prometheus server查询，Prometheus通过基于HTTP的pull的方式来周期性的采集数据。
- 任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示，监控目标可以通过配置信息以静态形式指定，也可以让Prometheus通过服务发现的机制进行动态管理。
- Prometheus 能够直接把API Server作为服务发现系统使用，进而动态发现和监控集群中的所有可被监控的对象。
官网：Data model | Prometheus
3.2 Prometheus特点
-
自定义多维数据模型（时序列数据由metric名和一组key/value标签组成）
-
非常高效的储存平均一个采样数据占大约3.5bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G
-
在多维上灵活且强大的查询语句（PromQL）
-
不依赖分布式储存，支持单主节点工作
-
通过基于HTTP的pull方式采集时序数据
-
可以通过push gateway进行时序列数据库推送（pushing）
-
可以通过服务发现或静态配置去获取要采集的目标服务器
-
多种可视化图表及仪表盘支持
3.3 使用场景
-
Prometheus可以很好地记录任何纯数字时间序列。它既适用于以机器为中心的监视，也适用于高度动态的面向服务的体系结构的监视。在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。（k8s）
-
Prometheus是为可靠性而设计的，它是您在中断期间要使用的系统，可让您快速诊断问题。每个Prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您可以依靠它，并且无需设置广泛的基础结构即可使用它
3.4 不适合的场景
普罗米修斯重视可靠性。即使在故障情况下，您始终可以查看有关系统的可用统计信息。如果您需要100%的准确性（例如按请求计费)，则Prometheus并不是一个不错的选择，因为所收集的数据可能不会足够详细和完整。在这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余的监视。
四、Prometheus监控体系
4.1 系统层监控（需要监控的数据）
- CPU、Load、Memory、swap、disk、I/O、process等
- 网络监控：网络设备、工作负载、网络延迟、丢包率等
4.2 中间件及基础设施类监控
- 消息中间件：kafka、RocketMQ、等消息代理（redis 中间件）
- WEB服务容器：tomcat、weblogic、apache、php、spring系列
- 数据库/缓存数据库：Mysql、Postgresql、MongoDB、es、redis
redis监控内容
- redis的服务状态
- redis所在服务器的系统层监控
- RDB和AOF日志监控
日志--->如果是哨兵模式--->哨兵共享集群信息，产生的日志
--->直接包含的其他节点哨兵信息及redis信息
- key的数量
- key被命中的数据/次数
- 最大连接数--->redis和系统
- redis:redis-cli登录--->config get maxclients查看最大连接
4.3 应用层监控
用于衡量应用程序代码状态和性能
监控的分类：
- 白盒监控：自省指标，等待被下载（cadvisor）
- 黑盒监控：基于探针（snmp）的监控方式，不会主动干预、影响数据
4.4 业务层监控
- 用于衡量应用程序的价值。如电商业务的销售量，ops、dau日活、转化等
- 业务接口：登入数量，注册数、订单量、搜索量和支付量
4.5 硬件层面监控
- 交换机 路由器 服务器CPU温度 空气污染值
五、prometheus时间序列数据
时序数据，是在一段时间内通过重复测量(measurement）而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据;
5.1 数据来源
-
prometheus基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口）上周期性获取指标数据。
-
很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，prometheus-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式）
5.2 收集数据
-
监控概念 : 白盒监控、黑盒监控
白盒监控: 自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可（例如cadvisor）PS:被监控端自身可产出指标数据，且监控服务可直接来抓取的监控类型，我们叫做内建的指标暴露器 （指标暴露器：exporter把系统的数据原本无法通过http展示出来的数据，转化成http方式暴露出来，给prometheus来抓取，这种exporter类型的服务，或者代理，我们其实会称为指标暴露器）
（指标：类似cpu使用率 cpu空闲率）
黑盒监控: 对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议）
-
Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控);
Exporters ——>工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送 Instrumentation ——>指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取 Pushgateway ——>短周期5s—10s的数据收集
5.3 prometheus(获取方式)
-
Prometheus同其它TSDB相比有一个非常典型的特性: 它主动从各Target上拉取(pull)数据，而非等待被监控端的推送 (push)
-
两个获取方式各有优劣，其中，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，而pro内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus 采集过后，会存储在自己内建的TSDB数据库中，提供了promQL 支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具（grafana）来展示数据
采集、抓取数据是其自身的功能，但一般被抓去的数据一般来自于:
export/instrumentation （指标数据暴露器） 来完成的，或者是应用程序自身内建的测量系统（汽车仪表盘之类的，测量、展示）来完成
5、Alertmanager: 由告警规则对接，从Prometheus Server接收到"告警通知"后，通过去重、分
组、路由等预处理功能后以高效向用户完成告警信息发送
6、Data Visualization（Dashboards）: 与TSDB对接并且展示数据库中的数据，Prometheus web UI (Prometheus Server内建)，及Grafana等;
7、Service Discovery: 动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用;该组件目前由PropetheusServer内建支持
七、prometheus工作原理
7.1 prometheus工作模式
- Prometheus Server 基于服务发现（Service Discovery）机制或静态配置获取要监视的目标（Target），并通过每个目标上的指标exporter来采集（Scrape）指标数据；
- Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据，用户可使用PromQL接口来检索数据，也能够按需将告警需求发往A1ertmanager完成告警内容发送；
- 一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到Server端，它们一般会采用推送（Push）方式输出指标数据，Prometheus借助于Pushgateway 接收这些推送的数据，进而由server端进行抓取
7.2 prometheus工作流程
- Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
- Prometheus server 把采集到的监控指标数据通过TSDB存储到本地HDD/ssD中。
- Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager。
- Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
- Prometheus 自带的Web UI 界面提供PromQL 查询语言，可查询监控数据。
- Grafana 可接入Prometheus 数据源，把监控数据以图形化形式展示出。
ps:告警数据采集、告警信息提取、告警通知
1、首先，需要采集监控数据，pro会周期性的pull或被push指标数据，数据采集的方式主要包括exporters、instrumentation、pushgateway 3种方式，前两者为pull方式获取，pushgateway借助于push方式推送给prometheus。
2、根据prometheus配置文件中（K8S-configmap的配置种），获取被监控端的数据之后，保存在TSDB中，我们可以借助Grafana或者告警平台来展示数据，grafana的展示是通过PromQL来获取数据。
3、prometheus通过rule配置来借助于PromQL来定义布尔值表达式，产生告警信息
4、一旦出现告警，prometheus产生告警信息，发送给alertmanager,alertmanager根据自定义的告警路由，来进行告警通知，对接第三方平台，例如告警平台、邮件、钉钉。7.3 prometheus的局限性
- Prometheus是一款指际监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据；
- Prometheus认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储；若需要存储长期的历史数据，建议基于远端存储机制将数据保存于InfluxDB或openTsDB等系统中；
- Prometheus的集群机制成熟度不高，可基于Thanos（和灭霸是一个单词）实现Prometheus集群的高可用及联邦集群