Prometheus
项目上线后如何保障业务的稳定性运行
-
高可用架构设计
- 采用分布式架构和容灾设计，确保系统的冗余与可恢复能力
- 包括多机房部署、多副本部署、负载均衡、热备份等策略，以应对单点故障和海量并发请求。
-
服务容错与降级
- 在面对故障或异常情况时，通过设计合适的容错机制和降级策略来保证核心业务的稳定进行
- 例如，对于关键服务，可以使用熔断器、限流器等技术来避免级联故障和请求雪崩。
-
自动化运维和发布
- 制定自动化的运维流程，包括自动化的部署、回滚、灰度发布等，减少人工操作引起的错误和风险。
- 同时，建立持续集成与持续交付（CI/CD）流程，确保代码的质量和稳定性
-
安全保障和漏洞修复
- 建立健全的安全策略和防护措施，保障系统和数据的安全。
- 同时及时修复系统中的漏洞和安全问题，避免被攻击者利用导致系统瘫痪或用户数据泄漏。
-
备份与恢复
- 定期进行系统数据的备份，并建立灾难恢复机制，备份可以包括系统配置、数据库、日志等关键数据
- 在系统发生故障时，能够及时将数据恢复到最新的可用状态。
如何发现业务的不稳定运行
互联网公司需要在开发、测试、发布、运维等不同阶段对产品进行监控，以便及时发现问题并采取相应措施
-
最终的核心：异常监控与预警
- 建立完善的监控系统，通过监控关键指标（如 CPU、内存、带宽等）来实时感知系统的健康状态
- 同时设置预警规则，一旦异常发生，结合自动化运维及时通知相关人员并采取相应的应急措施。
- 比如
- 网络故障或稳定性问题
- 由于网络故障、硬件故障或配置错误等原因，可能会导致访问不稳定或宕机，进而影响用户的体验。
- 性能瓶颈和延迟
- 当用户访问量增加时，可能会对服务器产生超过负荷或达到带宽上限的压力，导致网页或其他平台响应速度变慢，影响用户体验和满意度。
- 数据安全性问题
- 不法分子可能通过攻击防火墙、病毒、恶意软件等途径获取数据或进行恶意操作，在一定程度上破坏了数据的安全性
- 网络故障或稳定性问题
-
公司建设监控和告警系统的意义
- 提前预知和识别问题
- 监控和告警系统可以帮助我们实时获取系统的运行数据和指标，
- 通过对关键指标的监控和分析，可以提前预知系统可能出现的问题，如性能下降、异常错误、服务不可用等。
- 通过告警及时发现问题，可以提高问题识别的速度和准确性，便于及时采取相应的措施来修复问题。
- 提高故障响应和处理效率
- 及时发现和处理故障可以减少系统的停机时间，避免影响用户体验和业务运行。
- 配置监控和告警系统可以帮助运维团队更快速地响应和解决问题，减少故障的恢复时间，减少业务损失。
- 优化系统性能和资源利用
- 监控和告警系统可以实时监测系统的性能和资源利用情况，如 CPU、内存、磁盘、网络等。
- 通过对系统的性能指标进行监控和分析，可以帮助我们了解系统的负载情况和瓶颈
- 及时进行性能优化和资源扩展，以提高系统的稳定性和可扩展性。
- 安全风险的监测和应对
- 监控和告警系统还可以对系统的安全风险进行实时监测和预警。通过对异常访问、漏洞攻击、异常登录等进行监控和分析
- 可以帮助及时发现和应对潜在的安全风险，并保护系统和数据的安全。
- 提前预知和识别问题
监控系统常见的架构模式和主流系统对比
- Pull 模式
- 优点
- 可以根据需要定时获取数据，避免数据的多余传输，节约网络带宽和存储空间。
- 可以根据需要通过请求的方式，选定性地获取部分数据。
- 适用于对被监控对象的稳定性要求不高的场景
- Pull 模式核心消耗在监控系统侧，应用侧的代价较低
- 缺点：
- 由于需要定时发送请求获取数据，对于需要实时响应的业务，Pull 模式的数据传输速度难以达到。
- Pull 模式需要能够处理推送事件的应用程序，因此需要有较高的成本和复杂性。
- 优点
- Push 模式
- 优点
- 被监控对象可以主动推送数据，监控服务端不需要发送请求，因此避免了网络负载。
- 对于需要实时响应数据的业务，Push 模式具有更高的传输效率和更佳的实时性。
- Push 模式适用于稳定的网络环境，可以实现实时数据的快速传输
- 缺点：
- Push 模式核心消耗在推送和 Push Agent 端，监控系统侧的消耗相比 Pull 要小
- 被监控对象需要主动发送数据，不适用于对被监控对象要求性能较高的场景，需要严格控制被监控对象的数据流量
- 优点
- 总结
- 公司内部的监控系统来说，应该同时具备 Pull 和 Push 的能力才是比较合适的
主流监控告警框架对比
-
- Zabbix（支持 pull/push 两种模式）
- 基于 C 语言开发, 是一种基于服务器-客户端体系结构开发的企业级监控软件，它允许监控各种网络服务，服务器资源和硬件
- 优点：
- 用户友好，易于部署和设置
- 具有插件式框架，可以灵活地满足不同的监控需求
- 提供了丰富的图形化监控数据
- 具有高扩展性，用户可以轻松添加自定义功能。
- 缺点：
- 功能强大，使用比较笨重，Zabbix 的安装和部署需要更多的时间和资源
- 对于复杂的 IT 架构，Zabbix 的配置难度较大,
- 响应时间不够实时，对于实时性要求较高的应用场景可能不够理想
- Open-Falcon（push 模式）
- 是一种分布式、高性能的监控解决方案，它被用于大型的高可用性系统和广泛的云计算环境
- 优点：
- 轻量级，可以部署在物理机和虚拟机上，部署和配置足够简单
- 支持查询优化，支持多种数据源输入
- 具有简单和易于使用的图形化界面
- 缺点：
- 国内使用量较小，社区不够活跃
- 对于某些复杂的 IT 架构，Open-Falcon 在准备和安装方面可能存在困难
- 针对不同需求经验丰富的开发人员需代码调整
- Prometheus（Pull 模式）
- go 语言开发, 是可扩展的开源监控系统，用于收集存储多维度的时间序列数据
- 支持 PromQL 查询语言和提供的图形化展示工具
- 可视化和告警这些功能交由 Grafana 和 Alertmanager 等第三方产品来实现，拓展性强
- 功能上的简洁，作为一个轻量级的后起之秀，在性能和展示方面优势比较明显，对容器监控支持的非常好
- 优点：
- 可扩展性强，支持水平扩展，满足大规模监控需求
- 支持灵活的查询和查询语言，提供了丰富的查询函数和操作符
- 可以从不同的数据源收集数据，支持多维度数据聚合
- 可以轻松集成 Alertmanager 实现告警
- 缺点
- 存储机制不够灵活，大规模数据的存储和处理存在压力
- 对运维工程师的技术水平要求较高
- Zabbix（支持 pull/push 两种模式）
-
监控系统选择建议
- 功能和扩展性
- 不同的监控系统在功能和扩展性上有所差异，根据具体业务需求选择合适的功能和可扩展性。
- 适应的场景
- 不同的监控系统适用于不同的场景，如云原生环境、微服务体系等，根据具体的环境和需求选择合适的监控系统。
- 学习和维护成本
- 不同的监控系统可能需要不同的学习和维护成本，根据团队的技术能力和资源状况选择合适的监控系统。
- 社区支持和生态系统
- 选择具有活跃的社区支持和丰富的生态系统的监控系统，可以获得更好的开发、运维和解决问题的支
- 功能和扩展性
官网
-
一个开源的系统监控和警报工具，多数 Prometheus 组件是 Go 语言写的
-
为用户提供可视化仪表板、警报、告警等功能，以帮助用户快速定位和解决问题
-
现在已经成为一个独立于企业级的开源项目和一个独立的基金会（Cloud Native Computing Foundation）的一部分
-
用途
- Kubernetes 集群监控
- 使用 Prometheus 可以收集和监控 Kubernetes 集群的指标数据，例如 CPU、内存、网络等。
- 使用 Prometheus Operator 部署 Prometheus，然后通过 Grafana 可视化工具展示监控指标的仪表板
- 网络监控
- Prometheus 可以监控网络的状态和性能，例如 TCP 连接数、网络延迟和带宽利用率等
- 使用 Prometheus 的 Blackbox Exporter 插件来执行网络探测，检查网络服务是否可用
- 应用程序性能监控
- 通过 Prometheus 的客户端库可以在应用程序中嵌入指标收集代码，并收集应用程序的性能指标数据
- 例如请求数、响应时间、错误率等，帮助开发人员监控应用程序的性能，并进行调试和优化
- 数据库监控
- 可以使用 Prometheus 的 Exporter 插件监控各种类型的数据库，例如 MySQL、PostgreSQL、Redis 和 MongoDB
- Exporter 可以将数据库的指标数据转换为 Prometheus 可以处理的格式，并将其发送到 Prometheus 进行监控和警报
- 服务器监控
- 使用 Prometheus 可以监控服务器的 CPU、内存、磁盘和网络使用情况等指标，服务器上运行的各种服务的状态和性能
- 能够实时地存储和查询系统和服务的各种指标，如性能、CPU 利用率、内存使用和请求计数等。
- Kubernetes 集群监控
架构
- 什么是时序数据库
- 是一种特定类型的数据库,随时间流逝而不断产生的数据，主要用来存储时序数据
- 常见的有 InfluxDB、Kdb+、Prometheus、Graphite、TSDB
- 主要分为时间戳（timestamp）、标签（tag）、存档（filed）三大部分，按照时间顺序记录数据
- 核心组成部分
- Prometheus server
- 核心组件，负责抓取、存储和查询指标数据，提供 API 以供访问
- Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中
- 内置的 UI 界面，通过这个 UI 可以直接通过 PromQL 实现数据的查询以及可视化
- Exporter
- Prometheus 插件或独立组件，负责抓取指定服务或系统的性能指标数据
- Prometheus 原理是通过 HTTP 协议周期性抓取被监控组件的状态，输出这些被监控的组件的 Http 接口为 Exporter
- Exporter 将监控数据采集的端点通过 HTTP 服务的形式暴露给 Prometheus Server，将其公开为 HTTP 端点或指定的格式
- Prometheus server 通过轮询或指定的抓取器从 Exporter 提供的 Endpoint 端点中提取数据
- Alertmanager
- 在 Prometheus Server 中支持基于 PromQL 创建告警规则，如果满足 PromQL 定义的规则，就会产生一条告警
- Prometheus 告警管理器组件，负责管理告警规则、通知和报警策略的设置，提供第一类和第二类警报的分类管理服务
- PushGateway
- Prometheus 数据采集基于 Pull 模型进行设计，在网络环境必须要让 Prometheus Server 能够直接与 Exporter 进行通信
- 当这种网络需求无法直接满足时，就可以利用 PushGateway 来进行中转
- 通过 PushGateway 将内部网络的监控数据主动 Push 到 Gateway 当中
- Prometheus Server 则可以采用同样 Pull 的方式从 PushGateway 中获取到监控数据
- Service Discovery
- 服务发现功能，动态发现待监控的 Target，完成监控配置的重要组件
- Prometheus server
- 总结
- Prometheus 服务直接通过目标拉取数据，或者间接地通过中间网关拉取数据
- 并通过一定规则进行清理和整理数据，把得到的结果存储到新的时间序列中
- 利用 PromQL 和其他 API 可视化地展示收集的数据
部署 Prometheus Server
prometheus-2.43.0.linux-amd64.tar.gz
go1.17.6.linux-amd64.tar.gz
配置 go 环境变量（Prometheus 使用 go 语言开发）
1#解压
2tar -zxvf go1.17.6.linux-amd64.tar.gz
3
4#配置环境变量
5echo "export PATH=$PATH:/usr/local/software/temp/go/bin" >> /etc/profile
6
7#立刻生效
8source /etc/profile
9
10#测试 go是否安装成功
11go version
安装 Prometheus
1#解压
2tar -zxvf prometheus-2.43.0.linux-amd64.tar.gz
3
4#重命名
5mv prometheus-2.43.0.linux-amd64 prometheus
6
7#进入目录启动
8./prometheus --config.file=./prometheus.yml
9
10# 动态更新（热更新：prometheus里面经常需要修改配置）
11# 启动时在参数中加入******--web.enable-lifecycle****** (该参数默认关闭)
12# 启动， &表示需要守护进程方式运行，不然退出终端则进程消失
13./prometheus --config.file=./prometheus.yml --web.enable-lifecycle
14
15#动态更新配置（不需要重启服务！！！）
16curl -X POST http://localhost:9090/-/reload
17
18#查看是否启动成功，默认端口9090
19lsof -i:9090
20
21# 关闭防火墙
22systemctl stop firewalld.service
23
24#访问 prometheus ,阿里云网络安全组开放端口
25 指标数据
26 http://192.168.10.20:9090/metrics
27 图界面
28 http://192.168.10.20:9090/
Prometheus 操作面板和常见配置讲解
- Prometheus 的目录结构
- console_libraries：用于存储用于在 Prometheus 控制台上显示的 JavaScript 库。
- consoles：用于存储用于在 Prometheus 控制台上显示的控制台文件，其中包括查询和图形定义。
- data：用于存储 Prometheus 的磁盘持久化数据。
- LICENSE：Prometheus 的许可证文件。
- NOTICE：版权声明文件。
- prometheus：存储 Prometheus 二进制文件及其相关文件的目录。
- prometheus.yml：Prometheus 的配置文件。
- promtool：Prometheus 的命令行工具，用于检查配置文件是否正确以及生成表达式的值。
1[root@localhost prometheus]# tree
2.
3├── console_libraries
4│ ├── menu.lib
5│ └── prom.lib
6├── consoles
7│ ├── index.html.example
8│ ├── node-cpu.html
9│ ├── node-disk.html
10│ ├── node.html
11│ ├── node-overview.html
12│ ├── prometheus.html
13│ └── prometheus-overview.html
14├── data
15│ ├── chunks_head
16│ ├── lock
17│ ├── queries.active
18│ └── wal
19│ ├── 00000000
20│ └── 00000001
21├── LICENSE
22├── NOTICE
23├── prometheus
24├── prometheus.yml
25└── promtool
配置文件介绍
1#全局配置，默认，可以被覆盖
2global:
3 scrape_interval: 15s #全局的抓取间隔
4 scrape_timeout: 10s #抓取超时时间
5 evaluation_interval: 15s #评估间隔
6
7#告警配置
8alerting:
9 alertmanagers: #告警管理器
10 - follow_redirects: true #是否启用重定向
11 enable_http2: true #是否启用HTTP2
12 scheme: http
13 timeout: 10s
14 api_version: v2 #指定Alertmanager的API版本，此处为v2
15 static_configs: #告诉Prometheus哪些目标是静态的（即不会更改），如果有多个目标，则可以在targets中指定多个地址。
16 - targets: []
17
18#抓取配置
19scrape_configs:
20- job_name: prometheus #任务名称
21 honor_timestamps: true #指标的时间戳应该由服务器提供，而不是客户端在发送指标时提供的时间戳
22 scrape_interval: 15s #抓取任务的时间间隔，即每15秒抓取一次。
23 scrape_timeout: 10s #抓取任务的超时时间，单位为秒，即每个目标最多等待10秒钟
24 metrics_path: /metrics #抓取指标的路径
25 scheme: http #指定抓取时使用的协议，默认为http
26 follow_redirects: true #是否启用重定向。在此处启用
27 enable_http2: true #是否启用HTTP2
28 static_configs:
29 - targets:
30 - 120.24.7.58:9090 #目标配置，告诉Prometheus哪些目标需要抓取，如果有多个目标，则可以在targets中指定多个地址
31
32#此处抓取了一个名为prometheus的任务，每隔15秒抓取一次120.24.7.58:9090上的/metrics路径，超时时间为10秒
监控分层和 metric 指标
Prometheus 通过 Pull 方式采集指标数据，适用于分布式架构、云原生环境和微服务体系等场景
互联网公司监控和指标很多，按照顺序分层归类：系统层、应用层、业务层，这些 Prometheus 都可以完成
- 这些指标不是绝对的，应该根据企业的业务和系统选择合适的指标
- 系统和网络层
- 主要关注底层基础设施的状态和事件，以确保服务器、网络、CPU 和存储设备等运行正常，提供稳定的资源支持。
- 操心系统常见指标
- CPU 利用率：服务器上 CPU 主要的核心使用率情况。
- 内存使用率：服务器内存使用情况，包括已使用、空闲等情况。
- 网络带宽利用率：服务器网络使用度，包括网卡、负载均衡、网络连接等的带宽使用情况。
- 硬盘 I/O 读写速度：磁盘读写速率。
- 硬盘容量：服务器硬盘容量使用情况，包括已使用、空闲等情况。
- ...
- 网络常见指标
- 带宽利用率：网络带宽利用率评估，包括上传和下载比率。
- 包丢失率：测量包在传输中丢失的数量和百分比。
- 网络流量：流经网络的实时数据量和数据流量。
- 网络错误率：网络传输中发生的错误数量和百分比。
- 连接数：网络连接总数。
- ...
- 应用层（业务应用程序、中间件应用程序等）
- 关注整体服务的质量和运行状态，能够及时预测系统运行瓶颈，保证产品的高效和用户体验
- 常见指标（Java 为例）
- 错误率：应用程序产生错误的请求占总数的百分比。
- 线程实例数：当前在应用程序中运行的线程实例数量。
- 堆内存使用率：应用程序中 Java 虚拟机（JVM）分配的内存占用的百分比。
- 平均延迟时间：从请求到响应开始的时间差。
- 垃圾回收时间：在 JVM 中收集不再使用的内存对象所需的时间。
- 响应代码：HTTP 请求成功或失败代码。
- ...
- 业务层
- 重点关注业务运营的分析和结果，通过监控平台运营情况和各种配置，获取更多业务数据
- 及时发现行业发展趋势，指引业务方向，实现全方位监控、预测和干预
- 指标
- GMV 销售额：项目特定时间内总的销售额。
- 日活、月活：日活跃用户数、月活跃用户数
- 客单价：平均每个订单的金额
- 支付成功率：成功支付订单和总订单的比率
- 订单量：每次交易中的订单数量。
- 购物车转化率：加入购物车商品与实际付款之间的比率。
- 点击率：网站广告点击率。
- ...
- 人工监控：客服和产品运营接收用户反馈（大厂里面的小部门挺多的）
- 技术人员一定要关注技术 + 业务 两个指标
- 技术指标（技术人员关注）
- 上述的系统 + 网络指标、应用指标
- 业务指标（产品和运营人员关注）
- 上述的业务指标就是
- 技术指标（技术人员关注）
Exporter：Node-Exporter
什么是 Prometheus 的 Exporter
-
向 Prometheus 提供监控样本数据的程序都可以被称为一个 Exporter
-
是一种用于将不同数据源的指标提供给 Prometheus 进行收集和监控的工具。
-
运行在应用程序、计算机、网络设备或者其他系统上的代码，它可以将系统的指标信息以一种标准格式公开
-
将指标数据公开为 HTTP 端点或者指定的格式（如 Redis、JMX 等），Prometheus 然后可以通过轮询或指定的抓取器
-
总结
- Exporter 是 Prometheus 的指标数据收集组件，负责从目标 Jobs 收集数据
- 并把收集到的数据转换为 Prometheus 支持的时序数据格式
- 只负责收集，并不向 Server 端发送数据，而是等待 Prometheus Server 主动抓取
-
Prometheus 社区以及其他团队开发了大量的 Exporter，覆盖了许多不同类型的系统和服务
- Node Exporter、MySQL Exporter、Redis Exporter、MongoDB Exporter、Nginx Exporter...
-
使用方式
- 在主机上安装了一个 Exporter 程序，该程序对外暴露了一个用于获取当前监控样本数据的 HTTP 访问地址
- Prometheus 通过轮询的方式定时从这些 Target 中获取监控数据样本，并且存储在数据库当中
- 所有的 Exporter 程序都需要按照 Prometheus 的规范，返回监控的样本数据
案例实战 node_exporter
node-export 主要用来做Linux服务器监控，比如服务器的进程数、消耗了多少 CPU、内存，磁盘空间，iops等资源。
node_exporter-1.6.0.linux-amd64
1#解压
2tar -zxvf node_exporter-1.6.0.linux-amd64.tar.gz
3
4#进到目录里面，启动
5nohup ./node_exporter &
6
7#确认端口
8lsof -i:9100
9
10# 访问exporter（成功！！！）
11http://192.168.10.21:9100/metrics
12
13
14# Prometheus服务器中添加被监控机器的配置(target的也可以写ip)
15[root@localhost prometheus]# vim prometheus.yml
16 - job_name: 'soulboy-agent-1'
17 static_configs:
18 - targets: ['192.168.10.21:9100']
19
20# 动态更新配置
21[root@localhost prometheus]# curl -X POST http://192.168.10.20:9090/-/reload
Prometheus 时序数据语法
所有的 Exporter 程序都需要按照 Prometheus 的规范，返回监控的样本数据
- 比如 Node Exporter，当访问/metrics 地址时会返回内容和本身 Prometheus 协议保持一致即可
- Prometheus 协议格式主要由三个部分组成，Prometheus 会对 Exporter 响应的内容逐行解析
- 样本的一般注释信息（HELP）
- 样本的类型注释信息（TYPE）
- 样本
1# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
2# TYPE go_gc_duration_seconds summary
3go_gc_duration_seconds{quantile="0"} 6.884e-06
4go_gc_duration_seconds{quantile="0.25"} 8.997e-06
5go_gc_duration_seconds{quantile="0.5"} 9.849e-06
6go_gc_duration_seconds{quantile="0.75"} 1.1542e-05
7go_gc_duration_seconds{quantile="1"} 1.1542e-05
8go_gc_duration_seconds_sum 3.7272e-05
9go_gc_duration_seconds_count 4
-
Prometheus 的时序数据模型:
-
指标（Metric）
- 一个指标是一个具有唯一名称的时间序列数据集合。
- 指标的完整名称由一个必需的名称和可选的标签键-值对组成，用冒号分隔
1http_requests_total -
标签（Label）
- 标签用于区分相同指标的不同时间序列，一个时间序列可以有多个标签，标签由键-值对组成，通过逗号分隔
1http_requests_total{method="GET", status="200"} -
样本（Sample）
- 样本是时间序列的数据点，包括时间戳和对应的值, 样本由指标和标签组成，通过空格分隔
1http_requests_total{method="GET", status="200"} 500 1626866123000
-
-
案例一
- 业务系统，需要监控 HTTP 请求的总数，不同请求方法和状态码的请求次数，可以使用以下指标来描述这些数据
- 指标名称为
http_requests_total，表示 HTTP 请求的总数。 - 可以使用标签来区分不同请求方法和状态码。例如，使用
method标签表示请求方法，使用status标签表示状态码。 - 样本是具体的指标值和时间戳组成。例如，将
http_requests_total指标和标签组合成以下样本：
- 指标名称为
1http_requests_total{method="GET", status="200"} 100 1626866123000 2http_requests_total{method="POST", status="200"} 50 1626866123000 3http_requests_total{method="GET", status="404"} 10 1626866123000- 表示在时间戳为 1626866123000 时
- GET 方法的 200 状态码的请求总数为 100 次
- POST 方法的 200 状态码的请求总数为 50 次
- GET 方法的 404 状态码的请求总数为 10 次
- 使用这种时序数据模型，可以方便地进行数据查询和分析
- 业务系统，需要监控 HTTP 请求的总数，不同请求方法和状态码的请求次数，可以使用以下指标来描述这些数据
-
例如：可以通过以下 PromQL 查询语句统计不同请求方法的请求总数
1sum(http_requests_total) by (method) -
案例二
- Linux 服务器监控相关的 CPU 使用率，指标名称
node_cpu_seconds_total， 数据来源cat /proc/cpuinfo - 指标是 counter 类型的递增指标，指 CPU 每种模式下所花费的时间
- 结合内置函数 统计 CPU 使用率
1(1 -sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) / sum(rate(node_cpu_seconds_total[1m])) by (instance) )
- Linux 服务器监控相关的 CPU 使用率，指标名称
统计指标
数值指标
1、计数器 counter
- 计数器是一个递增的整数型指标，用于表示累计数量。
- 计数器在增长时，只能累加，不会减少。
- 一般用于统计请求次数、错误次数等场景。
案例：node_network_receive_packets_total 表示网络接收的数据包总数。
2、仪表盘 gauge
- 仪表盘是一个可变的数值指标，用于表示某个瞬时值
- 可变大，可变小。
- 仪表盘可以随着时间增加或减少，可以用于表示当前连接数、温度等持续变化的指标。
案例：统计 CPU 使用率
(1 -sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) / sum(rate(node_cpu_seconds_total[1m])) by (instance) )
统计指标
3、直方图 histogram
是一种直方图类型，可以观察到指标在各个不同的区间范围的分布情况，例如请求的延迟分布。
它会将这些事件按照不同的桶（bucket）进行分组，并收集每个桶内事件的数量，可以用于分析某个操作的响应时间。
案例：prometheus_http_request_duration_seconds_bucket{handler="/targets"}
- 用于查询路径为"/targets"相对应的 Prometheus HTTP 请求持续时间指标的直方图桶信息
- 记录 HTTP 请求的持续时间信息，并按照不同的时间区间（桶）进行分组。
1prometheus_http_request_duration_seconds_bucket{handler="/targets", le="0.1"} 2
2prometheus_http_request_duration_seconds_bucket{handler="/targets", le="0.5"} 2
3prometheus_http_request_duration_seconds_bucket{handler="/targets", le="1"} 2
- 在持续时间小于等于 0.1 秒的桶中有 20 个请求，在持续时间小于等于 0.5 秒的桶中有 50 个请求，以此类推。
1### 注意 2* 在le=“0.2”这个桶中是包含了 le=“0.1”这个桶的数据 3* 如果想要拿到0.1毫秒到0.2毫秒的请求数量，可以通过两个桶相减得到 - 通过这样的查询，可以了解"/targets"处理程序路径下不同持续时间区间的 HTTP 请求的数量。
- 对于分析程序路径的请求延迟和性能非常有用
4、摘要 summary
- 用于测量事件的分布情况，类似于直方图，和 Histogram 区别在于，Summary 直接存储的就是百分位数
- 摘要适合于分析事件的分布和响应时间的百分比。
案例：
go_gc_duration_seconds，Go 语言应用程序的指标，用于表示垃圾回收（Garbage Collection）的持续时间。
Prometheus 监控 Mysql8
1### 部署mysql8
2docker run \
3 -p 3307:3306 \
4 -e MYSQL_ROOT_PASSWORD=abc1024.pub \
5 --name mysql \
6 --restart=always \
7 -d mysql:8.0
8
9### 配置mysql_exporter(对外暴露端口9104)监控MySQL，数据源格式：DATA_SOURCE_NAME="账号:密码@(ip:端口)
10docker run -d --name mysql-exporter -p 9104:9104 -e DATA_SOURCE_NAME="root:abc1024.pub@(192.168.10.21:3307)/mysql" prom/mysqld-exporter:v0.14.0
11
12### 查看exporter日志
13[root@localhost ~]# docker logs -f mysql-exporter
14
15### mysqld_exporter 的 metrics 默认端口 9104
16http://192.168.10.21:9104/metrics
17
18### Prometheus服务器中添加被监控机器的配置
19[root@localhost ~]# vim /tmp/prometheus/prometheus.yml
20 - job_name: 'mysql-1'
21 static_configs:
22 - targets: ['192.168.10.21:9104']
23
24### 动态更新配置
25[root@localhost prometheus]# curl -X POST http://192.168.10.20:9090/-/reload
26
27### 查看Web UI界面的target和configuration是否有对应的数据
28* 常见的关键指标
29 * `mysql_up`：表示 MySQL 数据库的可用性，如果值为1，则表示数据库连接正常；如果值为0，则表示数据库连接不可用。
30 * `mysql_global_status_threads_connected`：表示当前活动的连接数量。
31 * `mysql_global_status_threads_running`：表示当前正在执行的线程数量。
32 * `mysql_global_variables_max_connections`：表示 MySQL 数据库允许的最大连接数。
33 * `mysql_global_status_queries`：表示 MySQL 数据库执行的总查询次数。
34 * `mysql_global_status_slow_queries`：表示慢查询的数量。
35 * `mysql_global_status_innodb_buffer_pool_read_requests`：表示从 InnoDB 缓冲池中读取的请求数量。
36
37* 注意
38 * 实际指标名称和标签可能会因使用的 MySQL 版本、Exporter 版本以及具体的配置变化而有所不同
39 * 只是一部分常见的关键指标，在实际使用中还有许多其他的指标进行监控分析。
40 * 通过这些关键指标，可以了解 MySQL 数据库的连接情况、查询性能、缓冲池状态等重要数据。
Prometheus 监控 Redis7
1### 部署Redis7.X，并指定密码
2docker run -itd --name redis -p 6379:6379 redis:7.0.8 --requirepass 123456
3
4### 配置Redis-Exporter，指定相关redis服务端IP和密码
5docker run -d --name redis_exporter -p 9121:9121 oliver006/redis_exporter --redis.addr redis://192.168.10.21:6379 --redis.password '123456'
6
7
8### redis_exporter 的 metrics 默认端口 9121
9http://192.168.10.21:9121/metrics
10
11### Prometheus服务器中添加被监控机器的配置
12[root@localhost ~]# vim /tmp/prometheus/prometheus.yml
13 - job_name: 'redis-1'
14 static_configs:
15 - targets: ['192.168.10.21:9121']
16
17### 动态更新配置
18[root@localhost prometheus]# curl -X POST http://192.168.10.20:9090/-/reload
19
20### 查看Web UI界面的target和configuration是否有对应的数据
21### 常见的 Redis Exporter 关键指标的示例
22常见的 Redis Exporter 关键指标的示例
23
24* `redis_up`：表示 Redis 服务器的可用性，如果值为1，则表示服务器连接正常；如果值为0，则表示服务器连接不可用。
25* `redis_connected_clients`：表示当前连接到 Redis 服务器的客户端数量。
26* `redis_memory_used_bytes`：表示 Redis 使用的内存总量。
27* `redis_commands_processed_total`：表示 Redis 服务器处理的命令总数。
28* `redis_keyspace_hits`：表示 Redis 服务器的键命中次数。
29* `redis_keyspace_misses`：表示 Redis 服务器的键未命中次数。
30* `redis_instance_info`：表示 Redis 服务器的各种信息，如服务器版本、机器信息、角色、端口等信息
Prometheus 监控 RabbitMQ
- RabbitMQ3.8.0 之前版本，使用单独的下载插件 prometheus_rabbitmq_exporter 来向 Prometheus 公开指标
- RabbitMQ3.8.0 版开始，RabbitMQ 附带了内置的 Prometheus＆Grafana 支持，但是默认没开启
1### 部署rabbitmq
2docker run -d --hostname rabbit_host1 --name rabbit -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=123456 -p 15672:15672 -p 5672:5672 -p 15692:15692 rabbitmq:3.8.9-management
3
4参数说明
5-d 以守护进程方式在后台运行
6-p 15672:15672 management 界面管理访问端口
7-p 5672:5672 amqp 访问端口
8-p 15692:15692 Prometheus监控相关的端口
9--name:指定容器名
10--hostname 设定容器的主机名
11-e 参数 RABBITMQ_DEFAULT_USER 用户名 RABBITMQ_DEFAULT_PASS 密码
12
13
14### 进入容器内部开启监控端点
15docker exec -it [rabbitmq container id] bin/sh
16docker exec -it rabbit bin/sh
17# 进入容器开启 Exporter
18rabbitmq-plugins enable rabbitmq_prometheus
19
20### Prometheus服务器中添加被监控机器的配置
21[root@localhost ~]# vim /tmp/prometheus/prometheus.yml
22 - job_name: 'rabbitmq-1'
23 static_configs:
24 - targets: ['192.168.10.21:15692']
25
26### 动态更新配置
27[root@localhost prometheus]# curl -X POST http://192.168.10.20:9090/-/reload
28
29
30### 查看Web UI界面的target和configuration是否有对应的数据
31常见的关键指标
32* `rabbitmq_queue_messages`: RabbitMQ队列中的消息数量。
33* `rabbitmq_queue_messages_ready`: RabbitMQ队列中准备就绪的消息数量。
34* `rabbitmq_connections`: RabbitMQ服务器的连接数量。
35* `rabbitmq_queue_consumers`: RabbitMQ队列的消费者数量。
SpringBoot3 监控 Actuator
- Spring Boot Actuator 是 Spring Boot 提供的一个可选模块，用于在运行时监控和管理 Spring Boot 应用程序
- 通过 Actuator 可以暴露应用程序的状态、统计信息、日志和其他有用的运行时信息
- 本地 JDK17 安装(SpringBoot3.X 要求 JDK17)，没相关环境的可以去 Oracle 官网安装下 JDK17
- 项目开发，快速创建 **https://start.spring.io/
添加依赖
1<dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-test</artifactId>
4 <scope>test</scope>
5 </dependency>
6
7 <dependency>
8 <groupId>org.springframework.boot</groupId>
9 <artifactId>spring-boot-starter-web</artifactId>
10 </dependency>
11
12 <!-- actuator -->
13 <dependency>
14 <groupId>org.springframework.boot</groupId>
15 <artifactId>spring-boot-starter-actuator</artifactId>
16 </dependency>
默认只暴露 health 端点，可以配置更多端点
http://localhost:8080/actuator
1// 20231004164926
2// http://localhost:8080/actuator
3
4{
5 "_links": {
6 "self": {
7 "href": "http://localhost:8080/actuator",
8 "templated": false
9 },
10 "health": {
11 "href": "http://localhost:8080/actuator/health",
12 "templated": false
13 },
14 "health-path": {
15 "href": "http://localhost:8080/actuator/health/{*path}",
16 "templated": true
17 }
18 }
19}
配置 application.properties
1#暴露指定端点
2#management.endpoints.web.exposure.include=env,info,config,health
3
4#暴露全部
5management.endpoints.web.exposure.include=*
http://localhost:8080/actuator
1http://localhost:8080/actuator/metrics
2http://localhost:8080/actuator/metrics/jvm.buffer.memory.used
现有的 Actuator 格式并非 Promethus 支持的格式，所以需要加入相关 Promethus 支持的包统一格式
1<!--整合prometheus-->
2 <dependency>
3 <groupId>io.micrometer</groupId>
4 <artifactId>micrometer-registry-prometheus</artifactId>
5 </dependency>
会新增 prometheus 端点：http://localhost:8080/actuator/prometheus
1# HELP jvm_memory_usage_after_gc_percent The percentage of long-lived heap pool used after the last GC event, in the range [0..1]
2# TYPE jvm_memory_usage_after_gc_percent gauge
3jvm_memory_usage_after_gc_percent{area="heap",pool="long-lived",} 0.0033393502235412598
4# HELP executor_pool_max_threads The maximum allowed number of threads in the pool
5# TYPE executor_pool_max_threads gauge
6executor_pool_max_threads{name="applicationTaskExecutor",} 2.147483647E9
7# HELP jvm_memory_max_bytes The maximum amount of memory in bytes that can be used for memory management
8# TYPE jvm_memory_max_bytes gauge
9jvm_memory_max_bytes{area="heap",id="G1 Survivor Space",} -1.0
10jvm_memory_max_bytes{area="heap",id="G1 Old Gen",} 8.589934592E9
11...
关键指标说明
指标的具体名称和标签可能会因SpringBoot版本、监控工具和配置而有所不同
jvm_memory_max_bytes: JVM 各个区域的最大可用内存（以字节为单位）jvm_memory_used_bytes: JVM 使用的内存量（以字节为单位）jvm_threads_states_threads: JVM 线程状态的数量process_cpu_usage: 进程的 CPU 使用率。process_start_time_seconds: 进程启动的时间戳。http_server_requests_seconds: HTTP 请求的响应时间。tomcat_sessions_active_current: 当前活动的 Tomcat 会话数量。system_cpu_usage: 系统的 CPU 使用率
Maven 打成 jar 包
arch-web-0.0.1-SNAPSHOT.jar
1### maven打包
2PS D:\Project\arch-web> cd .\arch-web\
3PS D:\Project\arch-web\arch-web> pwd
4
5Path
6----
7D:\Project\arch-web\arch-web
8
9
10PS D:\Project\arch-web\arch-web> mvn install
11
12### 本地也可以进行测试（如果本地都启动不成功就没有必要上传）
13PS D:\Project\arch-web\arch-web\target> cd D:\Project\arch-web\arch-web\target
14PS D:\Project\arch-web\arch-web\target> java -jar .\arch-web-0.0.1-SNAPSHOT.jar
15
16### jar包上传CentOS7，守护进程启动
17[root@localhost software]# nohup java -jar arch-web-0.0.1-SNAPSHOT.jar &
18
19### 查看日志
20[root@localhost software]# tail nohup.out
212023-10-04T17:52:21.738+08:00 INFO 4586 --- [ main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 1105 ms
222023-10-04T17:52:22.323+08:00 INFO 4586 --- [ main] o.s.b.a.e.web.EndpointLinksResolver : Exposing 14 endpoint(s) beneath base path '/actuator'
232023-10-04T17:52:22.398+08:00 INFO 4586 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
242023-10-04T17:52:22.434+08:00 INFO 4586 --- [ main] soulboy.pub.archweb.ArchWebApplication : Started ArchWebApplication in 2.402 seconds (process running for 2.739)
CentOS7 部署 JDK17（运行 jar 包）
1### 部署JDK17
2[root@localhost software]# mkdir /usr/local/software
3[root@localhost software]# tar -zxvf jdk-17_linux-x64_bin.tar.gz
4[root@localhost software]# mv jdk-17.0.7 /usr/local/software/jdk17
5[root@localhost ~]# vim /etc/profile
6JAVA_HOME=/usr/local/software/jdk17
7CLASSPATH=$JAVA_HOME/lib/
8PATH=$PATH:$JAVA_HOME/bin
9export PATH JAVA_HOME CLASSPATH
10
11#保存生效
12[root@localhost ~]# source /etc/profile
13[root@localhost ~]# java -version
14java version "17.0.7" 2023-04-18 LTS
15Java(TM) SE Runtime Environment (build 17.0.7+8-LTS-224)
16Java HotSpot(TM) 64-Bit Server VM (build 17.0.7+8-LTS-224, mixed mode, sharing)
Prometheus 整合配置
1### 修改配置文件
2[root@localhost ~]# vim /tmp/prometheus/prometheus.yml
3 - job_name: "springboot"
4 scrape_interval: 15s
5 scrape_timeout: 10s
6 metrics_path: '/actuator/prometheus'
7 static_configs:
8 - targets: ['192.168.10.21:8080']
9
10### 动态更新配置
11[root@localhost prometheus]# curl -X POST http://192.168.10.20:9090/-/reload
12
13### 访问springboot actuator
14http://192.168.10.21:8080/actuator/prometheus
15# HELP system_cpu_count The number of processors available to the Java virtual machine
16# TYPE system_cpu_count gauge
17system_cpu_count 2.0
18# HELP jvm_memory_used_bytes The amount of used memory
19# TYPE jvm_memory_used_bytes gauge
20jvm_memory_used_bytes{area="nonheap",id="CodeHeap 'profiled nmethods'",} 8090496.0
21jvm_memory_used_bytes{area="heap",id="G1 Survivor Space",} 2576112.0
22jvm_memory_used_bytes{area="heap",id="G1 Old Gen",} 1.4966784E7
23jvm_memory_used_bytes{area="nonheap",id="Metaspace",} 3.5131496E7
24jvm_memory_used_bytes{area="nonheap",id="CodeHeap 'non-nmethods'",} 1267840.0
25jvm_memory_used_bytes{area="heap",id="G1 Eden Space",} 1.3631488E7
26jvm_memory_used_bytes{area="nonheap",id="Compressed Class Space",} 4561584.0
27jvm_memory_used_bytes{area="nonheap",id="CodeHeap 'non-profiled nmethods'",} 2313472.0
28# HELP executor_completed_tasks_total The approximate total number of tasks that have completed execution
29# TYPE executor_completed_tasks_total counter
30executor_completed_tasks_total{name="applicationTaskExecutor",} 0.0
31# HELP jvm_threads_daemon_threads The current number of live daemon threads
32# TYPE jvm_threads_daemon_threads gauge
33jvm_threads_daemon_threads 17.0
34
35### prometheus web端查看
36http://192.168.10.20:9090/
PromQL
什么是 PromQL
- Prometheus 提供了内置的数据查询语言 PromQL，全称为 Prometheus Query Language
- 是 Prometheus 自己开发的数据查询 DSL 语言，可以让用户实时选择和聚合时间序列数据
- PromQL 是对指标(Metric)的查询/聚合/过滤的处理，Metric 的语法格式
<metric name>{<label name>=<label value>, ...}
条件筛选
1### 不带条件（两种写法都一样）
2jvm_classes_loaded_classes
3jvm_classes_loaded_classes{}
4
5### 带条件
6jvm_classes_loaded_classes{job="springboot"}
7jvm_classes_loaded_classes{job!="springboot-test"}
不完全匹配
1### 表示选择那些标签符合正则表达式定义的时间序列
2label=~regx
3
4### 进行排除
5label!~regx
6
7### 示例
8jvm_classes_loaded_classes{job =~ "springboot|java|javaweb"}
时间范围选择器
1### 支持多种时间单位
2s - 秒
3m - 分钟
4h - 小时
5d - 天
6w - 周
7y - 年
8
9### 示例
10# 过去五分钟的数据
11up[5m]
12
13
14# 一天之前的数据
15up[1d]
数学运算符
- +(加法)、-(减法) 、*(乘法)、/(除法)、%(求余)、^(幂运算)
布尔运算符
- ==(相等)、!=(不相等)、>(大于)、<(小于)、>=(大于等于)、<=(小于等于)
1### 筛选出请求次数超过 100 次的接口
2prometheus_http_requests_total > 100
集合运算符
- and(并且-交集)、or(或者-并集)、unless(除非-补集)
聚合操作符
1### 计算所有接口的请求数量总和
2sum(prometheus_http_requests_total{})
3
4### 匹配其中样本值为最小的时间序列
5min(prometheus_http_requests_total{})
6
7### 匹配其中样本值为最大的时间序列
8max(prometheus_http_requests_total{})
9
10### 求出所有样本的平均值
11avg(prometheus_http_requests_total{})
12
13### 请求数后 5 位的时序样本数据
14bottomk (5,prometheus_http_requests_total{})
15
16### 请求数前 5 位的时序样本数据
17topk (5,prometheus_http_requests_total{})
18
19### 计算一共有几条数据，和sum不一样，sum是对value进行求和
20count (prometheus_http_requests_total{})
21
22### 样本值升序排序
23sort(prometheus_http_requests_total)
24
25### 样本值倒序排序 (指定时间区间后，计算该指标在最早和最晚时间的值的差，即增长量)
26sort_desc(prometheus_http_requests_total)
27
28### 计算在过去1分钟内CPU使用时间的指标增长量
29* 如果除以相关时间范围，则可以计算出增长率，和rate函数效果一样
30* 单使用rate或者increase函数去计算样本的平均增长速率，容易陷入“长尾问题”，无法反应在时间窗口内样本数据的突发变化
31increase(node_cpu_seconds_total[1m])
32
33### 关键字（分组，类似 SQL 中的 group by）
34* without 用于从计算结果中移除列出的标签，而保留其它标签
35# 在prometheus_http_requests_total指标中,排除 instance,handler,job，来进行分组求和
36sum(prometheus_http_requests_total{}) without (instance,handler,job)
37
38* by 计算结果 中只保留列出的标签，其余标签则移除
39# 在prometheus_http_requests_total指标中根据code来分组求和
40sum(prometheus_http_requests_total{}) by (code)
41
42### 指标值的变化速率：irate函数的图像峰值变化大，rate函数变化较为平缓
43* rate函数的图像峰值变化大，rate函数变化较为平缓**
44* 使用`irate`函数可以更精确地捕捉到短期内的变化，而`rate`函数则更适合用于观察长周期的趋势
45* rate适合缓慢变化的计数器，使用了平均值，很容易把峰值削平，除非把时间间隔设置得足够小，就能够减弱这种效应
46
47例如，计算过去5分钟内节点的网络接收字节数和传输字节数的变化速率
48
49# rate适用于根据一定时间范围内的样本计算速率, 也就是我们常说的QPS，函数原型为：rate(vector range-vector)
50 rate只是算出来某个时间区间内的【平均速率】，没办法反映突发变化
51 假设在一分钟的时间区间里，前50秒的请求量都是0到10左右，但最后10秒请求量暴增到200以上，则不能很好反映变化
52rate(node_network_receive_bytes_total[5m]) + rate(node_network_transmit_bytes_total[5m])
53
54# irate函数以瞬间速率的方式返回时间序列的变化率（每秒），它适用于在一段时间内考虑单个样本的变化，会考虑时间范围内最近两个样本之间的变化
55 函数原型为：`irate(vector range-vector)`
56irate(node_network_receive_bytes_total[5m]) + irate(node_network_transmit_bytes_total[5m])
统计 CPU 使用率
需求
计算服务器的 CPU 的使用率(1 分钟)
指标
node_cpu_seconds_total 用来统计 CPU 每种模式下所花费的时间，不加条件则是 CPU 使用时间总和
思路
- 计算 CPU 使用率，简单的说就是除 idle 状态之外的 CPU 时间除以 CPU 总时间
- CPU 的使用率 = (所有非空闲状态 CPU 使用时间总和 )/(所有状态 CPU 时间总和)
- 用 prometheus 的计算思路就是：1- idle/total
1#过滤出CPU空闲的时间
2node_cpu_seconds_total{mode="idle"}
3
4#统计idle状态时长
5sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by (instance)
6
7#统计总时长
8 #sum函数是将所有CPU核数时间相加，没有按照主机进行聚合，就需要引入 by (instance) 函数,即分组
9 #by (instance) 它会把sum求和到一起的数值按照指定方式进行拆分，instance代表的是机器名
10 #如果不写by (instance)的话就需要在{ }中写明需要哪个实例的数据
11sum(increase(node_cpu_seconds_total[1m])) by (instance)
12
13#计算出idle时长和总时长，CPU使用率的表达式
14(1 - sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) / sum(increase(node_cpu_seconds_total[1m])) by (instance) ) * 100
Grafana
数据源广:
-
官网地址：https://grafana.com/
-
用 Go 语言开发的开源数据可视化工具，可以做数据监控和数据统计，带有告警功能。
-
可视化
- 支持快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件
- 比如热图、折线图、图表等多种展示方式
- Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch 和 KairosDB 等。
- 支持混合数据源，在同一个图中混合不同的数据源，可以根据每个查询指定数据源，甚至适用于自定义数据源。
- 报警
- 支持可视方式定义最重要指标的警报规则，Grafana 将不断计算并发送通知，在数据达到阈值时进行告警
- 避免混淆各个组件主要的作用概念
- Exporter 数据生产者，采集需要监控的数据
- Prometheus 普罗米修斯时序数据库，用来存储和查询的监控数据，从 Exporter 上拉取
- Grafana 可视化工具仪表盘
部署 grafana
1### docker部署grafana
2docker run -d -p 3000:3000 --name=soulboy-grafana grafana/grafana:8.1.5
3
4### URL admin 密码：admin
5http://192.168.10.20:3000/login
配置数据源
-
用户
- Grafana 里面用户有三种角色 admin,editor,viewer
- admin 权限最高，可以执行任何操作，包括创建用户，新增 Datasource、DashBoard。
- editor 角色不可以创建用户，不可以新增 Datasource，可以创建 DashBoard。
- viewer 角色仅可以查看 DashBoard
-
组织
- 每个用户可以拥有多个 Organization，用户登录后可以在不同的 Organization 之间切换
- 不同的 Organization 之间完全不一样，包括 datasource，dashboard 等都不一样
- 创建一个 Organization 就相当于开了一个全新的视图，所有的 datasource，dashboard 等都要再重新开始创建
-
数据源 (Data Source )
- Grafana 支持多种不同的时序数据库数据源，对每种数据源提供不同的查询方法，而且能很好的支持每种数据源的特性
- 可以将多个数据源的数据合并到一个单独的仪表板上
-
仪表盘（Dashboard）
- 最重要 UI 界面 仪表盘，通过数据源定义好可视化的数据来源，Dashboard 来组织和管理数据可视化图表
- 仪表盘可以视为一组一个或多个面板组成的一个集合，来展示各种各样的面板。
-
面板 (Panel)
- Panel 在一个 Dashboard 中一个最基本的可视化单元为一个 Panel（面板）
- 通过 Panel 的 Query Editor（查询编辑器）为每一个 Panel 添加查询的数据源以及数据查询方式，每一个 Panel 都是独立的
-
探索 (Explore)
最佳实践 Grafana 应用市场-高效导入仪表盘
-
需求
- Grafana 支持很多数据源，但是不同中间件太多，每个 panel 又很多选项
- 一个个配置对于开发新手和老手都是比较麻烦的，能不能达到复用呢？
-
Grafana 应用市场
- 地址：https://grafana.com/grafana/dashboards/
- 是 Grafana 社区和其他用户分享的可装载的仪表板和面板集合
- 当安装应用程序市场模板时，Grafana 会自动安装和配置自定义仪表板面板，并可以自动设置相关数据源
- 应用市场模板可以是来自 Grafana 仓库、别人的 GitHub 仓库、开源项目或个人创建的
- Grafana 模板使得共享可装载的仪表板变得容易，从而帮助用户减少了工作量，并促进了最佳设置和最佳配置的使用
Grafana 的 Alert 监控告警
-
需求
- Alertmanager 是 Prometheus 的一个组件，用于定义和发送告警通知，Grafana 也有告警功能，两个组件各有优缺点
- Grafana 更适合于互联网领域的常规监控系统，而 Alertmanager 更适合于大规模或更复杂的告警处理场景
- 如果需要告警功能并且已经使用 Grafana 进行数据可视化，则可以使用 Grafana 作为告警处理工具
-
两者对比
- Grafana
- 优点
- 简单易用，Grafana 的告警规则配置界面直观易懂，可以方便地设置告警的触发条件、持续时间和通知方式等。
- 定制性强，Grafana 的告警规则支持自定义查询和指标，使得监控系统的告警范围更加广泛。
- 能够对告警事件进行统计和可视化处理，在 Grafana 中可以方便地对告警事件进行统计，同时还可以进行实况监控和定期报告等操作。
- 缺点
- 不支持高级告警逻辑。Grafana 只能识别基于简单算术或表达式的逻辑，无法支持更复杂的逻辑。
- 设计初衷不是作为告警处理工具，Grafana 更多地是作为数据可视化工具
- 核心功能是数据分析和展示，并不是专门的告警处理工具，因此不太适合大规模或复杂的告警处理场景
- 可扩展性不够，无法满足比较复杂、高级的告警规则设计
- 优点
- Alertmanager
- 优点
- 提供高级告警逻辑功能，支持许多常用的高级告警逻辑，如静默、抑制和聚合等。
- 支持多通道分发告警，支持将告警通知分发到多个通道，如电子邮件，短信等，能够满足不同场景下的需求。
- 可靠性高，提供多种保护机制，如去重、失败重试和自动恢复，确保告警能够可靠地传送给相应的接收方。
- 支持高度可扩展性，可以与各种 monitoring system 集成使告警触发进一步个性化
- 缺点
- 复杂和难以部署，Alertmanager 的配置比 Grafana 更复杂，需要深入了解监控系统和告警系统。
- 学习成本高，Alertmanager 需要学习更多的知识和技能才能掌握
- 不善于定义静态监控告警，对于 Dashboard 监控告警，它可能不太适合。
- 优点
- Grafana
Grafana 的告警界面介绍：由 告警规则 + 推送通道 组成
-
Alert Rules 告警规则
- 根据 panel 面板进行配置告警规则，满足相关条件则会触发告警，并通过推送通道推送给对应的接受者
- 注意：查询条件使用模版变量，会识别不了，导致告警创建失败，可以进行硬编码替换模版变量
Notifications Channel 推送通道
- 支持多个通知方式，用于向用户推送告警信息，可以根据不同的应用场景选择适合的通知渠道
- 比如：Email、Slack、钉钉、Webhook 等
Grafana 之钉钉群告警机器人
- 使用 Grafana 的 alert 告警模块，检测应用是否存活
- 配置自动告警机器人，如果应用宕机超过 1 分钟，推送到钉钉群
- 注意：一般只有 graph panel 也就是图表面板（一般都是折线图和柱状图或者点状图）可以添加 Alert ，其他面板不支持。
实战步骤
-
创建钉钉告警机器人，获取 webhook 地址
问题修复
- 点击群告警信息没法直接进到告警页面
- 解决方案：配置默认跳转路径，使用 root 用户进入容器修改配置文件
1# 进入容器
2docker exec -u 0 -it soulboy-grafana /bin/bash
3
4#通过容器id进入
5docker exec -u 0 -it 940d7837c3aa /bin/bash
6
7# 默认是localhost
8bash-5.1# vi /usr/share/grafana/conf/defaults.ini
9domain = 192.168.10.20
10
11#通过容器id重启
12exit
13docker restart 940d7837c3aa
