监控的基本理论和prometheus安装

前言

这篇博客主要讲的是关于理论的知识，大家尽可能的消化和吸收，也能扩展大家的知识面

监控的基本概念

监控俗称为运维的第三只眼。没有了监控，业务运维都是“瞎子”。所以说监控室运维这个职业的根本，尤其是在Devops这么活的时候，用监控数据给自己撑腰，这个显得更加的必要，有人说运维是背锅侠，那么有了监控，就有了证据，一切以证据说话，运维就不需要背锅了，

所以作为一个运维工程师，如何构建一套监控系统是你的第一个工作

SRE必修课程，搞懂SLI,SLO,SLA的区别

SRE团队主要承担的职责，可用性的改进，延迟优化，效率提高，变更管理，监控，紧急事物的处理以及容量规划与管理，总结一句话，就是提升服务质量，就要指定一个针对于客户服务质量的目标，这就是今天要聊的SLI,SLO,SLA

1. SLI

SLI是指的服务质量水平标准（service level lndicator）用来描述一个服务有多好，达到好的标准，对于业务来说是重要的指标，对于一个网站而言，一个常见的sli是 请求的响应时间是多少，比如tcp延迟小于200ms,又比如pod在一分钟内交付。我i们通常从延迟性，可用性，吞吐率和成功率这些角度来指定sli

2. SLO

slo (service level object) 表示目标服务器，来衡量一个SLI指标在一段时间内达到好的标准比例，通常是一个百分比，并与一个时间范围内挂钩，比如，月度、季度、年度等。如果脱离了时间的度量，SLO的意义就不大了。比如说，99%的Pod在1min内交付。每月 99.99% 的 TCP 请求延迟（SLI）小于 200ms。

3. SLA

SLA是服务水平协议，常用于SLO定义的目标比例唯有完成时，服务器方要赔付多少。

区别SLO和SLA的一个简单方法是问“如果SLO没有达到时，有什么后果？”如果没有定义明确的后果，那么我们就肯定是在讨论一个SLO，而不是SLA。

监控方法论

目前业界比较流行的方法论有Google的4个黄金指标，RED方法，USE方法

Google的4个黄金指标

google的4个黄金指标对于服务器监控分别是延迟，流量，错误和饱和度。

延迟：表示服务请求所花费的时间，比如说用户获取商品列表上的每个接口，花费30毫秒，注意请求成功的延迟和失败请求的延迟区别。通常延迟较高时不好的表现，大多数的情况下也意味着系统的系统系能不好，用户的体验不好。

流量：表示系统承载的用户活交易的量级，流量对于不同类型的服务而言可能代表着不同的含义，比如对于web的http应用。这类的指标可能表现为tps,qps,流量指标通常是2用来展现当前系统的负载状态和不同时段的负载情况。

错误：表示当前系统发生错误的评价维度，错误一般可以分为显示错误和隐藏式错误。

举例子来说：http返回了500状态码，说明这个请求是失败的，也就属于显示错误，而某些情况下，http尽管返回了200的状态码但是返回的内容不符合预期这个就是隐藏式的错误，也就是请求失败。此类指标可以用来衡量系统的运行质量

饱和度：表示当前资源使用的饱和度情况，通常情况下，资源达到饱和度，服务器的性能会下降，比如磁盘的读写功能，还有式I/o操作下降会处于阻碍状态，此外cpu使用率也可以作为饱和度的指标，这类指标可以衡量系统资源的使用率

RED方法

RED方法式Google的4类的黄金指标基础上提出的，它重点关注应用请求的3个关键指标，希望由此涵盖web服务（也是占比最高的服务类型）相关问题

（Request）Rate:请求速率，每秒请求数

（Request）Errors:错误，每秒，错误请求数量

（Request）Duration:延迟,每一个请求延迟分布情况

三个英文单词取首字母组成 RED 方法，姑且可以看做是 Google 四个黄金指标的简化版。RED方法是以请求为中心，聚焦用户在使用Web服务时所应关注的重点，通过这三项指标，我们就能监测到 通常情况下影响客户使用体验的关键信息。

Red方法，主要适用于关注和请求相关的指标数据，适合云原生应用和微服务应用下的应用

