Prometheus + grafana

一、常规监控简介

1、Cacti

Cacti (英文含义为仙人掌)是一套基于PHP、 MySQL、 SNMP和RRDtoo1开发的网络流量监测图形分析工具。
它通过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, HP-UX,
AIX， Free BSD， Open BSD， OS X等平台上。
zabbix解决了cacti没有告警的不足，也解决了nagios不能通过web配置的缺点，同时还支持分布式部署，这使得它迅速流行起来，zabbix也成为目前中小企业监控最流行的运维监控平台。
当然，zabbix也有不足之处，它消耗的资源比较多，如果监控的主机非常多时(服务器数量超过500台)，可能会出现监控超时、告警超时、告警系统单点故障等现象，不过也有很多解决办法，比如提高硬件性能、改变zabbix监控模式等。

Zabbix-》核心组件

Zabbix监控组件主要包括：Zabbix Server、Zabbix Proxy、Zabbix Agent；
其中Zabbix Server包括：Web GUI、Database、Zabbix Server。
功能： - CPU负荷、内存使用、磁盘使用、网络状况、端口监视、日志监视
kube-proxy的流量代理的三种模式：
Service能将pod的变化屏蔽在集群内部，同时提供负载均衡的能力，自动将请求流量分布到后端的pod，这一功能的实
现靠的就是kube-proxy的流量代理，一共有三种模式，userspace、iptables以及ipvs。
userspace ：由node节点随机端口，任何连接到“代理端口”的请求，都会被代理到 Service 的backend Pods 中的
某个上面（实际是根据Endpoints中，在k8s v1.2后就已经被淘汰）
iptables 代理模式：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规
则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod（版本1.2开始并在v1.12之前的默认模式）
ipvs 代理模式：类似iptables规则，在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规
则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构（版本1.8开始增加了IPVS支持）

4、Prometheus

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

Prometheus具有以下特性:
· 多维的数据模型(基于时间序列的Key、Value键值对)
· 灵活的查询和聚合语言PromQL
· 提供本地存储和分布式存储
· 通过基于HTTP的Pul1模型采集时间序列数据
· 可利用Pushgateway ( Prometheus的可选中间件)实现Push模式
· 可通过动态服务发现或静态配置发现目标机器
· 支持多种图表和数据大盘

二、监控体系:

系统层监控
1、CPU、Load、Memory、 Swap、 Disk I/0、 Process等一》5个常规负载指标
2、网络监控:网络设备、工作负载、网络延迟、丢包率等(协议)
中间件及基础设施类监控
消息中间件: Kafka、 RocketMQ、Rabbitmq等消息代理
WEB服务容器: Tomcat|
数据库/缓存数据库: MySQL、 PostgreSQL、 MogoDB、 es、 redis
存储系统: Ceph、 GFS等

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

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

三、prometheus简介

谷歌的内部大型集群系统borg
borg: kubernetes的前身
borgmon (监控系统)对应克隆的版本: prometheus (go语言)

所以prometheus特别适合K8S的架构上
Prometheus是–套开源的监控&报警&时间序列数据库的组合
采集到的样本以时间序列的方式保存在内存(TSDB 时序数据库)中，并定时保存到硬盘中

官网: https; I /prometheus . io/ docs/concepts/data model/

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

PS ; open-Falcaon
open-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案。

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

1、数据收集模块
2、数据提取模块
3、监控告警模块
可细化为“6层模型”

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

五、使用场景

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

Prometheus是为可靠性而设计的，它是您在中断期间要使用的系统，可让您快速诊断问题。每个Prometheus服务器都是独立的,而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您可以依靠它，并且无需设置广泛的基础结构即可使用它

简单说: prometheus 基础配置简单，go设计-》方便的使用
prometheus +部署多套
节点一》容器一》进程一》
容器和vm容器千万、虚拟机几十台

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

六、prometheus时序数据

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

数据来源：（HTTP方式）
prometheus基于HTTP call (http/https请求)，从配置文件中指定的网络端点( endpoint/IP:端口) 上周期性获取指标数据

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

怎么抓取/收集数据:
监控概念: 白盒监控、黑盒监控
白盒监控: 自省方式，被监控端内部，可以自已生成指标，只要等待监控系统来采集时提供出去即可
黑盒监控: 对于被监控系统没有侵入性，对其没有直接"影响”，这种类似于基于探针机制进行监控(snmp协议)

Prometheus支持通过三种类型的途径从目标上“抓取(Scrape) ”指标数据(基于白盒监控) ;
Exporters
Inst rumentation
Pushgateway

prometheus (获取方式)
Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上”拉取
(pull)”数据，而非等待被监控端的“推送(push) ";
两个方式各有优劣，其中，Pull模型的优势在于:
集中控制:有利于将配置集在Prometheus Server. 上完成，包括指标及采取速率等;
Prometheus的根本目标在于收集在Target.上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统:

