一、常用监控简介

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能监视各种网络参数，保证服务器系统的安全运营；并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题

3.1 zabbix的构成

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

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）是独立的板卡，独立供电

3.2 zabbix的优点和缺点

优点
zabbix解决了cacti没有告警的不足，也解决了nagios不能通过web配置的缺点，同时还支持分布式部署，这使得它迅速流行起来，zabbix也称为目前中小企业监控最流行的运维监控平台‘

缺点
zabbix也有不足之处，它消耗的资源比较多，如果监控的主机非常多时（服务器数量超过500台），可能会出现监控超时，告警搞事、告警系统单点故障等现象，不过也有很多解决办法，比如提高硬件性能、改变zabbix监控模式、多套zabbix等

3.3 zabbix核心组件介绍

Zabbix server：zabbix软件实现监控的核心程序，主要功能是与zabbix proxies和agents进行交互、触发器计算、发送告警通知；并将数据集中保存。与prometheus的类似，可以保存收集到的数据，但是prometheus告警需要使用alter manager组件
Database storage：存储配置信息以及收集到的数据
web interface：Zabbix的GUI接口，通常与server运行在同一台机器上
Proxy：可选组件，常用于分布式监控环境中，一个帮助zabbix server收集数据，分担zabbix server的负载的程序
Agent：部署在被监控主机上，负责收集数据发送给server

二、Prometheus概述

1.什么是Prometheus

Prometheus是一个开源的服务监控系统和时序数据库，其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉取数据，当新拉取到的数据大于配置的内存缓存区时，数据就会持久化到存储设备当中

• 每个被监控的主机都可以通过专用的exporter程序提供输出监控数据的接口，它会在目标处收集监控数据，并暴露出一个HTTP接口供Prometheus server查询，Prometheus通过基于HTTP的pull的方式来周期性的采集数据
• 任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示，监控不表可以通过配置信息以静态形式指定，也可以让Prometheus通过服务发现的机制进行动态管理
• Prometheus能够直接把API Server作为服务发现系统使用，进而动态发现和监控集群中的而所有可被监控的对象

Prometheus 官网地址：https://prometheus.io
Prometheus github 地址：https://github.com/prometheus

2.Zabbix和Prometheus区别

• 和Zabbix乐视，Prometheus也是一个今年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂
• Zabbix的客户端agent可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而Prometheus的上报客户端则分为不同语言的SDK和不同用途的exporter两种，比如如果你要监控机器状态、MySQL性能等，有大量已经成熟的exporter来直接开箱使用，通过HTTP通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集
• zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据
• 界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路

3.Prometheus的特点

• 自定义多维数据模型（时序列数据由metric（度量）名和一组key/value（键值对）标签组成）
  • 时序数据，是一段时间内通过重复测量而获得的观测值的集合；将这些观测值绘制与图形之上，它会有一个数据轴和时间轴
• 内置时间序列数据库：Prometheus；外置的远端存储通常会用：InfluxDB、openTSDB等
• PromQL一种灵活的查询语言，可以利用多维数据完成复杂查询
• 通过HTTP的pull方式采集时序数据
• 通过push gateway进行时序数据库推送（pushing）
• 通过服务发现或静态配置去获取要采集的目标服务器
• 支持多种可视化图标及仪表盘支持

4.Prometheus使用场景及不适合场景

使用场景

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

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

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

• 数据收集模块
• 数据提取模块
• 监控告警模块

可以细化为6层

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

四、Prometheus监控体系

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

• CPU、Load、Memory、swap、disk I/O、process等
• 网络监控：网络设备、工作负载、网络延迟、丢包率

2.中间件及基础设施类监控

• 消息中间件：kafka、RocketMQ、等消息代理
• WEB服务器容器：tomcat
• 数据库/缓存数据库：MySQL、PostgreSQL、MogoDB、es、redis

redis监控内容

• redis所在服务器的系统层监控
• redis服务状态
• RDB AOF日志监控
• 日志→如果是哨兵→哨兵共享集群信息，产生的日志→直接包含其它节点哨兵信息及redis信息

3.应用层监控

用于衡量应用程序代码状态和性能

监控的分类：

• 白盒监控：自省指标，等待被下载（cadvisor）
• 黑盒监控：基于探针（snmp）的监控方式，不会主动干预、影响数据

4.业务层监控

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

五、Prometheus时间序列数据

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

1.时序数据特点

• 性能好：关系型数据库对于大规模数据的处理性能糟糕。NOSQL可以比较好的处理大闺蜜数据，但依然比不上时间序列数据库
• 存储成本低：高效的压缩算法，节省存储空间，有效降低I/O

