一、监控系统基础

1.1 监控系统功能组件

• 指标数据采集。比如监控端周期的向被监控端抓取数据，或者被监控端周期性的向监控端报告/上传自身的数据。所谓监控，即针对被监控系统的某个维度的属性执行某种测量机制后获取的结果。
• 指标数据存储。要想分析数据的演变趋势，保存数据是前提。
• 指标数据趋势分析及可视化。数据存储完成后，需要对数据进行相关聚合操作，比如求平均数、最大/最小值等，将产生的结果以可视化方式展现数据变动的情况。
• 告警。当结果不符合预期(突破阈值)时，向用户发起警报通知，告诉用户系统出现的异常。对应的媒介比如邮件、微信等。

1.2 监控体系

自下而上分为系统层监控、中间件及基础设施类系统监控、应用层监控、业务层监控。

1.2.1 系统层监控

• 系统监控：CPU、Load、Memory、Process…
• 网络监控：网络设备、工作负载、网络延迟、丢包率…

1.2.2 中间件及基础设施类系统监控

• 消息中间件：Kafka、RabbitMQ等
• Web服务容器：Tomcat等
• 数据库及缓存系统：Mysql、PostgreSQL、ElasticSearch、Redis等
• 数据库连接池：ShardingSphere等
• 存储系统：NFS和Ceph等

1.2.3 应用层监控

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

1.2.4 业务层监控

• 用于衡量应用程序的价值，比如电子商务网站上的销售量
• QPS、dau日活、转化率等
• 业务接口：登录数、注册数、订单量、搜索量和支付量等

1.3 著名的监控方法论

1.3.1 Google SRE的四黄金指标

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

1.3.1.1 延迟：服务请求所需时长

应用程序响应时间会受到核心系统资源(内存、CPU、网络、存储)延迟的影响。记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。

1.3.1.2 流量(吞吐量)

用于衡量服务的容量需求，例如每秒处理的HTTP请求数或数据库系统的事务数量。

1.3.1.3 错误

失败的请求的数量，可衡量错误请求占请求总数的百分比。

1.3.1.4 饱和度

衡量资源的使用情况，用于表达应用程序使用资源的程度。比如CPU、内存、磁盘的使用量。

1.3.2 Weave Cloud的RED方法

RED方法是Weave Cloud在基于Google的“4个黄金指标”的原则下结合Prometheus以及Kubernetes容器实践，细化和总结的方法论，特别适合于云原生应用以及微服务架构应用的监控和度量。主要关注以下三种关键指标。

• (请求)速率：服务每秒接收的请求数。
• (请求)错误：每秒失败的请求数。
• (请求)耗时：每个请求的耗时。

1.3.3 USE方法

USE方法全称"Utilization Saturation and Errors Method"，由Netflix的内核和性能工程师Rendan Gregg提出，主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈以及错误。

• 使用率：关注系统资源的使用情况。这里的资源主要包括但不限于：CPU，内存，网络，磁盘等等。100%的使用率通常是系统性能瓶颈的标志。
• 饱和度：例如CPU的平均运行排队长度，这里主要是针对资源的饱和度(注意，不同于4大黄金信号)。任何资源在某种程度上的饱和都可能导致系统性能的下降。
• 错误：错误计数。例如：“网卡在数据包传输过程中检测到的以太网网络冲突了14次”。

二、Prometheus介绍

2.1 简介

Prometheus 最开始是由 SoundCloud开发的开源监控告警系统，是 Google BorgMon 监控系统的开源版本。在 2016 年，Prometheus 加入 CNCF，成为继 Kubernetes 之后第二个被 CNCF 托管的项目。它是一个时序(time series)数据库TSDB，但其主要功能却不限于TSDB，而是一款用于进行目标监控的关键组件。
       什么是时序数据？时序数据即在一段时间内通过周期性反复测量而获得的观测值的集合；将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴。像服务器指标数据、网络数据、应用程序性能监控数据等都是时序数据。

2.2 Prometheus特性

• 灵活的查询语法 PromQL。
• 不需要依赖额外的存储，一个服务节点就可以工作。
• 利用http协议，通过pull模式周期性的向目标(主机/服务)收集时间序列数据(核心功能)。被监控端暴露一个http服务端口便于Prometheus Server定期采集数据。
• 需要push模式的应用可以通过中间件gateway来实现。
• 监控目标支持服务发现和静态配置。
• 支持各种各样的图表和监控面板组件。

2.3 Prometheus收集(scrape)数据的方式