USE 方法

USE 是使用率（Utilization）、饱和度（Saturation）、错误（Error）的缩写，主要用于分析资源问题。

什么是资源？主要是指传统意义上的物理服务器组件，比如 CPU、硬盘等，但现在很多人已经扩展了资源的范围，把一些软件资源也包含在内。下面我们对使用率、饱和度、错误做一个更详细的解释。

资源使用率：这个我们最熟悉，比如CPU、内存、网络、磁盘I/O等。如果某项资源使用率持续较高，那么通常说明其存在一定的性能瓶颈。

饱和度：与Google的4个黄金信号中的饱和度意义相同。

错误：与错误相关的指标统计信息，比如调用失败次数、或通过 ifconfig 看到的 errors、dropped 包量。还有很多错误是以系统错误日志的方式暴露的，没法直接拿到某个统计指标，此时可以进行日志关键字监控。

USE 方法，可以从资源使用率、资源饱和度等指标维度进行监控和分析，对于系统性能监控和性能瓶颈识别可以起到很好的作用，适用于主机级监控。

需要监控的指标有那些

我们在这里用一个图来表示

1.资源监控

资源监控，主要是针对硬件设备和网络，硬件设备又分为服务器，网络设备又衍生为通信监控，质量监控，流量监控

2.组件监控

我们将常用web,数据库，中间间，容器等系统通常称之为组件，因此监控组件。

3.应用监控

应用监控就是指对应用程序（Application）的监控，Google 的四个黄金指标、RED 方法主要就是针对应用监控的。其实主要监控的是应用的性能指标

4.业务监控

这类监控指标非常重要，它代表着业务系统是否正常，同时也是管理层非常关注的，因为业务系统代表企业营收，或者跟客户项目相关，核心业务指标异常，一定是故障，业务指标异常代表着最终用户体验受损，或者造成公司直接资产损失。

5、监控与可观测性

监控的本质就是收集、分析和使用信息来观察一段时间内监控对象的运行进度，并且进行相应的决策管理的过程，监控侧重于观察特定指标。

但是随着云原生时代的到来，我们对监控提出了更多的要求：

通过监控了解数据趋势，知道系统在未来的某个时刻可能出问题，预知问题。

通过监控了解系统的资源情况，为服务扩缩容提供数据支撑。

通过监控来给系统把脉，感知到哪里需要优化，比如一些中间件参数的调优。

通过监控来洞察业务，提供业务决策的数据依据，及时感知业务异常。

要实现这些功能，就是今天要讲的“可观测性”。可观测性是云原生时代必须具备的能力。目前，“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。

可观测性是指在软件系统中，通过度量、监控和分析系统的各个组件行为，以便于了解系统的状态、性能和问题的能力。

可观测性的重要性在于它可以帮助开发人员及时发现问题，快速定位问题，并在问题发生时采取相应的措施，以减少系统的故障率和维护成本。此外，可观测性还有助于开发人员了解系统的实际运行情况，以便于对系统进行优化和升级。

在可观测性中，有三个重要的组件：

• 聚合指标：聚合指标指的是将多个指标数据聚合到一个单独的指标中以简化数据。例如，将多个节点的 CPU 利用率聚合为一个单一的平均值。聚合指标允许我们更轻松地理解系统的整体性能。同时，聚合指标还可以帮助我们快速识别潜在问题并了解系统中哪些部分 可能需要更多的资源。
• 事件日志：事件日志是一组事件的记录，这些事件可以提供系统的历史记录和状态变化。例如，错误、警告和信息性事件都可以记录在事件日志中。事件日志对于诊断和调试问题非常有用，因为它们提供了对系统活动的详细记录。还可以发现系统中无法预知的行为。
• **链路追踪：链路追踪是一种用于跟踪分布式系统中请求的过程，以了解请求的路径以及请求在每个服务中花费的时间。**这有助于识别分布式系统中的性能瓶颈和瓶颈来源。链路追踪还可以帮助我们诊断分布式系统中出现的错误和问题，因为它提供了有关请求在哪个组件中失败的信息。

因此，可观测性能够回答以下几个问题：