Prometheus有着非常高效的事件序列数据存储方法，每个采样数据仅仅占用3.5byte左右空间，上百万条事件序列，30秒间隔，保留60天，大概200多G（来自官方数据）

2.数据来源

Prometeus基于HTTP call（http/https请求），从配置文件中指定的网络端点（endpoint/IP:端口）上周期性获取指标数据。

很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，prometheus-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为promrtheus可识别，可使用的数据（兼容模式）

3.收集数据

监控概念：白盒监控、黑盒监控

• 白盒监控：自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可
• 黑盒监控：对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议）

Prometheus支持通过三种类型的途径从目标上"抓取（Scrape）"指标数据（基于白盒监控）

• Exporters：工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送
• Intrumentation：指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
• Push gateway：短周期5s-10s的数据收集

4.prometheus获取方式

Prometheus同其它TSDB相比有一个非常典型的特性：主动从Target上拉取（pull）数据，非等待被监控端的推送（push）

两个获取方式各有优劣，其中，pull模型的优势在于：

• 集中控制：有利于将配置集在Prometheus server上完成，包括指标及采取速率等；
• Prometheus的根本目标在于收集在target上预先完成聚合性数据，而非一款由事件驱动的存储系统通过targets（标识的是具体被监控端）
• 比如配置文件中的targets:[‘localhost:9090’]

六、Prometheus的生态组件

Prometheus负责时序性指标数据的采集及存储，但数据的分析、聚合及直观展示以及告警等功能并非由Prometheus Server所负责

1.Prometheus server

Prometheus server：服务核心组件，采取pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server由3各部分组成：Retrival，Storage，PromQL

• Retrival：负责在活跃的target主机上抓取监控指标数据
• Storage：存储，主要是把采集到的数据存储到磁盘中。默认为15天（可修改）
• PromQL：是Prometheus提供的查询语言模块

2.Push gateway

Push gateway：类似一个中转站，Prometheus的server端只会使用pull方式拉取数据，但是某些节点因为某些原因只能使用push方式推送数据，那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Push gateway，然后Prometheus server同一从Push gateway拉取数据

3.exporter

Exporter：指标暴露器，负责收集不支持内奸Instrumentation的应用程序或服务的性能指标数据，并通过HTTP接口供Promentheus server获取。换句话说，Exporter负责从目标应用程序上采集和聚合原始格式的数据，并转换为Prometheus格式的指标向外暴露

常见的Exporters：

• Node-Exporter：用于收集服务器节点（例如K8s）的物理指标状态数据，如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据，需要部署到所有运算节点。指标详细介绍：https://github.com/prometheus/node_exporter
• mysqld-exporter/nginx-exporter
• Kube-state-Metrics：为prometheus 采集k8s资源数据的exporter，通过监听APIServer 收集kubernetes集群内资源对象的状态指标数据，例如pod、deployment、service 等等。同时它也提供自己的数据，主要是资源采集个数和采集发生的异常次数统计。

需要注意的是kube-state-metrics 只是简单的提供一个metrics 数据，并不会存储这些指标数据，
所以可以使用prometheus来抓取这些数据然后存储，主要关注的是业务相关的一些元数据，
比如Deployment、Pod、副本状态等；调度了多少个replicas？现在可用的有几个？
多少个Pod是running/stopped/terminated 状态？Pod 重启了多少次？有多少job在运行中。

• cadvisor：用来监控容器内部使用资源的信息，比如CPU、内存、网络I/0、磁盘I/0。
• blackbox-exporter：监控业务容器存活性

4、Service Discovery

Service Discovery：服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。

服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持

5、Alertmanager

Alertmanager：是一个独立的告警模块，从Prometheus server端接收到“告警通知”后，会进行去重、分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件、钉钉、企业微信等。

1、Prometheus Server 仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责；
2、告警指示由 Prometheus Server基于用户提供的告警规则周期性计算生成，Alertmanager 接收到Prometheus Server发来的告警指示后，基于用户定义的告警路由向告警接收人发送告警信息。

6、client Library

client Library：客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。

7、grafana

Grafana：是一个跨平台的开源的度量分析和可视化工具，可以将采集的数据可视化的展示，并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。

Prometheus数据流向

1. Prometheus server定期从配置好的jobs或者exporters中拉取metrics，或者接收来自 Pushgateway发送过来的metrics，或者从其它的Prometheus server中拉metrics。
2. Prometheus server在本地存储收集到的metrics，并运行定义好的alerts.rules，记录新的时间序列或者向Alert manager推送警报。
3. Alertmanager根据配置文件，对接收到的警报进行处理，发出告警。
4. 在图形界面中，可视化采集数据