• Exporters：工作在被监控端，周期性的以pull的方式去采集数据并转换为Prometheus所兼容的格式，再暴露一个http接口，等待Prometheus Server去采集数据。
• Instrumentation：指被监控对象内部自身有数据采集、监控的功能，自身就能暴露出Prometheus所兼容的格式的指标，这样只需要Prometheus直接获取即可，无需部署Exporters。
• Pushgateway：介于Prometheus和被监控端之间，起了一个中间人的角色。Prometheus默认不支持被监控端主动推送(汇报)数据，但有些场景是需要被监控端自动汇报和推送数据的，此时Pushgateway就派上用场了。此时监控端主动推送(汇报)数据给Pushgateway，由Pushgateway接收并缓存数据，之后等待Prometheus Server周期性的去抓取Pushgateway上的数据。此时，Prometheus Server获取数据的对象不再是被监控端，而是Pushgateway。当被监控端是个作业(eg：Kubernetes的Job)时就可以用Pushgateway用于汇报指标数据，否则在Prometheus的数据抓取周期到达之前这个Job就运行结束了，这样指标数据就来不及抓取。因为Job是有结束时间的，它不会自己就等待Prometheus去收集数据的。

2.4 Pull和Push

Prometheus 同其他TSDB相比有一个非常典型的特性：主动从各Target上拉取(pull)数据，非等待被监控端的推送(push)。
       两个获取方式各有优劣，其中，Pull模型的优势在于：

• 集中控制：有利于将配置集在Prometheus Server上完成，包括指标及采取速率等。
• Prometheus的根本目标在于收集在target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统。

2.5 Prometheus的生态组件

• Prometheus Server：服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。包含Retrieval、TSDB、HTTP Server三部分。其中，Retrieval组件负责在目标主机上抓取监控指标数据； TSDB负责时序数据的存储及其检索；HTTP Server即对外提供HTTP服务
• Client Library：客户端库，目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。
• Push Gateway：接受那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行获取指标操作。
• Exporters：指标暴露器，负责收集不支持内建Instrumentation 的应用程序或服务的性能指标数据，并通过HTTP接口供Prometheus Server获取。
• Alertmanager：是一个独立的告警模块，从Prometheus Server端接收到“告警通知”后，会进行去重、分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件、钉钉、企业微信等。
• Data Visualization：Prometheus Web UI(Prometheus Server内建)，以及Grafana等。
• Service Discorvery：动态发现待监控的目标，在容器化环境中尤为有用。该组件目前由Prometheus Server内建支持。

2.6 Prometheus的工作模式

1. Prometheus基于服务发现机制或静态配置获取要监控的目标，并通过每个目标上的Exporter来采集指标数据。
2. 当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘(如果使用 remote storage 将持久化到云端)。
3. Prometheus可以配置 rules，然后定时查询数据，当条件触发的时候，会将基于alert 规则生成的告警信息推送到配置的 Alertmanager。
4. Alertmanager收到警告的时候，可以根据配置，聚合，去重，降噪，最后发送警告。
5. 可以使用API或Grafana 查询和聚合数据。

2.7 作业和实例

能够接收Prometheus Server数据抓取操作的每个网络端点，称为一个实例(Instance)；通常，具有类似功能的实例的集合就称为一个Job，例如一个Mysql主从复制集群中的所有Mysql进程。

2.8 Prometheus不适用的场景

• Prometheus是一款指标监控系统，不适合存储事件及日志。
• Prometheus认为只有最近的监控数据才有查询的必要，其本地存储的设计初衷只是保存短期数据，因而不支持针对大量的历史数据进行存储。

2.9 Prometheus和Zabbix对比

2.9.1 数据模型和查询语言

Prometheus使用一个称为PromQL的查询语言来查询和处理时间序列数据。PromQL支持许多数据模型和查询功能，包括度量标准、标签和聚合函数。Zabbix使用自己的数据模型和查询语言，包括触发器和动作等概念。

2.9.2 存储方式

Prometheus使用一种称为TSDB的时间序列数据库来存储时间序列数据。Zabbix使用关系型数据库来存储数据。

2.9.3 自动化和配置管理

Prometheus具有自动化和自动配置的能力，它可以自动发现服务和指标，并对它们进行监控。Zabbix也提供了类似的功能，但需要手动配置。

2.9.4 可视化和警报

Zabbix和Prometheus都支持可视化和警报功能。Zabbix提供了一个基于Web的前端界面，可以查看监控数据和设置警报。Prometheus通常与Grafana等工具一起使用，以实现更高级的可视化和警报功能。

2.9.5 性能和扩展性

Prometheus在性能和扩展性方面表现良好，能够处理大规模的时间序列数据。Zabbix也具有良好的性能和扩展性，但在大规模监控方面可能需要更多的资源和配置。

Zabbix 更加适合用于本地计算机的监控，而Prometheus 更适合在现在流行的云计算监控上使用。

三、部署Prometheus

3.1 部署Prometheus Server