• 性能瓶颈有哪些
• 请求需要接受的服务有哪些
• 请求执行过程与系统行为之间的差异性
• 请求失败的原因
• 每一个微服务将如何处理请求

Prometheus的组件和架构

Prometheus介绍

Prometheus是一套开源的系统监控报警框架，作为新一代的云原生监控系统，Prometheus既可以实现主机为中心的监控，也可以完成以服务为导向的动态架构监控，在微服务的世界里，它支持多维度的数据集合，查询功能非常强大，

Prometheus的优势

• 简单部署，Prometheus唯一需要的是一个本地磁盘，因为他的核心是一个二进制的文件，没有数据库，缓存等一系列的第三方的依赖
• Prometheus可以实现监控服务的内部状态
• Prometheus 内置强大的一个数据查询语言PromQL,通过PromQL可以实现对于数据的查询，聚合。
• Prometheus可以高速的处理10多万的数据。

与zabbix相比，使用的场景区别

• 偏基础的监控，像主机，网络这种场景，使用zabbix更加适合
• 简单来说更适合于硬件方面，cpu,硬盘，内存。。。
• 偏服务类型的容器的，使用Prometheus来作为监控。

一句话总结

服务类如：mysql,redis,php,python用于Prometheus

硬件类如：硬盘，cpu,内存

Prometheus的组件和架构

Prometheus 的生态系统包括多个组件，大部分组件都是由go语言编写而成，因此部署十分的方便，而这些组件都是可以选择的

主要的组件如下

Prometheus Server
Prometheus Server 是prometheus的核心组件之一，负责对于监控数据的获得，存储以及查询推送网关（push gateway）
主要是用来接收client push 推送过来的指标数据，在指定的时间间隔，由Prometheus Server来抓取Exporter
主要来采集数据，通过http服务的形式暴露于 Prometheus server -》它通过访问Exporter提供接口，即可采集到监控数据数据
常见的Exporter有很多，例如node_exporter、mysqld_exporter、statsd_exporter、blackbox_exporter、haproxy_exporter等等，支持如 HAProxy，StatsD，Graphite，Redis 此类的服务监控。警告管理器（Alertmanager）
管理告警，主要是负责实现监控报警功能。在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。

pull 和 push

pull监控主动的拉取目标数据

push目标推送数据到监控

• Prometheus是通过HTTP方式抓取组件的状态，任意组件只要提供的http接口符合Prometheus定义的数据格式，就可以接入prometheus监控
• Prometheus Server负责定时在目标上抓取metrics(指标)数据，每个抓取目标都需要暴露一个HTTP服务接口用于Prometheus定时抓取。这种调用被监控对象获取监控数据的方式被称为Pull(拉)；Pull方式体现了Prometheus独特的设计哲学与大多数采用Push(推)方式的监控不同
• Pull方式的优势是可以降低耦合。pull模式可控性好，pull模式下，监控系统是主动的一方，可以控制频率；push模式，客户端是主动的一方，如果代码写的有问题，就会给监控系统造成很大压力。所以通过Pull方式，被采集端无需感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制。
• Pull方式的优势是可以降低耦合。pull模式可控性好，pull模式下，监控系统是主动的一方，可以控制频率；push模式，客户端是主动的一方，如果代码写的有问题，就会给监控系统造成很大压力。所以通过Pull方式，被采集端无需感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制。

所以说pull模式完美打败push模式

Prometheus安装配置

时序数据库全称是时间序列数据库，时间序列数据库指用于处理时间标签，按照时间顺序变换，即时间上的变化，常用于物联网设别和互联网监控的业务场景，提供读写的性能和强聚合计算的服务。

时间序列数据库主要按照一定的时间间隔产生一个个的数据点，以时间轴为横坐标，序列为纵坐标，如图所示：

时序数据库的特点：

• 严重依赖于采集时间：每条数据都有一个时间戳，通常以UNIX时间为单位，可以方便地对数据进行排序和查询。
• 数据产生频率快：高并发写入，主要是写入和读取操作，没有更新操作，通常以秒或毫秒为单位，有时甚至会达到微秒级别。
• 存在明显的冷热数据：一般只会查询近期数据。对冷数据降低精度存储，对历史数据做聚合，节省存储空间。
• 大量的统计查询要求：查询一定时间范围内的计数、最大值、最小值和平均值。