七、prometheus工作原理

1.prometheus工作模式

1、Prometheus Server 基于服务发现（Service Discovery）机制或静态配置获取要监视的目标（Target），并通过每个目标上的指标exporter来采集（Scrape）指标数据；
2、Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据，用户可使用PromQL接口来检索数据，也能够按需将告警需求发往A1ertmanager完成告警内容发送；
3、一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到Server端，它们一般会采用推送（Push）方式输出指标数据，Prometheus借助于Pushgateway 接收这些推送的数据，进而由server端进行抓取

2.promrtheus工作流程

1、Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
2、Prometheus server 把采集到的监控指标数据通过TSDB存储到本地HDD/ssD中。
3、Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager。
4、Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
5、Prometheus 自带的Web UI 界面提供PromQL 查询语言，可查询监控数据。
6、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根据自定义的告警路由，来进行告警通知，对接第三方平台，例如告警平台、邮件、钉钉。

3.prometheus的局限性

• Prometheus是一款指际监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据；
• Prometheus认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储；若需要存储长期的历史数据，建议基于远端存储机制将数据保存于InfluxDB或openTsDB等系统中；
• Prometheus的集群机制成熟度不高，可基于Thanos（和灭霸是一个单词）实现Prometheus集群的高可用及联邦集群

总结

1、prometheus如何收集k8s/服务的–三种方式收集

Exporters（指标暴露器）：收集节点的信息、将数据格式化或转化为promtheus可识别的http这种转化方式/镜像拉取方式
Instrumentation （应用内置的指标暴露器）： 收集有内置指标暴露器的信息
Pushgateway ： 收集短周期的数据

2 、如何防止告警信息轰炸

alertmanagr: prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件alertmanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸
把这条告警规则中的支持静默开启，让它必须，配置文件里直接改alertmanager改一个单词

3、prometheus监控什么

3.1 网络监控

• 网络性能监控：主要涉及网络监测，网络实时流量监控（网络延迟、访问量、成功率）和历史数据统计、汇总和历史数据分析等功能。
• 网络检测：主要针对内网或者外网的网络。如DDoS的。通过分析异常流量来确定网络行为。
• 设备监控：主要针对数据中心内的多种网络设备进行监控。包括路由器，防火墙和交换机等硬件设备，可以通过snmp等协议收集数据。

3.2 存储监控

• 存储性能监控方面：存储通常监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储通常监控文件系统inode。读写速度、目录权限等。
• 存储系统监控方面：不同的存储系统有不同的指标，例如，对于ceph存储需要监控OSD, MON的运行状态，各种状态pg的数量以及集群IOPS等信息。
• 存储设备监控方面：对于构建在x86服务器上的存储设备，设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，通常自带监控功能，可监控设备的运行状态，性能和容量的。

3.3 服务器监控

• CPU：涉及整个 CPU 的使用量、用户态百分比、内核态百分比，每个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等。
• 内存：涉及内存的使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常等。
• 网络 I/O：涉及每个网卡的上行流量、下行流量、网络延迟、丢包率等。
• 磁盘 I/O：涉及硬盘的读写速率、IOPS、磁盘用量、读写延迟等。

3.4 中间件监控

• 消息中间件： RabbitMQ Exporter、Kafka Exporter
• Web 服务中间件：Apache Exporter、Nginx Exporter
• 数据库中间件：MySQL Exporter、PostgreSQL Exporter、Redis Exporter

4、常见的时间序列数据库

5、4个黄金指标

4个黄金指标可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。主要关注与以下四种类型的指标：延迟，通讯量，错误以及饱和度：

5.1 延迟：服务请求所需时间

记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。 例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此以外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的。

5.2 通讯量：监控当前系统的流量，用于衡量服务的容量需求

流量对于不同类型的系统而言可能代表不同的含义。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数；

5.3 错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率

对于失败而言有些是显式的(比如, HTTP 500错误)，而有些是隐式(比如，HTTP响应200，但实际业务流程依然是失败的)。
对于一些显式的错误如HTTP 500可以通过在负载均衡器(如Nginx)上进行捕获，而对于一些系统内部的异常，则可能需要直接从服务中添加钩子统计并进行获取。

5.4 饱和度：衡量当前服务的饱和度

主要强调最能影响服务状态的受限制的资源。 例如，如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘I/O，那就主要观测磁盘I/O的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，比如，“磁盘是否可能在4个小时候就满了”。