七、Instrumentation ( 程序仪表)

任何能够支持Scrape指标数据的应用程序都首先要具有一个测量系统:
在Prometheus的语境中，Instrumentation是指附加到应用程序中的那些用于暴露程序指标数据的客户端库程序员借助于这些客户端库编写代码生成可暴露的指标数据;

八、Exporters

node-exporter组件，因为prometheus
抓取数据是通过http的方式调用/的，假如抓取的数据是操作系统的资源负载情况，而linux操作系统内核是没有内置任何http协议的，并不支持直接通过http方式进行，所以需要在每个被监控端安装node-exporter,由其向内核中拿取各种状态信息，然后再通过prometheus兼容的指标格式暴露给prometheus。

对于那些未内建Instrumentation,且也不便于自行添加该类组件以暴露指标数据的应用程序来说，常用的办法是于待监控的目标应用程序外部运行一个独立指标暴露程序，该类型的程序即统称为Exporter;
因为抓取数据是通过http的方式调用/的，假如抓取的数据是操作系统的资源负载情况，而1inux操作系统内核是没有内置任何http协议的，并不支持直接通过http方式进行，所以需要在每个被监控端安装node-exporter,由其向内核中拿取各种状态信息，然后再通过prometheus兼容的指标格式暴露给prometheus

PS: Prometheus站点上提供了大量的Exporter

九、alerts (告警)

异常值:不是绝对的一-》(人为根据不同的环境和场景，对于服务可以正常运行这种状态所定义一种主观判断-健康值)——抓取异常值，pro通过告警机制发现和发送警示

aler负责:告警只是pro基于用户提供“告警规则”周期性计算生成，好的监控系统，可以事先预测、并提前处理的功能
aler接受服务端发送来的告警指示，基于用户定义的告警路由(route) 向告警接收人( receivers)发送告警信息(可由用户定义)。

prometheus server

内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus
采集过后，会存储在自己内建的TSDB数据库中，提供了promQL
支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析-场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具(grafana) 来展示数据

采集、抓取数据是其自身的功能，但- -般被抓去的数据一般来自于:export/instrumentation ( 指标数据暴露器)来完成的，或者是应用程序自身内建的测量系统(汽车仪表盘之类的，测量、展示)来完成

指标类型

默认都是以双精度浮点型数据(服务端无数据量类型数据)
1、counter :计数器单调递增
2、gauge:仪表盘:有起伏特征的
3、histogram: 直方图:
在一.段时间范围内对数据采样的相关结果，并记入配置的bucket中，他可以存储更多的数据，包括样本值分布在每个bucket中的
数量，从而prometheus 就可以使用内置函数进行计算:
计算样本平均值:以值得综合除以值的数量
计算样本分位值:分位数有助于了解符合特定标准的数据个数，例如评估响应时间超过1秒的请求比例，若超过208则进行告警等
4、summary, 摘要，histogram的扩展类型，它是直接由监控端自行j聚合计算出分位数，同时将计算结果响应给prometheus
server的样本采集请求，因而，其分位数计算是由监控端完成

十、部署环境

prometheus软件包

https://prometheus.io/download/

主机        操作系统        ip地址               软件
promethus   centos 7    192.168.37.20
server1     centos 7    192.168.37.30
server2     centos 7    192.168.37.40
server3     centos 7    192.168.37.50

prometheus

[root@localhost ~]# hostnamectl set-hostname promethus
[root@localhost ~]# su
[root@promethus ~]# systemctl stop firewalld.service
[root@promethus ~]# systemctl disable firewalld.service
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@promethus ~]# setenforce 0
[root@promethus ~]# date
2021年 06月 08日 星期二 16:18:13 CST
[root@promethus ~]# ntpdate ntp.aliyun.com8 Jun 16:19:41 ntpdate[46991]: adjust time server 203.107.6.88 offset -0.002124 sec

[root@promethus ~]# rz -E
rz waiting to receive.
[root@promethus ~]# ls
anaconda-ks.cfg  initial-setup-ks.cfg  prometheus-2.27.1.linux-amd64.tar.gz[root@promethus ~]# tar zxvf prometheus-2.27.1.linux-amd64.tar.gz -C /usr/local/
[root@promethus ~]# cd  /usr/local/
[root@promethus local]# ls
bin  etc  games  include  lib  lib64  libexec  prometheus-2.27.1.linux-amd64  sbin  share  src
[root@promethus local]# cd prometheus-2.27.1.linux-amd64/
[root@promethus prometheus-2.27.1.linux-amd64]# ls
console_libraries  consoles  LICENSE  NOTICE  prometheus  prometheus.yml  promtool

server1

promethus

浏览器访问：

监控node

语句过滤

过滤标签：

#CPU使用总量(所有节点)

node_cpu_seconds_total

