promethus基本信息（一）

一、promethus简介

谷歌的内部大型集群系统博如果，是kubernetes的前身。其监控系统是Promethus。而Promethus是其克隆版，所以非常契合K8s的监控，对容器非常适用。

Promethus是一套开源的监控、报警、时间序列、数据库的组合采集的样本，以时间序列的方式保存在内存（TSDB时序数据库）中，并定时保存到硬盘中（以持久化的方式）时序数据库不属于SQL数据库也不是NOSQL数据库。

1、Pomeranian的特点

1. 自定义多为数据模型（时序列数据由metric名和一组key/value标签组成）
2. 非常高效的储存平均一个采样数据占大约3.5Bytes左右。例如：320万的时间序列，每30秒采样，保持60天，大约需要消耗228G的磁盘空间
3. 在多维上灵活且强大的查询语句（promSQL）
4. 不依赖分布式储存，支持单主节点工作
5. 通过基于HTTP的pull方式采集时序数据
6. 可以通过push gateway进行时序列数据库推送（pushing）
7. 可以通过服务发现或静态配置去获取要采集的目标服务器
8. 多种可视化图表及仪表盘支持

2、适用场景

Promethus可以很好的记录任何纯数字时间序列。它既适用于以机器为中心的监视，也适用于高度动态的面向服务的体系结构的监视。在微服务中，它对多维数据收集和查询的支持是一种特别的优势。（K8s）

Promethus是为可靠性而设计的，它是一种服务中断期间要使用的系统，可以快速诊断问题。

每个Promethus服务器都是独立的，而不依赖于网络存储或者其他的远程服务。当Promethus挂掉的时候，会先将挂掉的原因书写一个日志，用户可以直接根据日志信息去排除故障重启Promethus。

3、不适用场景

Promethus不适合是用于一些精准性需求很高的场合

例如：需要精准度100%的计费系统中，Promethus可能会导致数据并不是足够的详细以及完整。

二、常用监控简介

1、几个常见的监控服务

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、agent、ping。端口监视等方式提供对远程服务器/网络状态的监视，数据收集等功能，他可以运行在linux，solaris-ux，ATX，Free BSD，Open BSD，os x等平台上

4. Prometheus
   borg. kubernetes
   borgmon (监控系统)对应克隆的版本: prometheus (go语言)

   所以prometheus特别适合K8S的架构上

   而作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提 交和7200个拉取请求

   Prometheus具有以下特性:
   SQL、NOSQL、TSDB（时序数据，强制来说，这个也属于非关型数据库）

node节点在1h之内cpu使用率得变化

1. 多维的数据模型(基于时间序列的Key、value键值对)

以key是横轴，value为纵轴组成一个时序数据，多个时序数据，组成的一个趋势图（时间序列）（如下图，虽然画的简陋，但是也可以理解一下，横轴是key（时间轴），纵轴是value（数值轴），同一时刻，一个key可以对应一个或者多个value（数值），这一个点，就被称为时间数据。数据会随着时间的推移而改变，所以，就慢慢的往后就会发生变化，多个时间数据组成一个时间序列（可以理解为一个曲线））

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BXW19sBN-1644678519839)(D:\图片\image-20220212225842190.png)]

2. 灵活的查询和聚合语言PromQL
   1. 先确定时间，再确定是那台主机
3. 提供本地存储和分布式存储
4. 通过基于HTTP和HTTPs的Pull模型采集时间序列数据 ：（pul1数据的推送，时间序列:每段时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图）
5. 可利用pushgateway：(Prometheus的可选中间件)实现Push模式(只会对脚本执行或者一 次性/短周期执行的任务，或者不是使用第七层暴露的方式，使用push方式)
6. 可通过动态服务发现或静态配置发现目标机器(通过consul自动发现和收缩)（静态是方便的，一次性的，不会自动更新监控组中新增的或者认为终端的服务器）（动态是可以实时的更新新增的服务器）
7. 支持多种图表和数据大盘（收集数据之后可支持多种类型展示）

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

1. 数据收集模块
   1. 收集数据的对象，收集数据的方式
2. 数据提取模块 （prometheus-TSDB查询语言是PromQL）
   1. 将大量数据中的不需要的数据进行提取，将不需要的丢弃
3. 监控告警模块 （布尔值表达式判断是否需要告警PromQ (CPU使用率) > 80%）
   1. 进行判断，是否成立，成立就报警，不成立继续监控

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

四、promethus监控体系

1、监控体系（监控指标）

1. 系统层监控（三类或者以下四类都可以）

   1. cpu、load、memory、swap、disk I/O、process等。
   2. 网络监控：网络设备、工作负载、网络延迟、丢包率等

2. 中间件及基础应用监控（可选可不选）

   1. 消息中间件：kafka、RocketMQ、RabbitMQ等消息代理（redis 中间件）

   2. WEB（应用）服务器：tomcat、weblogic、apache、php、spring系列

   3. 数据库/缓存数据库：MYSQL、PostgreSQL、MogoDB、es、redis等：

      1. redis中需要监控的内容：

         • redis所在服务器的系统层监控
         • redis服务状态
         • RDB AOF日志监控

         ​ 日志，如果是哨兵模式，则会哨兵共享集群信息，产生日志，该日志直接包含有其他节点哨兵信息及redis信息

      2. key的数量

         key被命中的数据/次数

         连接系统和redis的最大连接数

         系统：ulimit -a

         redis： reids-cli登录，再 config get maxclients 查看最大连接数

   4. 监控指标：如何选择所需要监控的指标？

      数据流向方面：

      ​ 监控服务之间的对接：服务的数据流向

      ​ 监控端口、模块、API之间的对接：业务的数据流向

      ​ 监控端口、设备之间的对接：网络层面的流量/数据的流向

   5. 指标的选择方向

      1. 主机层面的监控的指标选择：一般是服务器中影响应用状态的一些指标的数据，比如（硬件方面的，CPU、网络、I/O、内核、磁盘、最大文件打开数、文件描述符、socket等）
      2. 网络方面指标的选择方向：，在架构中，内外网、网络流量数据，以及延迟、丢包、效率性能、端口队列、socket的数据指标
      3. 业务层面指标的选择方向：在业务数据流向/数据链路线进行最终加农，API接口数据流向、个性化的数据流向的监控（业务测、体验感、稳定/安全性、这些都是运维体系中需要进行监控的指标）
      4. 应用层方面的指标选择方向：示例：监控mysql中表的数量、总表的记录航，select语句数量、insert数量、慢查询语句、错误日志、主从日志、服务内的内存、死锁状态、打开的线程数量、socket、文件描述符。其他应用需要监控的方向也是差不多，但有些许差异。

3. 应用层监控

   1. 用于衡量应用程序代码状态和性能
   2. 监控分类：黑盒监控、白盒监控
      1. 黑盒监控：基于探针的监控方式，不会主动干预，影响数据
      2. 白盒监控：自省指针，等待被下载（cudvisoc）

4. 业务层监控

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