3.1.1 下载安装包并解压

wget https://github.com/prometheus/prometheus/releases/download/v2.46.0/prometheus-2.46.0.linux-amd64.tar.gz
tar -xf prometheus-2.46.0.linux-amd64.tar.gz
mv prometheus-2.46.0.linux-amd64 /usr/local/prometheus

3.1.2 配置Prometheus Server

可通过默认的配置文件prometheus.yml查看里面的内容

cd/usr/local/prometheus && cat prometheus.yml
# my global config
global:
 scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
 evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
 # scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
 alertmanagers:
 - static_configs:
 - targets:
 # - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
 # - "first_rules.yml"
 # - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
 - job_name: "prometheus"
 # metrics_path defaults to '/metrics'
 # scheme defaults to 'http'.
 static_configs:
 - targets: ["localhost:9090"]

Prometheus 默认的配置文件分为四大块：

• global：Prometheus 的全局配置，比如 scrape_interval 表示 Prometheus 多久抓取一次指标数据，evaluation_interval 表示多久运行一次告警规则。
• alerting：生成告警信息并将其发给alertmanager(目前没用上)。
• rule_files：根据指定文件的rules(Record Rule或Alert Rule)来周期性的评估。
• scrape_configs：这里定义了 Prometheus 要抓取的目标，我们可以看到默认已经配置了一个名称为 prometheus 的 job，这是因为 Prometheus 在启动的时候也会通过 HTTP 接口暴露自身的指标数据(Prometheus自己监控自己)。

3.1.3 为Prometheus配置systemctl启动服务

vim /lib/systemd/system/prometheus.service
[Unit]
Descriptinotallow=prometheus server daemon
[Service]
Restart=on-failure
#--storage.tsdb.path：数据存储路径
#--storage.tsdb.retention.time：数据存储时间
#--web.enable-lifecycle：支持热加载
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/usr/local/prometheus/data --storage.tsdb.retention.time=30d --web.enable-lifecycle
[Install]
WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable --now prometheus

注意：如果是使用其它普通用户启动Prometheus，则需要先添加相关用户，再把Prometheus相关目录(包括存储数据的目录)的属主属组设置为相关用户。

3.2 了解Exporter相关知识

广义上讲，所有可以向Prometheus提供监控样本数据的程序都可以被称为一个Exporter。而Exporter的一个实例称为target，如下图所示，Prometheus通过轮询的方式定期从这些target中获取样本数据。

为什么要使用Exporter呢？

云原生组件就支持Prometheus接口监控，像etcd、Kubernetes、CoreDNS等就可以直接被Prometheus监控。但大多数服务在Prometheus诞生前的很多年就已发布，考虑到安全性、稳定性及代码耦合等因素的影响，软件作者并不愿意将监控代码加入现有代码中。

在此背景之下，Exporter 应运而生，Prometheus 在面对众多繁杂的监控对象时并没有采用逐一适配的方式，而是制定了一套独特的监控数据规范，符合这套规范的监控数据都可以被Prometheus统一采集、分析和展现。说白了你想用Prometheus收集数据要么改造软件支持Prometheus数据格式，要不然开发第三方插件Exporter。

3.3 部署Node Exporter

3.3.1 下载安装包并解压

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz
tar -xf node_exporter-1.6.1.linux-amd64.tar.gz
mv node_exporter-1.6.1.linux-amd64 /usr/local/node_exporter

3.3.2 为Node Exporter配置systemctl启动服务

vim /lib/systemd/system/node_exporter.service
[Unit]
Descriptinotallow=Node Exporter
Wants=network-online.target
After=network-online.target
[Service]
#--collector.filesystem.mount-points-exclude：磁盘监控中需要忽略的设备
ExecStart=/usr/local/node_exporter/node_exporter --web.listen-address=:9100 --collector.filesystem.mount-points-exclude="^/(dev|proc|run|boot|run/credentials/.+|sys|data/kubelet/.+|sys|data/docker.+|sys|var/lib/.+)($|/)"
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=node_exporter
[Install]
WantedBy=default.target

systemctl daemon-reload && systemctl enable --now node_exporter

3.4 Prometheus Server收集Node节点信息

在prometheus.yml添加如下内容：

- job_name: "node_exporter"
 static_configs:
 - targets: ["192.168.131.11:9100"]

此时调用Prometheus接口热加载配置，如果有报错也会检查到，类似于nginx -s reload。也可以先执行语法检查规则再进行热加载。

#Prometheus接口热加载配置命令
curl -X POST Prometheus Server IP:9090/-/reload
#Prometheus配置文件语法检查规则命令
promtool check rules /path/to/example.rules.yml

此时查看Prometheus web UI页面也能看到新加了一个对应的target。