#CPU空闲值(所有节点)

node_cpu_seconds_total{mode='idle'}

#指定查看节点

node_cpu_seconds_total{mode='idle',instance="192.168.37.30:9100"}

#计算过去5分钟内的CP0使用速率
PromQL: irate (node_ Cpu_ seconds_ total (mode-“idle”} [5m] )

解析:
irate:速率计算函数( 灵敏度非常高的)
node_ cpu_ seconds_ total :node节点CPU使用总量
mode-"idle"空闲指标
5m:过去的5分钟内，所有CPU空闲数的样本值，每个数值做速率运算

每台主机CPU在5分组内的平均使用率

PromQL:  (1-avg (irate(node_cpu_secondes_total{mode='idle'}[5m]))by(instance))*100

解析
avg:平均值
avg (irate (node cpu seconds total {mode= ‘idle’} [5m]):可以理解为CPU空闲量的百分比
by (instance) :表示的是所有节点
(1- avg (irate (node_ Cpu_ seconds_ total (mode= ’ idle’) [5m]))by (instance))* 100: CPU 5分钟内的平均使用率

其他常用的指标:
1、查询1分钟平均负载超过主机CPU数量两倍的时间序列

node_load1 > on (instance)2*count(node_cpu_seconds_total{mode='idle'})by(instance)

2、内存使用率

node_memory_Active_file_bytes
node_memory_MemAvailable_bytes
node_ memory_ Buffers_ bytes
node_ memory_ Cached_ bytes

3、计算使用率

可用空间:以上后三个指标之和
已用空间:总空间减去可用空间
使用率:已用空间除以总空间

服务发现 serice discovery

Prometheus指标抓取的生命周期
发现->配置.-> relabel ->指标数据抓取-> metrics relabel
Prometheus的服务发现
基于文件的服务发现:
基于DNS的服务发现:
基于API的服务发现: Kubernetes. Consul. Azure. …
重新标记
target重新打标
metric重新打标

指标抓取的生命周期
在每个scrape_ interval 期间，Prometheus 都会检查执行的作业(Job) :
这些作业首先会根据Job.上指定的发现配置生成target列表，此即服务发现过程:
服务发现会返回一一个Target列表，其中包含一组称为元数据的标签，这些标签都以" meta_ "为

前缀:
服务发现还会根据目标配置来设置其它标签，这些标签带有"_ "前缀和后缀，包括scheme “、” address "和“metrics path "，分别保存有target支持使用协议(http或https,默认为http)、target的地址及指标的URI路径(默认为/metrics);
若URI路径中存在任何参数，则它们的前缀会设置为“param”
这些目标列表和标签会返回给Prometheus,其中的一.些标签也可以配置中被

覆盖:
配置标签会在抓取的生命周期中被重复利用以生成其他标签，例如，指标上的instance标签的默认值就来自于标签的值:

总结：

promethesu
数据采集/获取
①pro-server端-》没有数据采集功能一 -》本身pro-server端，是通过pull模型HTTP/HTTPS方式拉取监控端数据(周期)
②exporter
数据采集
exporter 一》主动去抓取
1、采集，
2、因为很多被监控端默认没有HTTP功能，exporter. 会将数据转化为pro可以识别/兼容的格式(HTTP) , node1-IP:9100
Instrumentation–》服务内部自建的一套数据采集方式，http/https方式提供出来pro-server. 一》 pull
3、 pushgateway, - -》负责采集- -些短期/临时性的任务(需要被监控的)- 》汇总到pushgateway网关，等待pro-server拉取
①TSDB +表达式浏览器(WEB)
pro-server端 pull到数据之后，会保存在TSDB时序数据库中
TSDB数据中数据，会做为表达式浏览器(UI) 的数据来源来展示出来
②alertmanager
告警规则，pro-server内部可以使用promQL编写告警规则
(告警规则的表达式是布尔值-true、false)
CPU使用率50%以上是异常，以下是正常
PromQL—>过滤我们收集的数据中CPU使用率的部分做为
PromQL- 》CPU是608 > 50号 —》true. 一》alertmanager- -》才会通过各种接口SMTP
③server discovery :服务发现
pro-server 需要持续运行，前台终端，如果被监控端发生了更新(增、减) - -》 pro-server 可以自动发现
file 一》
consul- -》自动发现、更新
DNS-
一》主机A记录 SRV记录
K8S - -》

QQ邮件告警:
prometheus-server——》定义告警规则(布尔值表达式，以及描述信息)，一旦表达式为true，那么会将此告警信息
发送给alertmanager
alertmanager此时会根据主配置文件中定义的route (告警路由)，recver (接收方/告警媒介)进行发送

5大核心组件
pro-server端
exporter / Instrumentation / pushgateway
TSDB +表达式浏览器(WEB)
alertmanager
server discovery

是白盒监控：自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可。（适用于容器监控）