常见时序数据库：InfluxDB、OpenTSDB等。

Prometheus数据指标的概念及命名方式

promethes监控中，对于采集过来的数据统称为指标（metrics）数据，当我们需要为某个系统、某个服务做监控统计时，就需要用到指标数据。因此，指标是对采样数据的总称，注意，metrics并不代表某种具体的数据格式，它是对于度量计算单位的抽象。

Prometheus将采集的监控数据以指标（metric）的形式保存在内置的时间序列数据库当中（TSDB），每一条时间序列是由 metric 的名字和一系列的标签（key/value键值对）来唯一标识的，不同的标签代表不同的时间序列。格式如下：

<metric name>{<label name>=<label value>, …}

• metric（指标）名字：指标名称可以反映监控样本的含量，一般用于metric的功能，例如prometheus_http_requests_total， 表示http请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成。

• 标签：标签可以使 Prometheus的数据更加丰富，对于相同的指标名称，通过不同标签列表的集合，会形成特定的维度实例。改变任何指标上的任何标签值（包括添加或删除指标），都会创建新的时间序列。例如：

prometheus_http_requests_total{code="200"}

在时间序列中的每一个点称为一个样本（sample），时间序列的样本数据包括一个float64的值和一个毫秒级的unix时间戳，这些数据是按照某个时序以时间维度采集的数据。这样，一个完整的时间序列的组成如下图所示：

下面的例子：

<--------------- metric and lable----------------------><-timestamp ->  <-value->
http_request_total{status="200", method="GET"}          @1434417560938 => 94355
http_request_total{status="200", method="GET"}          @1434417561287 => 94334
​
http_request_total{status="404", method="GET"}          @1434417560938 => 38473
http_request_total{status="404", method="GET"}          @1434417561287 => 38544
​
http_request_total{status="200", method="POST"}         @1434417560938 => 4748
http_request_total{status="200", method="POST"}         @1434417561287 => 4785

Prometheus server 下载

安装Prometheus之前必须要先安装ntp时间同步，因为prometheus server对系统时间的准确性要求很高，必须保证本机时间实时同步。这里我们以Almalinux9.1/RHEL9.1为例，先执行时间同步，执行如下计划任务：

[root@docker-110 ~]# timedatectl set-timezone Asia/Shanghai
[root@docker-110 ~]# crontab -e

首先需要到Prometheus官网 http://prometheus.io 下载最新版本的Prometheus，自己去下载

安装与启动Prometheus server

prometheus的安装非常简单，只需解压即可，然后执行命令可直接启动。

[root@localhost ~]# tar -xvzf prometheus-2.44.0.linux-amd64.tar.gz
[root@localhost ~]# mv prometheus-2.44.0.linux-amd64  /usr/local/prometheus[root@docker-110 prometheus]# ll
total 302892
-rw-r--r-- 1 1001 docker     11357 Jun 30 21:38 LICENSE
-rw-r--r-- 1 1001 docker      3773 Jun 30 21:38 NOTICE
-rwxr-xr-x 1 1001 docker 159395306 Jun 30 21:25 prometheus
-rw-r--r-- 1 1001 docker      1093 Jun 30 21:38 prometheus.yml
-rwxr-xr-x 1 1001 docker 150742130 Jun 30 21:25 promtool
[root@docker-110 local]# cd prometheus/ 
[root@docker-110 prometheus]# ./prometheus --version 
prometheus, version 3.5.0-rc.0 (branch: HEAD, revision: 31f0c7007e7187b706da03e05aeeb303101164f8)build user:       root@d6b2cb516986build date:       20250630-13:23:30go version:       go1.24.4platform:         linux/amd64tags:             netgo,builtinassets

使用systemctl管理prometheus

# 创建prometheus本地存储的数据库
mkdir -p /var/lib/prometheusvim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Documentation=https://prometheus.io/
After=network.target[Service]
# Type设置为notify时，服务会不断重启
Type=simple
User=root
# --storage.tsdb.path是可选项，默认数据目录在运行目录的./dada目录中
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure[Install]
WantedBy=multi-user.target

访问本机ip:9090地址