{ "version": "https://jsonfeed.org/version/1", "title": "老王的个人博客", "description": "这是一个 LinuxSre 相关的技术播客", "home_page_url": "http://blog.jaxxwang.cn", "items": [ { "id": "http://blog.jaxxwang.cn/posts/65018325.html", "url": "http://blog.jaxxwang.cn/posts/65018325.html", "title": "01 Prometheus入门：从监控到可观测性", "date_published": "2026-10-23T16:00:00.000Z", "content_html": "

# 第 1 章　Prometheus 入门：从监控到可观测性

\n
\n

本章导读

\n

如果你已经学过 Zabbix，第一个问题大概率是："既然有 Zabbix 了，为什么还要再学一套 Prometheus？"
\n本章就从这个疑问出发，先把" 监控 " 这件事放回到更大的框架 —— 可观测性里去看，再落到 Prometheus 本身：它是什么、由哪些组件拼成、数据怎么流转、模型长什么样。

\n

本章是整门课的地基。地基打不牢，后面装 Exporter、写 PromQL、配告警、接 Grafana 都会变成 "照着敲命令"，一旦报错就无从下手。

\n
\n

学习目标

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
序号学完本章，你应当能够
1说清可观测性三大支柱，以及 Zabbix / Prometheus 分别属于哪一支
2画出完整监控系统的六大环节，并说明每个环节解决什么问题
3用 "四个黄金指标" 设计一套自己的监控项清单
4解释时序数据库为什么比关系型数据库更适合监控场景
5讲清 Prometheus 的组件构成与四条工作流程
6对比 Pull 与 Push 两种采集模型，回答 "Zabbix 与 Prometheus 的区别" 这道必考题
7看懂一条 Prometheus 指标的含义：metric 名 + 标签 = 唯一的 time series
\n
\n

# 1.1　先破一个误解：Prometheus 不是 Zabbix 的替代品

\n

很多同学下意识地把新技术当成旧技术的 "升级包"：有了 Prometheus，Zabbix 就该淘汰了。

\n

不是这样的。 在真实的互联网公司里，这两个监控系统往往是并存的，有些大厂甚至是 "两套都跑、各管一摊"。

\n

原因在于它们的技术基因不同：

\n\n

一句话概括：

\n
\n

Zabbix 擅长 "管得住的固定目标"，Prometheus 擅长 "抓不住的动态目标"。

\n
\n

当然，这并不意味着 Prometheus 不能监控传统服务器 —— 它当然能， node_exporter 就是干这个的。也不是说 Zabbix 不能监控容器 —— 只是要费很大劲。

\n
┌────────────────────────────────────────────────────────┐\n│  一家中大型公司的典型监控版图                            │\n├────────────────────────────────────────────────────────┤\n│  机房 / 网络设备 / 老旧业务  ──►  Zabbix                 │\n│  容器平台 / 微服务 / K8s     ──►  Prometheus + Grafana   │\n└────────────────────────────────────────────────────────┘\n
\n

另外要提醒一句："Prometheus" 这个名字，指的其实不是一个软件，而是一整套组件的集合。 这一点和 Zabbix 很像 ——Zabbix 也是一堆东西： zabbix-server 、 zabbix-agent 、 zabbix-proxy 、 zabbix-web 、 zabbix-java-gateway ，还得配一个 MySQL。Prometheus 同理，只是因为它在这套架构里分量最重，所以大家习惯用它的名字指代整个体系。

\n
\n

# 1.2　把眼界放宽：什么是可观测性

\n

# 1.2.1　从控制论说起

\n

可观测性（Observability） 这个词并不是 IT 行业发明的，它诞生于几十年前的控制理论，指的是：

\n
\n

通过检查系统的 "输出"，来推断系统 "内部状态" 的能力。

\n

输出能反映内部状态的程度越高，系统的可观测性就越好。

\n
\n

举个生活化的例子：你发烧了，医生不能直接 "看见" 你体内的炎症，但他可以通过体温、血常规、心率这些外部输出去推断。这些可测量的输出越丰富、越精确，诊断就越准。系统运维完全是同一个道理 —— 你没法钻进服务器里看它 "心情如何"，只能靠它吐出来的数据判断。

\n

📌 里程碑事件：2018 年，CNCF（云原生计算基金会）率先把 "可观测性" 引入 IT 领域，称其为云原生时代必须具备的能力，并出版《可观测性白皮书》做了系统阐述。

\n

# 1.2.2　可观测性三大支柱（三大信号）

\n

白皮书提出的 "可观测性三大信号"，今天已经是 IT 领域的通识：

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
支柱回答的问题数据特征代表工具
指标 Metrics系统 "现在怎么样"？数值型、有明确时间戳、可聚合Prometheus、Zabbix
日志 Logging"究竟发生了什么"？离散事件明细、文本、体量大ELK（Elasticsearch + Logstash + Kibana）、Loki
追踪 Tracing一次请求 "经过了谁"？调用链路、有父子关系与耗时SkyWalking、Jaeger、Zipkin
\n

三者是互补关系，不是替代关系：

\n\n
\n

⚠️ 注意：Zabbix 和我们今天要学的 Prometheus，都只属于第一支柱 —— 指标监控。
\n日志监控要靠 ELK，链路追踪要靠 SkyWalking。这两块不在本课程范围内，但它们是你在简历和面试里非常值钱的加分项，建议课外补齐。

\n
\n
\n

# 1.3　一个完整监控系统的六大环节

\n

不管用什么工具，一个完整的监控系统，数据都要依次流过下面六个环节：

\n
flowchart LR
    A[\"① 数据来源<br/>产生 / 暴露\"] --> B[\"② 数据采集<br/>周期抓取\"]
    B --> C[\"③ 数据存储<br/>TSDB\"]
    C --> D[\"④ 数据处理<br/>聚合 / 计算\"]
    D --> E[\"⑤ 展示分析<br/>图形化\"]
    E --> F[\"⑥ 告警<br/>阈值触发通知\"]

把这六环背下来，你就能在任何监控产品上 "对号入座"—— 看任何一个新工具，只要问自己：它负责这六环里的哪一环？剩下的靠谁补？架构立刻清晰。

\n

# 1.3.1　① 数据来源：数据从哪来

\n

要监控，首先得有数据。数据常见的产生与暴露方式有三类：

\n\n

这里有一个关键概念：这些数据在长时间运行中，都是以固定的 "属性指标" 来描述它们的，我们称之为 metric。

\n

监控系统要做的事，就是对每个环境、每个指标都持续获取数据，并按用户需要的方式提供出去。

\n

# 1.3.2　② 数据采集：怎么把数据拿过来

\n

指标数据不是取一次就完事，而是要持续、周期性地采集。按采集通道划分，分为两大类：

\n

软件方式

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
方式说明
agent专用的采集代理，装在目标机上，如 Zabbix Agent、node_exporter
http基于 HTTP 协议拉取（Prometheus 的主流方式）
ssh常见的系统通信机制，但并非所有系统都支持，效率也偏低
SNMP简单网络管理协议（Simple Network Management Protocol），广泛内置于交换机、路由器等网络设备
\n

硬件方式

\n\n\n\n\n\n\n\n\n\n\n\n\n\n
方式说明
IPMI智能平台管理接口（Intelligent Platform Management Interface），工业标准，用于采集硬件物理健康数据：温度、电压、风扇转速、电源状态等
\n
\n

💡 关于 IPMI 的一个实战价值：服务器主板上通常有一块独立的带外管理卡（BMC）。它走独立网络，即使业务网络断了，你依然能连上去远程开机、关机、重启、装系统、看硬件告警。机房排障时，这是救命通道。

\n
\n

❗ 为什么采集量会爆炸？ 因为每个业务场景需要采集的指标数量并不确定，有时一个业务场景就要采几百个指标。再乘上 "周期性采集"，数据量是极其可观的。这就直接引出了下一个环节 —— 存储。

\n

# 1.3.3　③ 数据存储：为什么必须是时序数据库

\n

我们采集到的是 "样本数据"（sample），单个样本几乎没有意义，必须存下来，后续才能做聚合分析。而且使用这些数据时，不仅要知道值是多少，还必须知道 "这是什么时候的值"。

\n

所以监控数据天然带一个时间维度，我们称之为时间序列数据（Time Series Data，TS），专门存储这类数据的数据库叫时序数据库（Time Series Database，TSDB）。

\n
\n

时序数据库的定义：用于存储时间序列数据，并以时间（时间点或时间区间）建立索引的软件。

\n
\n

对比一下就很清楚了：

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ZabbixPrometheus
后端存储关系型数据库（MySQL 等）内置 TSDB（时序数据库）
是否需要单独部署数据库需要不需要，自身即数据库
面向场景通用型，什么都能塞专为监控场景优化
\n

这是 Prometheus 一个非常特殊、也非常重要的设计：它是监控系统，同时它自己就是数据库。 装完 Prometheus，你就同时拥有了采集器和存储，不用再单独折腾一个 MySQL。

\n

时序数据库的细节，我们在 1.5 节专门展开。

\n

# 1.3.4　④ 数据处理：原始数据往往没有意义

\n

采集到的原始数据，本身常常说明不了问题，需要经过聚合、计算、切割才可用于分析。

\n

举个贯穿全书的例子。假设我们要判断 "主机内存是否吃紧"，直觉上会盯住 "内存可用率"：

\n

内存使用率=MemTotal−MemAvailableMemTotal×100%\\text{内存使用率} = \\frac{\\text{MemTotal} - \\text{MemAvailable}}{\\text{MemTotal}} \\times 100\\%\n内存使用率=MemTotalMemTotal−MemAvailable​×100%

\n

当它超过 70%（等价于可用率低于 30%）时告警。

\n

你看，这个 70% 并不是采集上来的，而是算出来的。这就是数据处理的典型场景：把两个原始指标做一次运算，得到一个有业务含义的新指标，再交给告警规则去判断。

\n

# 1.3.5　⑤ 数据展示：人眼看不完的数字

\n

无论是原始时序数据，还是聚合后的统计结果，数据量都极其巨大。几万条数据用表格去看，是看不出来的 —— 肉眼看不出趋势和拐点。

\n

所以可视化不是 "锦上添花"，而是监控系统的必需品：把数据画成折线图、柱状图、饼图、热力图，趋势和异常才一眼可见。

\n
\n

Prometheus 的做法很 "洒脱"：它自己不做图形界面（只带一个非常简陋的 Web UI 用来调试），把可视化这块整体外包给了 Grafana。而 Zabbix 是自带图形功能的。

\n

这正是 Prometheus"功能不完整" 这一特点的来源 —— 后面还会提到。

\n
\n

# 1.3.6　⑥ 告警：让系统主动来找你

\n

监控系统最核心的价值之一，是在你不盯着屏幕的时候替你盯着。

\n

做法是：根据日常采集的数据，分析出 "正常状态" 的取值区间，把它设为一个阈值。之后每次采集到实时数据，都拿它与阈值比较，一旦越界，就通过告警机制通知到人。

\n

常见通知渠道：邮件、短信、钉钉、企业微信、电话、Webhook。

\n

在 Prometheus 体系里，这件事被拆成两半：

\n\n
\n

# 1.4　监控什么，以及怎么监控

\n

# 1.4.1　监控内容：面试常问的 "你们公司都监控了什么"

\n

"贵公司监控了哪些东西？"—— 这是运维岗的高频面试题。回答不好，会显得你只是 "会点软件"。下面这个三层框架可以直接拿去用。

\n

# 第一层：资源数据（系统级）

\n\n

# 第二层：业务服务

\n\n
\n

💡 加分点：能说出 " 监控要区分技术指标和业务指标 "，说明你不是只会看 CPU 内存。面试官听到" 我们监控了支付成功率而不是只监控数据库连接数 "，好感度会明显上升。

\n
\n

# 第三层：趋势分析

\n\n

最典型的应用是容量预测：观察一段时间内磁盘增长曲线，推算 "还有多少天写满"，提前扩容。等到真写满了再去处理，业务已经中断了。

\n

# 1.4.2　监控方法：Google 的四个黄金指标

\n

Google 提出了一套用来衡量服务级别健康状况的方法论，叫四个黄金指标（Four Golden Signals）。它特别适合应用与服务层面的监控。

\n

# ① 延迟（Latency）

\n\n
\n

为什么？因为失败请求往往 "很快"—— 连接直接被拒绝，耗时 1ms。如果你把成功和失败的延迟混在一起算平均值，一个大量报错的服务会显得 "响应飞快"，这是极其危险的误导。

\n
\n

# ② 流量（Traffic / 吞吐量）

\n\n

# ③ 错误（Errors）

\n\n

# ④ 饱和度（Saturation）

\n\n
\n

📌 方法论怎么用：这四个指标不是让你死记，而是给你一个设计监控项的检查表。以后设计任何一套监控，先问四句：
\n它慢吗？它忙吗？它错吗？它满吗？

\n
\n

需要说明的是，成熟公司通常已经有现成的监控指标清单（Excel 表格列几百项），而且 Zabbix 的模板里也内置了海量指标。你不必全都监控 —— 监控项过多会显著加重负担。挑关键的监控，不重要的不兼顾，这也是为什么你需要学会自定义模板。

\n
\n

# 1.5　监控设施的实现方式

\n

# 1.5.1　系统命令：最原始，也最不该被丢掉

\n

用 Linux 自带命令了解系统状态，是最 "原始" 的方式。经典如 top 、 vmstat 、 iostat 、 free 、 ss 、 sar 等，能快速看清 CPU、内存、磁盘、网络、进程的情况。

\n

top 尤其经典 ——CPU、内存、负载、进程一目了然。但它有个致命局限：

\n
\n

只适合少量主机、临时性地看一眼。 一百台机器，你不可能挨个 ssh 上去敲 top 。

\n
\n

不过命令行的价值在于排障现场。这里有一个非常容易搞错的细节，必须讲清楚。

\n

# ⭐ 重点： free / top 里，该盯哪个内存数字？

\n

看一个真实例子：一台 8 GB 内存的机器， top 显示 free 只有 1.3 GB。

\n
\n

这是不是意味着内存快满了？不是。

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
字段含义是否是关键指标
free / 剩余内存完全未被任何用途占用的内存❌ 不是
available / 可用内存在不触发 swap 的前提下，能腾出来给应用用的内存✅ 是
\n

原因：Linux 会把空闲内存拿去做 page cache（缓存），这部分内存随时可以被回收交给应用使用。所以 free 小是正常的、甚至是健康的 —— 它说明系统没在浪费内存。

\n

结论：判断内存是否吃紧，只看 available 。

\n

对应的使用率算法就是：

\n

使用率=MemTotal−MemAvailableMemTotal×100%\\text{使用率} = \\frac{\\text{MemTotal} - \\text{MemAvailable}}{\\text{MemTotal}} \\times 100\\%\n使用率=MemTotalMemTotal−MemAvailable​×100%

\n

比如上面这台机器，总 8 GB、可用 3 GB：

\n

8−38×100%=62.5%\\frac{8 - 3}{8} \\times 100\\% = 62.5\\%\n88−3​×100%=62.5%

\n

还有一点要顺带看一眼：swap 有没有被用上。swap 大量被使用，通常是内存真的不够了的信号；swap 完全没用，说明内存还撑得住。

\n
\n

🔗 先记住这个细节，到了本课程后面的 PromQL 部分，你会看到它的 "标准答案"：

\n
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
  / node_memory_MemTotal_bytes * 100 > 70

你会发现，理论环节讲的计算逻辑，和最终写出来的查询语句是一一对应的。这就是为什么基础概念不能跳过。

\n
\n

# 1.5.2　开源软件：从 Nagios、Cacti 到 Zabbix、Prometheus

\n

历史上流行过的监控软件不少：

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
软件时代现状
Nagios早期已基本退出主流
Cacti早期以绘图见长，现已少用
Zabbix二十余年历史依然主流，传统环境首选，成熟稳定
Prometheus云原生时代容器 / 微服务 / K8s 场景的事实标准
\n

必学结论：把 Zabbix 和 Prometheus 这两套吃透，其余可以暂时不看。

\n

# 国产之光：夜莺（Nightingale）

\n

值得一提的还有国人开源的 夜莺（Nightingale），由滴滴团队主导，从早期的 Open-Falcon（猎鹰） 演进而来，现已完全开源免费，不少公司在用。

\n

它的特点：

\n\n
\n

这门课我们学的仍然是 Prometheus—— 它是业界最主流、最 "标准" 的方案，也是所有面试的默认话题。夜莺可以作为你工作后的备选方案，也可以作为面试里 "我还了解国产方案" 的加分项。

\n
\n

# 1.5.3　监控平台：公有云自带

\n

如果你用的是公有云，根本不用自己部署监控系统：

\n\n

开箱即用，能直接监控云主机、云数据库、负载均衡等云资源。

\n
\n

但要清楚它的边界：云监控擅长 "云资源本身"，一旦涉及你自建的中间件、业务指标、容器内部状态，往往还是得自己上 Prometheus。
\n"云上监控" 与 "自建监控" 也不是替代关系，而是叠加关系。

\n
\n
\n

# 1.6　时序数据库：Prometheus 的性能底座

\n

# 1.6.1　什么是时间序列数据

\n

时间序列数据（Time Series Data）：按照时间顺序记录系统、设备状态变化的数据 —— 以时间为横坐标，数据为纵坐标。

\n

它在我们身边无处不在：主机 CPU 每秒一个采样点、智能电表每 15 分钟一个读数、股票每分钟一个价格…… 都是时间序列。

\n

时间序列数据库（TSDB） 则是一种高性能、低成本、稳定可靠的在线时序数据服务，提供高效读写、高压缩比存储、时序数据插值及聚合计算等能力。

\n
\n

权威排名可参考 https://db-engines.com/en/ranking/time+series+dbms

\n
\n

典型应用场景：

\n\n

# 1.6.2　时间序列数据的五个特点

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
特点含义对设计的启示
写多改少绝大多数是顺序追加写入，几乎不修改可极端优化写入路径，无需复杂事务
删除成段通常删除一整段时间的数据（如保留 15 天）按时间段分块存储，整块删除即可
读有序查询基本是升序或降序扫描按时间做索引，顺序读
压缩高效单点平均存储降至 1~2 字节，可节省约 90% 空间专用压缩算法，同时加快写入
性能高每秒百万级数据点写入；亿级数据点聚合结果秒级返回面向列式 / 块式存储，而非通用行存
\n

# 1.6.3　和关系型数据库比，到底强在哪

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
维度关系型数据库（MySQL）时序数据库（TSDB）
通用性高，什么数据都能塞只擅长时序数据
监控场景性能一般极高（百万级写入 / 秒）
压缩率一般高（节省约 90% 空间）
数据模型表 / 行 / 主外键 / 强关联度量 + 标签 + 时间戳，结构极简
典型使用者ZabbixPrometheus、InfluxDB、VictoriaMetrics、TDengine
\n
\n

一句话记住：关系型数据库追求 "通用"，时序数据库追求 "在时间这个维度上极致"。
\n这也是为什么在大规模容器化监控场景中，用 Prometheus 替代 Zabbix，性能表现会有明显提升。

\n
\n
\n

# 1.7　Prometheus 其人其名

\n

# 1.7.1　名字的由来

\n

Prometheus（普罗米修斯） 是希腊神话中的一位神祇：他从太阳神阿波罗那里盗走火种送给人类，给人类带来了光明，因此成为一位受人敬仰的神。

\n

有意思的是，几乎每个文明都有类似 "为人类带来光明" 的传说（中国的燧人氏钻木取火、盘古开天、女娲造人……）。给一个监控系统起这个名字，寓意大约是：它在黑暗中为你点亮火光，让你看见系统的真实状态。

\n

# 1.7.2　它到底是什么

\n

准确地说：

\n
\n

Prometheus 是一款时序（time series）数据库（TSDB），同时也是一款用于实现 "基于目标（Target）" 的监控系统的关键组件。

\n
\n

它加上 Alertmanager、Pushgateway、Grafana 等外围组件，才构成一套完整的监控系统。

\n

# 1.7.3　发展简史

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
时间事件
灵感来源Google 内部的 BorgMon 监控系统（可理解为 BorgMon 的开源精神后继者）
2012由 SoundCloud 的前 Google 员工创建，作为社区开源项目开发
2015正式对外发布
2016加入 CNCF（云原生计算基金会），成为继 Kubernetes 之后第二个由 CNCF 托管的项目
其后从 CNCF 毕业（Graduated），成为成熟项目
\n

技术栈：完全由 Go 语言开发，编译后是单一静态二进制文件，无需任何运行时依赖，部署极为简单。

\n\n
\n

💡 顺带一提：CNCF 现在成员极多，分类也细（应用定义与镜像构建、数据库、可观测性……）。MySQL、Redis、PostgreSQL、Zabbix、Prometheus、Jenkins 都在其中。业界有句玩笑话："不加入 CNCF，就显得有点落伍了。" 这从侧面说明 Prometheus 不是孤立的工具，而是整个云原生生态的一环。

\n
\n
\n

# 1.8　Prometheus 的核心特点与不足

\n

# 1.8.1　核心特点

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
特点说明
多维数据模型时间序列由 "度量名 + 键值对标签" 组成，维度极其灵活
内置 TSDB自带时序数据库，无需外部依赖，单机即可完整运行
PromQL功能强大的查询语言，支持复杂查询与聚合，是图表与告警的基础
HTTP Pull 采集主动向目标拉取指标，而非被动等待推送
Pushgateway为瞬时 / 短周期任务提供 "推" 的补充通道
目标发现（Service Discovery）支持静态配置与自动发现（文件、DNS、Consul、K8s 等）
丰富可视化通过第三方 Dashboard（Grafana）实现
丰富的 Exporter 生态几乎每种中间件都有现成的采集器
\n

# 1.8.2　数据层面的特点

\n\n
\n

🔍 严谨补充：Prometheus 原生样本值只有 float64 一种类型；字符串只出现在 # HELP 之类的元数据里。很多资料写 "支持浮点型和字符串存储"，容易让人误以为可以存文本指标 —— 实际不行。存文本明细那是日志系统（ELK/Loki）的活。

\n
\n

# 1.8.3　适用场景

\n\n

Prometheus 的设计以可靠性为第一优先级，定位是 " 故障期间要用的系统 "：

\n
\n

每个 Prometheus Server 都是独立的，不依赖网络存储或其他远程服务。当基础设施的其他部分崩了，你依然可以依靠它 —— 而且不需要预先搭建庞大的基础设施就能用起来。

\n
\n

但要注意代价：

\n
\n

如果你需要 100% 的准确性，Prometheus 不是好选择。 因为它采集的数据可能不够详细、不够完整（会丢点、会采样）。

\n

正确做法：计费、审计这类要求绝对精确的场景，用专门的系统；Prometheus 负责其余的监控。

\n
\n

# 1.8.4　Prometheus 的四个不足

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
不足说明应对思路
不支持集群化原生单机，无内置 HA 集群方案双机 "跑两份相同配置" + 联邦（Federation）；或使用 Thanos / VictoriaMetrics
规模过大时有性能瓶颈单机承载的目标数、序列数有天花板分片、联邦、远程存储
中文支持不好界面默认英文配合 Grafana 做中文化面板
功能不完整无原生图形界面、无原生告警发送能力必须配合 Grafana + Alertmanager
\n
\n

⚠️ 对比一下：Zabbix 是自带图形界面的，所以 "要装 Grafana" 这件事，从 Zabbix 转过来的同学一开始会觉得别扭。

\n

另外补充一个资深运维才知道的八卦：Zabbix 中文界面乱码问题存在二十年了，官方为什么不修？ 不是技术问题，是字体版权问题 —— 它不能内置有版权的商业字体，只能由用户自己把系统中的中文字体拷过去配置。类似的 "历史遗留问题"，往往都不是技术原因，理解这一点能让你少走很多弯路。

\n
\n
\n

# 1.9　Pull 与 Push：两种数据获取模型

\n

# 1.9.1　Prometheus 的选择：只拉不推

\n

这是 Prometheus 与其它 TSDB 相比最典型的一个特性：

\n
\n

Prometheus 主动从各个 Target 上 "拉取（Pull）" 数据，而不是等待被监控端 "推送（Push）"。

\n
\n

对应到 Zabbix 的语境里，它相当于 Zabbix 的被动模式。

\n

# 1.9.2　先把 Zabbix 的推拉搞清楚

\n

这是最容易被讲混的地方，我们用 "谁主动" 来判断，一秒钟分清：

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
模式谁主动动作方向对 Zabbix Server 的影响
被动模式（默认）Server 主动Server → Agent 索要数据Server 要挨个问 100 台机器 = 100 次请求，负担重
主动模式Agent 主动Agent → Server 推送数据Server 只等着接收，负担轻，性能更好
\n

所以 Zabbix 的性能优化手段之一，就是把被动模式改成主动模式：让 Agent 主动把数据推给 Server。

\n
\n

🧠 记忆技巧：不要记 "推 / 拉" 这两个字，记 **"谁是主动方"**。

\n\n
\n

# 1.9.3　三种系统的对照

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
系统采集模型对应 Zabbix 的说法
Zabbix推、拉都支持主动模式 + 被动模式
Prometheus只支持拉（Pull）仅相当于被动模式
InfluxDB推（Push）相当于主动模式
\n

Prometheus 只支持 Pull，不支持 Push。这一点务必记住。

\n

# 1.9.4　Pull 模型为什么是 "优点" 而不是 "缺点"

\n

表面上看，Pull 很吃亏：Server 要主动去问每一台机器，理论上性能不如被推。但 Prometheus 为什么坚持这么做？

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Pull 的优势解释
集中控制抓什么目标、按什么频率抓、抓哪些指标，全部集中在 Server 端配置，无需改动被监控端
健康状态天然可知抓不到 = 目标挂了。Prometheus 会自动生成 up 指标，探活是免费的
调试极其方便浏览器直接打开 http://目标:端口/metrics 就能看到全部指标，不依赖任何推送服务
目标可控可审计Server 端就是唯一事实来源，不会出现 "谁偷偷推了脏数据"
契合动态环境配合服务发现，目标增删自动跟上，无需在每个容器里配推送地址
\n
\n

Pull 的核心目标：Prometheus 的根本目标是收集 Target 上已经预先完成聚合的聚合型数据，而不是做一个由事件驱动的存储系统。

\n

换句话说：指标该在哪儿算好，就在哪儿算好；Prometheus 只负责 "取走成品"。

\n
\n

关于 "性能不如推" 的担忧：理论上有影响，但 Prometheus 用的是 "专为监控优化的 TSDB"，而不是 MySQL 这种通用关系库，实际差距远没有想象中大。

\n
\n

🎯 面试直达：Zabbix 与 Prometheus 有什么区别？

\n

按下面五点作答，条理清晰、直接给分：

\n
    \n
  1. 采集模型：Zabbix 推拉都支持（默认被动 = 拉，可改主动 = 推）；Prometheus 只支持 Pull。
    2. \n
  2. 存储：Zabbix 依赖关系型数据库（MySQL）；Prometheus 内置时序数据库 TSDB。
    3. \n
  3. 数据模型：Zabbix 以主机 / 监控项为中心；Prometheus 是多维标签模型， metric + labels 唯一确定一条时间序列。
    4. \n
  4. 动态环境适配：Prometheus 原生服务发现，天然适配容器 / K8s；Zabbix 靠 Agent 固定部署，容器场景笨重。
    5. \n
  5. 生态定位：Prometheus 无图形、无告警发送能力，需配 Grafana + Alertmanager；Zabbix 开箱即用、功能完整。
    6. \n
\n

再加一句收尾：" 两者不是替代关系，很多公司同时使用 "—— 这一句往往就是面试官想听到的深度。

\n
\n
\n

# 1.10　Prometheus 架构

\n

# 1.10.1　整体架构图

\n
flowchart LR
    SD[\"服务发现<br/>文件 / DNS / Consul / K8s\"]
    subgraph TARGETS[\"被监控目标（Target）\"]
        E1[\"Exporters<br/>node_exporter<br/>mysqld_exporter ...\"]
        E2[\"Instrumentation<br/>应用内嵌客户端库\"]
        PG[\"Pushgateway<br/>短周期 / 批处理任务\"]
        PS2[\"其它 Prometheus<br/>联邦 / 级联\"]
    end
    PS[\"Prometheus Server<br/>① Retrieval 抓取<br/>② TSDB 本地存储<br/>③ Rules 规则计算\"]
    AM[\"Alertmanager<br/>去重 · 分组 · 抑制 · 路由\"]
    R[\"告警接收方<br/>邮件 / 钉钉 / 企业微信 / Webhook\"]
    G[\"Grafana / Web UI<br/>可视化\"]
    API[\"HTTP API<br/>供外部集成\"]
    SD --> PS
    E1 -->|Pull| PS
    E2 -->|Pull| PS
    PG -->|Pull| PS
    PS2 -->|Pull| PS
    PS -->|Push Alerts| AM
    AM --> R
    PS --> G
    PS --> API
# 1.10.2　组件职责速查表
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
组件职责
Prometheus Server核心。彼此独立运行，仅依靠本地存储实现核心功能：抓取时序数据、规则处理、生成告警
Client Library（客户端库）嵌入到被监控服务中，直接生成并暴露符合 Prometheus 规范的 metrics。Server 来 pull 时直接返回实时状态
Exporters部署在第三方软件主机上，把本身不支持 Prometheus 的服务的指标，转换 / 聚合为 Prometheus 格式并暴露出来
Pushgateway接收短周期任务主动推送的指标，再由 Server 拉取。弥补 Pull 模型无法采集 "转瞬即逝" 任务的短板
Alertmanager接收 Server 的告警，做去重、分组、路由，再高效地发送给接收方
Data VisualizationPrometheus 自带 Web UI + Grafana 等第三方方案
Service Discovery动态发现待监控的 Target，容器化环境中尤为关键；该能力目前由 Server 内建支持
\n
\n
📌 几乎所有组件都用 Go 编写，因此都极易构建、部署为静态二进制文件。这也是整个生态 "一个 tar 包解压就能跑" 的原因。
\n
\n
# 1.10.3　三种 "数据进入口" 怎么选
\n
Prometheus 默认支持三种从目标获取指标数据的途径，新手最容易在这里选错：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
方式适用对象说明
Instrumentation新应用（自己能改代码）在代码里引入客户端库（Go / Java / Python…）埋点并暴露 HTTP 端点。最 "原生" 的方式
Exporters老应用 / 第三方软件（改不了代码）如 MySQL、Redis、Nginx、HAProxy，用官方或社区的 exporter 去抓它们的原始指标并转换格式
Pushgateway短周期任务 / 批处理任务运行时间极短，Server 还没来 pull 它就已经退出了，所以只能 "先推到一个中转站"，Server 再从中转站 pull
\n
选型口诀：
\n
能改代码 → Instrumentation\n不能改代码，但它一直活着 → Exporter\n活得太短，来不及被拉 → Pushgateway\n
\n
\n
⚠️ 关于 Pushgateway 的两个重要提醒：
\n
    \n
  1. 它只是 Pull 模型的补充，不是让你把 Prometheus 用成 Push 系统；
    2. \n
  2. 它不做过期清理 —— 推上去的指标会一直存在。所以不要用它来上报 "长期运行服务" 的指标（服务挂了，旧数据还在，会造成 "假存活"）。官方明确建议：机器层面、服务层面的常规指标用 Exporter，不要用 Pushgateway。
    3. \n
\n
\n
# 1.10.4　工作流程：四步走
\n
sequenceDiagram
    participant SD as 服务发现
    participant PS as Prometheus Server
    participant T as Target / Exporter
    participant AM as Alertmanager
    participant V as Grafana
    SD->>PS: 告知当前有哪些目标
    loop 每个 scrape_interval
        PS->>T: GET /metrics (Pull)
        T-->>PS: 返回文本格式指标
        PS->>PS: 写入 TSDB（内存 + WAL + Block）
        PS->>PS: 按告警规则周期性计算
    end
    PS->>AM: 推送触发的告警
    AM->>AM: 去重 / 分组 / 抑制 / 路由
    AM-->>AM: 发送到邮件、钉钉等
    V->>PS: PromQL 查询
    PS-->>V: 返回时序数据
用文字再复述一遍，这四步能背下来最好：
\n
    \n
  1. 抓取：Prometheus Server 定期从配置好的 Jobs / Exporters 中拉取（Pull） Metrics；也会拉取 Pushgateway 上的指标（其数据是其他节点 Push 上来的）；也可以从其它 Prometheus Server 拉取（联邦）。
    2. \n
  2. 存储与规则计算：Server 将采集到的指标存到本地 TSDB，并周期性运行已定义的 Alert Rules；产生新序列或触发告警时，向 Alertmanager 推送告警。（每个 Server 独立运行、本地存储，因此天然具备一定程度的冗余能力）
    3. \n
  3. 告警分发：Alertmanager 依据配置对告警做去重、分组，按 ** 路由（route）** 规则发送到对应接收方。
    4. \n
  4. 可视化：集成 Grafana 或其他 API 作为图形界面，展示采集到的数据。
    5. \n
\n
# 1.10.5　"Prometheus 只做一件事"
\n
这一点必须建立正确的认知，否则你会一直困惑 "为什么还缺这缺那"：
\n
\n
Prometheus 只负责 "时序型指标数据" 的采集与存储。
\n
数据的分析、聚合、直观展示、告警发送，都不由 Prometheus Server 负责，必须配合其它组件完成。
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
我要的功能谁来做
抓取指标Prometheus Server
存指标Prometheus Server（内置 TSDB）
查询 / 聚合PromQL（Server 内建）
画图Grafana
发告警Alertmanager
采集各类中间件Exporters（官方 + 社区，生态极丰富）
\n
Exporter 清单见：https://prometheus.io/docs/instrumenting/exporters/
\n
\n
# 1.11　Prometheus 数据模型
\n
# 1.11.1　一切皆为时间序列
\n
Prometheus 中存储的数据，全部是时间序列 —— 即基于同一度量标准、或同一时间维度的数据流。
\n
\n
除了正常存储原始时间序列，Prometheus 还会基于原始数据临时生成新的时间序列（例如 PromQL 的聚合结果），作为后续查询的依据或结果。
\n
\n
核心公式，请务必刻在脑子里：
\n
时间序列=metric 名称+一组标签（键值对）+时间戳+样本值\\boxed{\\text{时间序列} = \\text{metric 名称} + \\text{一组标签（键值对）} + \\text{时间戳} + \\text{样本值}}\n时间序列=metric 名称+一组标签（键值对）+时间戳+样本值​
\n
其中，metric 名称 + 标签集合共同构成这条序列的唯一标识。
\n
\n
💡 关键推论：只要任意一个标签的值变了（包括新增或删除标签），就产生了一条全新的时间序列。
\n这就是为什么 "标签设计" 在 Prometheus 里如此重要 —— 标签设计不当会导致序列爆炸（cardinality explosion），直接把内存打满。这是第七章 "标签管理" 的核心话题。
\n
\n
# 1.11.2　Metric 名称
\n\n
准确的合法字符集（正则）：
\n
# metric 名称
[a-zA-Z_:][a-zA-Z0-9_:]*
# 标签名称
[a-zA-Z_][a-zA-Z0-9_]*
\n
⚠️ 常见误区纠偏：不少课件把这条正则简写成  a-zA-Z_:* ，看着像 "允许出现星号"，实际是笔误。记住上表两条规则即可 —— 首字符不能是数字，metric 名允许冒号，标签名不允许冒号。
\n
\n
关于冒号的保留说明：
\n
\n
冒号（ : ）是为用户定义的记录规则（recording rule）保留的，不要用在普通的 exporter 指标名里。
\n
\n
# 1.11.3　标签（Label）
\n
标签以键值对形式存在，用于表示时间序列的不同维度。
\n
基本格式：
\n
<metric name>{<label name>=<label value>, ...}\n
\n
示例：
\n
http_requests_total{method="POST", endpoint="/api/tracks"}\n
\n
解读：
\n\n
标签的命名与取值规则：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
规则说明
键名合法字符ASCII 字母、数字、下划线，正则  [a-zA-Z_][a-zA-Z0-9_]*
 __  开头保留给内部使用，用户不要使用（如  __name__  是 metric 名的内部表示）
标签值可以是任意 Unicode 字符（可以写中文）
空标签值被认为等同于标签不存在（等价于没有这个标签）
\n
查询语言（PromQL）正是基于这些维度进行过滤与聚合的 —— 这是 Prometheus 强大灵活性的根源：
\n
# 按 method 维度过滤
http_requests_total{method=\"POST\"}
# 按 method 维度聚合
sum by (method) (rate(http_requests_total[5m]))
# 1.11.4　数据格式（Exposition Format）
\n
Exporter 把采集到的数据转换为纯文本格式，通过 HTTP 响应返回给 Prometheus Server。
\n
格式规则：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
行首标记含义
# HELPmetric 的帮助说明（人类可读描述）
# TYPE声明 metric 类型： counter  /  gauge  /  histogram  /  summary  /  untyped
#  开头（其他）一般注释，供人阅读，Prometheus 会忽略
其他行真正的样本数据： 指标名{标签} 值 [时间戳]
\n
一个真实的  /metrics  输出片段：
\n
# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu=\"0\",mode=\"idle\"} 1.2345678e+06
node_cpu_seconds_total{cpu=\"0\",mode=\"system\"} 34567.89
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 0.52
四种核心数据类型速览（第 2 章会详细展开）：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
类型特征典型例子
Counter只增不减（除非重置）的累计值http_requests_total 、 node_cpu_seconds_total
Gauge可增可减的瞬时值node_load1 、 node_memory_MemAvailable_bytes
Histogram按桶（bucket）统计分布，可算分位数http_request_duration_seconds_bucket
Summary客户端直接计算分位数rpc_duration_seconds{quantile="0.99"}
\n
# 1.11.5　Job（任务）与 Instance（实例）
\n
这两个词在配置文件、PromQL、Grafana 面板里到处出现，必须分清。
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
概念定义
Instance（实例）一个单独的 scrape 目标，通常写作  IP:PORT ，对应单个应用的进程
Job（任务）一组同种类型的 instances 集合，主要用于保证可扩展性与可靠性
\n
官方式的例子：一个 API 服务 job 包含四个 instances：
\n
job: api-server\n├── instance 1: 1.2.3.4:5670\n├── instance 2: 1.2.3.4:5671\n├── instance 3: 5.6.7.8:5670\n└── instance 4: 5.6.7.8:5671\n
\n
\n
🧠 类比： job  是 " 一个部门的岗位名称 "， instance  是 " 这个岗位上具体的人 "。一个岗位可以有多个人轮值（多副本），这就是可扩展性；某个人请假了别人还在（副本冗余），这就是可靠性。
\n
\n
自动生成的内置指标：Prometheus 在每次抓取后，会为目标自动生成一组带  job  和  instance  标签的元指标。这些指标不需要你在目标上暴露，是 "白送" 的运维利器：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
指标含义典型用途
up{job,instance}目标是否健康：1 正常，0 不正常最常用的存活告警： up == 0
scrape_duration_seconds{job,instance}本次抓取耗时发现抓取缓慢的目标
scrape_samples_scraped{job,instance}本次抓取到的样本数量监控指标量是否异常膨胀
scrape_samples_post_metric_relabeling{job,instance}relabel 之后剩余的样本数验证 relabel 规则效果
scrape_series_added{job,instance}本次抓取新增的序列数（约数）发现序列爆炸的早期信号
\n
\n
💡 实战价值： scrape_series_added  突然飙升，往往意味着某个应用偷偷加了高基数标签，或者发生了一次重启导致新序列涌入。提前发现，能救你一命。
\n
\n
# 1.11.6　本节小结
\n
数据模型：metric 名称 + 标签（= 唯一时间序列）\n数据类型：Counter / Gauge / Histogram / Summary（+ untyped）\n组织结构：多个 instances 组成一个 job\n命名规则：名称 [a-zA-Z_:][a-zA-Z0-9_:]* ｜ 标签 [a-zA-Z_][a-zA-Z0-9_]*\n
\n
\n
# 1.12　Prometheus 数据处理四部曲
\n
# 1.12.1　数据获取：一切基于 HTTP
\n
Prometheus 采集指标数据的方式，本质上是 HTTP Call：从目标配置文件中指定的网络端点（endpoint，即  IP:Port ，代表一个应用）上周期性获取指标。一个端点上通常不止一个指标，而是成百上千个。
\n
这里有一个根本性约束，必须理解：
\n
\n
Prometheus 的所有指标都必须以 HTTP 方式暴露出来。
\n
因此 Prometheus 无法直接获取内核数据、硬件数据 —— 它只能通过其它机制间接获得（例如  node_exporter  读取  /proc  后再转换为 HTTP 端点暴露）。
\n
\n
这就是为什么 "安装一个 exporter" 几乎是所有监控任务的起点。
\n
# 1.12.2　数据存储：本地 TSDB 的分层结构
\n
Prometheus 采用自定义格式将时间序列存储在本地磁盘上，结构相当精妙：
\n\n
写入路径与 WAL 保护机制：
\n
\n
Prometheus 平时把采集到的数据先都放在内存里，以类似缓存的方式加快搜索和访问；
\n同时通过 WAL（Write-Ahead Logging，预写日志） 把数据落盘到  wal  目录；
\n当进程崩溃或宕机重启时，依靠 WAL 恢复数据并重新加载到内存。
\n
\n
真实的  data  目录长这样：
\n
/usr/local/prometheus/data
├── 01G9RSD61ZEF16T5YGE91K49MZ/    ← 一个 Block（约 2 小时的数据）
│   ├── chunks/                    ← 压缩后的样本数据
│   │   └── 000001
│   ├── index                      ← 标签与序列的索引
│   ├── meta.json                  ← 该 Block 的元信息（时间范围、样本数等）
│   └── tombstones                 ← 删除标记（软删除）
├── 01G9RZ8VXF2FHHB18CW0594P8T/
│   ├── chunks/000001
│   ├── index
│   ├── meta.json
│   └── tombstones
├── chunks_head/                   ← ┐
│   ├── 000002                     │  当前正在写入的\"头部块\"
│   └── 000003                     ← ┘
├── lock                           ← 进程锁，防止多实例共用目录
├── queries.active                 ← 正在执行的查询
└── wal/                           ← 预写日志，宕机恢复用
    ├── 00000000
    ├── 00000001
    └── 00000002
\n
⚠️ 生产提醒：
\n\n
\n
# 1.12.3　数据分析：PromQL
\n
Prometheus 提供了专门的查询语言 PromQL（Prometheus Query Language），支持实时查询与聚合运算，是图表展示与告警规则的共同基础。
\n
PromQL 处理两种核心向量：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
向量类型含义直观理解
即时向量（Instant Vector）最近一次抓取的单个时间戳上的一组数据一个时间点的数据
范围向量（Range Vector）指定时间范围内的所有时间戳上的数据一个时间段的数据
\n
# 即时向量：此刻的 CPU 空闲时间总量
node_cpu_seconds_total{mode=\"idle\"}
# 范围向量：过去 5 分钟的所有采样点（注意 [5m]）
node_cpu_seconds_total{mode=\"idle\"}[5m]
\n
两者最直观的区别：范围向量不能直接画成折线图，必须先经过  rate() 、 avg_over_time()  这类函数 "降维" 成即时向量才行。这是新手最常踩的坑之一。
\n
\n
PromQL 同时内置了大量处理函数（数学运算、聚合、时间函数、 rate / increase 、 histogram_quantile  等），第 5～6 章会逐一展开。
\n
# 1.12.4　数据告警：职责分离的设计
\n
Prometheus 的告警是一条明确分权的链路：
\n
Prometheus Server                     Alertmanager\n─────────────────                     ─────────────\n按告警规则周期性计算   ──告警指示──►   去重 → 分组 → 抑制 → 路由\n（只负责"发现问题"）                  （只负责"通知谁"）\n
\n\n
\n
💡 为什么这样设计？ 因为 "判断异常" 和 "决定通知" 是两件完全不同的事。前者是时序计算（Prometheus 擅长），后者是消息治理（去重、静默、值班表、升级策略 ——Alertmanager 擅长）。拆开之后，两边都能做得更好，也让 Prometheus 保持了 "单一职责"。
\n
\n
\n
# 1.13　本章小结
\n
mindmap
  root((\"Prometheus<br/>入门\"))
    可观测性
      指标 Metrics
      日志 Logging
      追踪 Tracing
    六大环节
      数据来源
      数据采集
      数据存储 TSDB
      数据处理
      数据展示
      数据告警
    监控方法
      四个黄金指标
      延迟 流量 错误 饱和度
    存储
      时序数据五特点
      压缩 90%
      百万级写入
    架构
      Server 核心
      Exporters
      Pushgateway
      Alertmanager
      Grafana
      Service Discovery
    Pull 模型
      只拉不推
      集中控制
      up 免费探活
    数据模型
      metric 名 + 标签
      四种类型
      job / instance
必须带走的一句话：
\n
\n
Prometheus 是一套 " 以 Pull 方式采集、用多维标签建模、把数据存进内置 TSDB、靠 PromQL 分析、由 Grafana 展示、交给 Alertmanager 告警 " 的监控组件集合。
\n它只做 "指标" 这一支柱，也只做 "采集 + 存储 + 查询" 这三件事 —— 其它都得靠生态补齐，而这恰恰是它最强大的地方。
\n
\n
\n
# 1.14　面试高频问答
\n
Q1：你们公司为什么同时用 Zabbix 和 Prometheus？
\n
\n
因为两者定位不同。Zabbix 擅长传统固定资产和网络设备监控（SNMP/IPMI 生态完善、开箱即用），Prometheus 擅长容器化、动态变化的微服务环境（服务发现 + 多维标签）。老业务用 Zabbix，容器平台用 Prometheus，是很常见的组合。
\n
\n
Q2：Prometheus 的采集模型是什么？和 Zabbix 有什么不同？
\n
\n
Prometheus 只支持 Pull，相当于 Zabbix 的被动模式；Zabbix 推拉都支持（默认被动，可改主动）。InfluxDB 则是 Push。
\nPull 的好处是配置集中在 Server 端、 up  指标免费探活、调试方便、天然配合服务发现。
\n
\n
Q3：Prometheus 为什么性能好？
\n
\n
核心是存储：它用的是自研 TSDB（时序数据库），针对 "写多改少、删除成段、读有序" 的特点做了分块存储和专用压缩，单点平均 1~2 字节，可节省约 90% 空间，支持百万级写入 / 秒、亿级聚合秒级返回；而 Zabbix 用通用关系库，不是为监控场景优化的。
\n
\n
Q4：什么是时间序列？唯一标识是什么？
\n
\n
时间序列是按时间顺序记录的、同一度量维度的数据流。唯一标识是 metric 名称 + 一组标签。任何一个标签值变化（新增或删除标签），都会产生一条新的时间序列。
\n
\n
Q5：Prometheus 有哪些不足？怎么弥补？
\n
\n
① 不支持集群（用双机 + 联邦，或 Thanos/VictoriaMetrics）；② 规模过大有瓶颈（分片、联邦、远程存储）；③ 中文支持差（Grafana 面板中文化）；④ 功能不完整（配 Grafana + Alertmanager）。
\n
\n
Q6： up  指标是干什么的？
\n
\n
Prometheus 每次抓取后自动生成的元指标， 1  表示目标健康、 0  表示抓取失败。最经典的存活告警就是  up == 0 。
\n
\n
\n
# 1.15　动手练习
\n
# 练习 1（观察题）　亲手看一眼 /metrics
\n
准备一台 Linux 机器（或虚拟机），下载  node_exporter  并运行，然后：
\n
# 终端 1：启动 exporter（默认端口 9100）
./node_exporter
# 终端 2：查看原始指标输出
curl -s http://localhost:9100/metrics | head -50
# 找出所有 HELP/TYPE 声明
curl -s http://localhost:9100/metrics | grep -E '^# (HELP|TYPE)' | head -20
# 找出内存相关指标
curl -s http://localhost:9100/metrics | grep node_memory_Mem
要回答的问题：
\n
    \n
  1. node_memory_MemTotal_bytes  是什么类型？（Counter 还是 Gauge？为什么？）
    2. \n
  2. node_cpu_seconds_total  是 Counter，那你怎么算出 "当前 CPU 使用率"？只用一次抓取的值能算出来吗？
    3. \n
  3. 用本章的内存公式，算出你这台机器当前的内存使用率。
    4. \n
\n
# 练习 2（思考题）　Pull 还是 Push？
\n
以下场景分别该用哪种方式？
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
场景你的答案
Nginx 反向代理（长期运行）?
每天凌晨跑 30 秒的备份脚本，要记录耗时与退出码?
你自己用 Go 写的 API 服务?
机房核心交换机?
\n
\n
参考答案：① Exporter（ nginx_exporter ）；② Pushgateway；③ Instrumentation（客户端库埋点）；④ Exporter（ snmp_exporter ）。
\n
\n
# 练习 3（设计题）　用四个黄金指标设计监控清单
\n
假设你要监控一个 "用户登录" 接口，请用延迟 / 流量 / 错误 / 饱和度四个维度，各写出至少 2 个具体监控项。
\n
\n
提示：延迟要区分成功与失败；流量可用 QPS；错误可用 HTTP 5xx 率；饱和度可看该服务所依赖的数据库连接池使用率。
\n
\n
# 练习 4（原理题）　为什么  free  小不是问题？
\n
在一台机器上执行  free -h ，观察  free  与  available  两列的差异，并解释：
\n
    \n
  1. 为什么两者差距可能很大？
    2. \n
  2. 如果  swap  开始被大量使用，说明什么？
    3. \n
  3. 用公式算出使用率，并说出对应的告警阈值。
    4. \n
\n
\n
# 1.16　下章预告
\n
本章我们把 Prometheus"是什么、为什么、由什么组成" 讲透了。下一章将正式动手：
\n\n
先把本章的架构图画三遍 —— 后面所有命令和配置，都是在给这张图 "接线"。
\n",
            "tags": [
                "Prometheus"
            ]
        },
        {
            "id": "http://blog.jaxxwang.cn/posts/1096553236.html",
            "url": "http://blog.jaxxwang.cn/posts/1096553236.html",
            "title": "03 PromQL：把指标变成答案",
            "date_published": "2026-10-23T16:00:00.000Z",
            "content_html": "
# 第 3 章　PromQL：把指标变成答案
\n
\n
本章导读
\n
第 2 章结束时，你已经能在 Grafana 上看到四台主机的 CPU 曲线了。但那张图是别人写好模板给你的 —— 你并不知道里面那句表达式在算什么。
\n
本章解决的就是这个问题。学完本章，你应当能够看着一条指标名，就知道该怎么查、能不能直接画、要不要套函数。
\n
这是全课程技术含量最高的一章，也是最容易 "看懂但写不出" 的一章。建议边读边在 9090 的 Graph 页面里敲 ——PromQL 是肌肉记忆，不是阅读理解。
\n
\n
学习目标
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
序号学完本章，你应当能够
1说清 Sample、Time Series、Instant Vector、Range Vector、Scalar 的关系
2熟练使用四种匹配器与  offset ，写出精准的过滤条件
3判断一个指标属于 Counter / Gauge / Histogram / Summary，并决定该不该套函数
4用算术、比较、 bool  修饰符写出 "内存使用率"" 磁盘使用率 " 这类业务指标
5用  by  /  without  完成分组统计，正确计算 "占比" 类指标
6准确区分  increase  /  rate  /  irate  /  delta  /  idelta ，并说明各自适用场景
7理解  ignoring  /  on  /  group_left  /  group_right  解决什么问题
8排查 "表达式没结果" 和 "vector cannot contain metrics with the same labelset" 两类高频报错
\n
\n
# 3.1　先把地基夯死：时间序列与样本
\n
# 3.1.1　时间序列（Time Series）
\n
Prometheus 采用时间序列存储监控数据。
\n
\n
时间序列：按照时间顺序记录系统、设备或应用状态变化的数据集合。
\n
\n
数据按固定采集周期（如 15s、30s）不断采集，随着时间推移形成一串离散的数据点 —— 这就是时间序列。
\n
放到坐标系里就非常直观：X 轴是时间，Y 轴是数值，把点连起来就是我们看到的监控曲线。Grafana 里那一条条折线，本质就是若干个时间序列。
\n
# 3.1.2　样本（Sample）
\n
每采集一次，就产生一个样本。一个 Sample 由两部分组成：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
组成内容
keyMetric 名称 + Label 集合 + Timestamp（毫秒精度）
valuefloat64 格式的数值
\n
\n
📌 记住这个 "没有例外" 的事实：Prometheus 的样本值只能是 float64。
\n没有字符串、没有布尔、没有整型。你看到的  1 、 0 、 200 ，全是浮点数的字面表现。
\n
\n
# 3.1.3　唯一标识与五条铁律
\n
时间序列的唯一标识 = Metric Name + Label Set。
\n
围绕这句话，有五条推论必须记牢：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
#铁律后果
1指标名 + 标签的特定组合代表一条时间序列查询时永远在 "选序列"
2不同指标名代表不同时间序列名字就是身份
3指标名相同、标签不同，是不同时间序列method="GET"  与  method="POST"  是两条
4更改任何标签值（含增删标签）都会创建新序列标签一改，历史数据就 "接不上"
5应尽量保持标签稳定标签乱变 → 序列爆炸 → 图形 / 告警 / 记录规则全部失效
\n
\n
⚠️ 第 4、5 条是生产事故级别的认知。第 4 章讲标签管理时，你会亲眼看到 "改了一个标签，图上出现断层" 的现象 —— 那正是这条铁律在起作用。
\n
\n
# 3.1.4　指标的两种书写形式
\n
http_requests_total{method="GET", code="200"}          # 常规写法\n{__name__="http_requests_total", method="GET"}         # 等价写法\n
\n
第二种写法里出现了  __name__ —— 这就是第 1 章提过的内部保留标签，它存的正是指标名本身。
\n
\n
💡 为什么要知道  __name__ ？ 因为它让你可以用正则批量选择指标名：
\n
{__name__=~\"prometheus_http_.*\"}     # 所有以 prometheus_http_ 开头的指标
而在  metric_relabel_configs  里 "按指标名前缀批量丢弃" 时，用的也正是它。
\n
\n
\n
# 3.2　四种表达式类型：PromQL 的 "类型系统"
\n
# 3.2.1　什么是 PromQL
\n
官方文档：https://prometheus.io/docs/prometheus/latest/querying/basics/
\n
\n
PromQL（Prometheus Query Language）是 Prometheus 内置的函数式表达式语言，用于实时查找和聚合时间序列数据。
\n
\n
它的结果有三个去处：
\n
    \n
  1. 图表展示（Grafana / 内置 Graph）；
    2. \n
  2. 表格展示（表达式浏览器）；
    3. \n
  3. HTTP API 提供给外部系统（告警、自动化平台、自研大屏）。
    4. \n
\n
\n
📌 默认时间基准：不指定时间时，以 "当前时间" 为基准点取数。
\n
\n
# 3.2.2　四种结果类型
\n
任何一个 PromQL 表达式（或子表达式），计算结果必为以下四种之一：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
类型中文定义直观理解
instant vector即时向量一组时间序列，每条序列各含一个样本，共享同一时间戳一个时间点上的一组数
range vector范围向量一组时间序列，每条序列含一串随时间变化的样本一个时间段内的一组数
scalar标量一个简单的浮点数值一个 "裸数字"，如  1024
string字符串一个简单字符串目前基本用不到
\n
instant vector  →  node_load1\n                   ↑ 4 台机器 = 4 条序列，每条 1 个值\n\nrange vector    →  node_load1[5m]\n                   ↑ 4 台机器 = 4 条序列，每条 20 个值（15s×20=5m）\n\nscalar          →  1024\nstring          →  "hello"\n
\n
# 3.2.3　⭐ 最实用的规则：什么场景要什么类型
\n
这是新手最容易栽跟头的地方。三类约束必须背下来：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
场景要求的类型违反后的报错
画折线图只能是 instant vector图表画不出来
用  rate  /  increase  /  irate  等速率函数必须是 range vector报  expected type range vector
在表达式浏览器里直接查 range vector❌ 不允许invalid expression type "range vector" for range query, must be Scalar or instant Vector
\n
\n
🧠 一句话总结：
\n范围向量永远不能 "出门"，它只能在函数括号里活着。
\n
所以要画图， node_load1[5m]  必须降维：
\n
avg_over_time(node_load1[5m])     # range → instant，可以画了
rate(http_requests_total[5m])     # range → instant，可以画了
\n
# 3.2.4　用 API 直接查数据
\n
PromQL 不只能在界面里敲，它本质是一个 HTTP API。
\n
# ① 即时查询：当前请求数
curl -G http://192.168.80.101:9090/api/v1/query \\
  --data-urlencode 'query=prometheus_http_requests_total' | jq
# ② 指定时间点查询
curl -G http://192.168.80.101:9090/api/v1/query \\
  --data-urlencode 'query=prometheus_http_requests_total' \\
  --data-urlencode \"time=$(date +%s)\" | jq
# ③ 带标签过滤（正则）
curl -G http://192.168.80.101:9090/api/v1/query \\
  --data-urlencode 'query=node_memory_MemFree_bytes{instance=~\"192.168.80.(101|102):9100\"}' | jq
# ④ 范围查询：必须给 start /end/step
curl -G http://192.168.80.101:9090/api/v1/query_range \\
  --data-urlencode 'query=rate(node_cpu_seconds_total{mode!=\"idle\"}[5m])' \\
  --data-urlencode \"start=$(date -d '-1 hour' +%s)\" \\
  --data-urlencode \"end=$(date +%s)\" \\
  --data-urlencode 'step=15' | jq
\n
💡 这套 API 的实际价值：所有 "把监控数据接到自研平台" 的需求，本质都是调  /api/v1/query_range 。学会它，你就能把 Prometheus 变成任何系统的数据源。
\n
\n
# 3.2.5　字面量：数字与字符串
\n
# 数字：[-] digits [.digits]
2
2.43
-2.43
# 字符串：单引号 / 双引号 / 反引号
\"this is a string\"
'these are unescaped: \\n \\t'
`these are not unescaped: \\n ' \" \\t`
反引号的作用：不做转义。写正则时特别有用（正则里的  \\d 、 \\d+  用双引号写会被当作转义符处理）。
\n
\n
# 3.3　数据选择器：从百万序列里挑出你要的
\n
# 3.3.1　统一语法
\n
metrics_name{筛选label=值,...}[<时间范围>] offset <偏移>\n
\n
一条表达式的三个可选部件：指标名 → 标签匹配器 → 时间修饰。
\n
# 3.3.2　即时向量选择器（Instant Vector Selector）
\n
获取 0 个、1 个或多个时间序列的即时样本值。
\n
由两部分组成，至少要给出一个：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
部分作用是否可省
指标名称限定是哪个指标可省
匹配器（Matcher）定义在  {}  内，过滤标签可省
\n
# 用法一：只给指标名
\n
node_filefd_allocated
prometheus_http_requests_total
\n
💡  http_requests_total  与  http_requests_total{}  完全等价。空花括号不改变语义。
\n
\n
# 用法二：用  __name__  匹配多个指标名
\n
{__name__=\"prometheus_http_requests_total\"}
{__name__=~\"^prometheus_http_.*\"}
# 用法三：只给匹配器
\n
{job=\"node_exporter\"}
\n
⚠️ 这种写法会返回所有带该标签的指标 —— 可能横跨很多不同指标名，结果集极大。慎用。
\n
\n
# 用法四：指标名 + 匹配器（最常用）
\n
http_requests_total{method=\"get\"}
# ⭐ 四种匹配操作符
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
操作符含义说明
=精确匹配值完全相等
!=不匹配值不完全相等
=~正则匹配必须整值匹配（全锚定）
!~正则不匹配取反
\n
关于  =~  的全锚定，务必记住：
\n
# ❌ 错误：以为能匹配 \"get\"、\"gets\"… 实际什么都匹配不到（除非值就是 \"ge\"）
http_requests_total{method=~\"^ge\"}
# ✅ 正确：显式补齐
http_requests_total{method=~\"^ge.*\"}
\n
🧠 Prometheus 的正则自动加了  ^...$ 。这是它和 grep 最大的区别，也是新手最高频的错误之一。
\n
\n
多值用  |  表示 "或"：
\n
{env=~\"staging|testing|development\"}
多条件用逗号  ,  分隔（逻辑与）：
\n
prometheus_http_requests_total{instance=\"localhost:9090\", job=\"prometheus\"}
prometheus_http_requests_total{handler=~\".*meta.*\"}
node_memory_MemFree_bytes{instance=~\"10.0.0.(101|102):9100\"}
node_memory_MemAvailable_bytes{instance=~\"10.0.0.20[0-9]:9100\"}
node_memory_MemAvailable_bytes{instance!~\"10.0.0.20[12]:9100\"}
# ⚠️ 空标签值的特殊性
\n
\n
匹配到空值的匹配器，会让 "根本没有这个标签" 的时间序列也符合条件。
\n
\n
http_requests_total{env=\"\"}
这条不仅匹配  env=""  的序列，还匹配完全不含  env  标签的所有  http_requests_total  序列。
\n
# ⚠️ 一个硬性约束
\n
\n
向量选择器至少要包含一个指标名，或者至少一个 "非空值" 的标签匹配器。
\n
\n
所以下面这两种写法是非法的：
\n
{job=~\".*\"}      # ❌ 正则能匹配空 → 相当于没限定
{job=\"\"}         # ❌ 同上
\n
💡 原因：这两种写法在语义上等于 "把整个数据库都选出来"。Prometheus 直接拒绝，防止你一条查询把内存打满。
\n
\n
# 3.3.3　范围向量选择器（Range Vector Selector）
\n
在即时选择器后面加一个  []  时间范围即可。
\n
prometheus_http_requests_total{job=\"prometheus\"}[5m]
时间单位的规则：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
单位含义单位含义
s秒d日
m分w周
h时y年
\n
两条限制：
\n
[1h30m]      # ✅ 允许串联，且必须\"由大到小\"
[1.5h]       # ❌ 不允许小数，必须是整数时间单位
# ⭐ 为什么统计结果 "不那么整"？
\n
这是一个非常好的理解 Prometheus 设计的机会。
\n
\n
不同时间序列的抓取时间点，并不严格对齐。
\n
\n
原因：如果所有 target 都在同一毫秒被抓取，几百上千个 target 会在那一瞬间把 Prometheus 压出尖峰。所以 Prometheus 会刻意为每个 target 稍微错峰（差几毫秒到几百毫秒）。
\n
后果：趋势上准确，绝对数值上并不精确。 比如  [1m]  在 10s 间隔下，采样点数可能是 6 个，也可能是 5 个或 7 个。
\n
\n
💡 这解释了大量 " 为什么  increase()  算出来是  5.8  而不是  6 " 的困惑。不是 bug，是设计。
\n
\n
# 3.3.4　偏移修饰符  offset
\n
所有选择器默认以 "当前时间" 为基准。 offset  就是把这根基准线往回推。
\n
# 5 分钟之前的即时值
prometheus_http_requests_total offset 5m
prometheus_http_requests_total{code=\"200\"} offset 5m
# 1 天之前的那 5 分钟区间
http_requests_total[5m] offset 1d
# 3 分钟之前的那 5 分钟区间
http_requests_total{handler=\"/metrics\"}[5m] offset 3m
三条要点：
\n
    \n
  1. offset  必须紧跟在选择器后面，中间不能断开；
    2. \n
  2. offset  偏移的是时间基点，不是区间长度；
    3. \n
  3. 既有范围又有偏移时：先定基点，再取范围。 [5m] offset 3m  = "3 分钟前那一刻，往前数 5 分钟"。
    4. \n
\n
\n
💡 典型用途：环比
\n
# 现在的 QPS 与 1 小时前对比
rate(http_requests_total[5m]) - rate(http_requests_total[5m] offset 1h)
\n
\n
# 3.4　四种指标类型：决定 "这个数能不能直接画"
\n
# 3.4.1　先看一组真实的统计数据
\n
# Prometheus 自身的指标类型分布
curl -s http://prometheus:9090/metrics | awk '$2==\"TYPE\"{t[$NF]++}END{for(i in t) print t[i], i}'
# 93 counter
# 74 gauge
#  7 histogram
# 12 summary
# Node Exporter 的指标类型分布
curl -s http://node01:9100/metrics | awk '$2==\"TYPE\"{t[$NF]++}END{for(i in t) print t[i], i}'
# 199 gauge
#  74 counter
#  47 untyped
#   1 summary
\n
💡 这个小命令很值得收藏： awk '$2=="TYPE"'  直接统计某个 Exporter 暴露了多少种、什么类型的指标。评估一个 Exporter 的 "指标规模" 时非常好用。
\n
\n
注意  untyped  的存在 —— 它是历史遗留，行为接近 gauge，新写的 Exporter 不应该产出 untyped。
\n
# 3.4.2　Counter（计数器）
\n
\n
单调递增的累计值，从 0 开始，只增不减，除非进程重启归零。
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
项目内容
特征只能增加，可被重置为 0（重新计数）
典型场景用户访问量、请求总数、任务完成数、错误总数
命名约定常以  _total  结尾
能否表示递减❌ 不能
\n
范例：
\n
# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu=\"0\",mode=\"idle\"}    28375.49
node_cpu_seconds_total{cpu=\"0\",mode=\"iowait\"}      4.82
node_cpu_seconds_total{cpu=\"0\",mode=\"irq\"}         0
node_cpu_seconds_total{cpu=\"0\",mode=\"nice\"}        0
node_cpu_seconds_total{cpu=\"0\",mode=\"softirq\"}     0.09
node_cpu_seconds_total{cpu=\"0\",mode=\"steal\"}       0
node_cpu_seconds_total{cpu=\"0\",mode=\"system\"}      4.43
node_cpu_seconds_total{cpu=\"0\",mode=\"user\"}        0.36
# ⭐ 核心认知：Counter 的总数几乎没有意义
\n
node_cpu_seconds_total{cpu="0",mode="idle"} = 28375.49  —— 这个数字本身说明不了任何问题。它只是 "从开机到现在，CPU 0 空闲了多少秒"。
\n
\n
有价值的是它的 "变化速度"。
\n
\n
所以 Counter 几乎从不直接使用，而是配函数降维：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
函数得到什么用途
rate()每秒平均增长率⭐ 算 QPS、CPU 使用率
irate()最近两点的瞬时增长率看突发尖峰
increase()区间内增长总量算 "这段时间一共处理了多少"
topk()排名前 K 的序列找最忙的接口
\n
# 找出请求总数排名前 3 的时间序列
topk(3, http_requests_total)
# 2 小时内的平均增长速率（各序列）
rate(http_requests_total[2h])
# 2 小时内最灵敏的瞬时速率
irate(http_requests_total[2h])
\n
⚠️ Counter 重置的处理：进程重启后 Counter 归零，直接相减会得到负数。
\n rate()  /  irate()  /  increase()  已经内置处理了重置（自动检测下降并补偿），所以永远用函数算，不要自己写  current - offset 。
\n
\n
# 3.4.3　Gauge（计量器）
\n
\n
可增可减的瞬时状态值。
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
项目内容
特征任意波动，可以上升也可以下降
典型场景硬盘剩余空间、当前内存使用量、待处理任务数、并发请求数、负载
常见操作sum  /  avg  /  min  /  max  /  delta  /  predict_linear
\n
范例：
\n
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 2.017896e+06
# TYPE node_load1 gauge
node_load1  0
# TYPE node_load15 gauge
node_load15 0
两个实战函数：
\n
# delta：区间首尾之差（\"比 2 小时前升高 / 降低了多少\"）
delta(cpu_temp_celsius{host=\"prometheus.example.com\"}[2h])
# predict_linear：基于线性回归，预测 t 秒后的值
# ⭐ 容量预测：按最近 6 小时的趋势，预测 4 小时后根分区可用空间是否将小于 0
predict_linear(node_filesystem_free_bytes{mountpoint=\"/\"}[6h], 4*3600) < 0
\n
💡 最后这条表达式就是第 1 章讲的 " 趋势分析 " 的落地写法：不是等磁盘满了才告警，而是提前 4 小时预测它要满。
\n
\n
# 3.4.4　Histogram（直方图）
\n
\n
用于统计数据分布。服务端（Prometheus）负责计算分位数。
\n
\n
核心机制：累积桶（Cumulative Bucket）
\n
把取值范围切成若干连续、相邻但不重叠的区间（bucket），统计每个区间里有多少个观测值。累积的意思是： le="0.1"  的桶里，包含了所有 ≤0.1 的样本，也自然被计入  le="0.5"  的桶。
\n
一个 Histogram 指标会展开成多条时间序列：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
序列含义
<basename>_bucket{le="<上界>"}落入该桶（含更小桶）的样本数
<basename>_bucket{le="+Inf"}全部样本数（最后一个桶）
<basename>_sum所有观测值的总和
<basename>_count观测总次数（本质是 Counter）
\n
范例：
\n
# TYPE prometheus_tsdb_compaction_chunk_range_seconds histogram
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"100\"}        0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"400\"}        0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"1600\"}       0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"6400\"}       0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"25600\"}      0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"102400\"}     0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"409600\"}     0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"1.6384e+06\"} 0
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"6.5536e+06\"} 6028
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"2.62144e+07\"} 6028
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le=\"+Inf\"}      6028
prometheus_tsdb_compaction_chunk_range_seconds_sum   1.0734846288e+10
prometheus_tsdb_compaction_chunk_range_seconds_count 6028
读法：
\n\n
计算分位数：
\n
# 过去 10 分钟，HTTP 请求持续时间的第 90 百分位数
histogram_quantile(0.9, rate(prometheus_http_request_duration_seconds_bucket[10m]))
Histogram 的三个优势：
\n\n
# 3.4.5　Summary（摘要）
\n
\n
与 Histogram 类似，但分位数在客户端就算好了。
\n
\n
一个 Summary 的序列构成：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
序列含义
<basename>{quantile="<x>"}分位点  x  对应的值（0 ≤ x ≤ 1）
<basename>_sum样本值之和
<basename>_count样本总数
\n
范例：
\n
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile=\"0\"}    3.4414e-05
go_gc_duration_seconds{quantile=\"0.25\"} 5.0434e-05
go_gc_duration_seconds{quantile=\"0.5\"}  6.5102e-05
go_gc_duration_seconds{quantile=\"0.75\"} 9.2624e-05
go_gc_duration_seconds{quantile=\"1\"}    0.00109096
go_gc_duration_seconds_sum   0.02311494
go_gc_duration_seconds_count 229
# 3.4.6　Histogram vs Summary：一表定生死
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
维度HistogramSummary
分位数在哪算Prometheus 服务端（ histogram_quantile ）客户端（每次采样时算好）
能否事后换分位数✅ 任意（P50/P90/P99 随时算）❌ 只能用客户端预定义的
能否多实例聚合✅ 桶可相加后再算❌ 分位数不可聚合
客户端开销小（只是计数）大（要维护滑动窗口与分位计算）
服务端开销大（分位计算消耗资源）小（直接读数）
准确性受桶划分影响，是估算值客户端流式计算，相对精确
典型用途⭐ 绝大多数场景首选（请求耗时、响应大小）分位数固定、实例少、不能聚合的场景
\n
\n
🧠 选型口诀：能用 Histogram 就用 Histogram。
\n
因为 "分位数不能聚合" 是致命缺陷：你有 10 个实例，每个实例的 P99 是 100ms，整体 P99 绝不是 100ms—— 它可能差得很远。只有 Histogram 的桶相加后才能算整体的分位数。
\n
唯一例外：客户端只需暴露一个固定的高分位数（如 SLO 的 P99.9），且不需要聚合。
\n
\n
\n
⚠️ 严谨补充：笔记里说 Summary "不支持 sum 或 avg 一类的聚合运算"—— 这句话只对分位数成立。 <basename>_sum  和  <basename>_count  是可以正常聚合的（它们本质是 Counter）。所以 Summary 可以算平均值，不能算分位数。
\n
\n
# 3.4.7　一张决策树
\n
flowchart TD
    A[\"拿到一个指标\"] --> B{\"名字带 _total<br/>或 HELP 写 counter？\"}
    B -->|是| C[\"Counter<br/>必须配 rate / irate / increase\"]
    B -->|否| D{\"名字带 _bucket<br/>或 quantile？\"}
    D -->|_bucket| E[\"Histogram<br/>histogram_quantile 算分位\"]
    D -->|quantile| F[\"Summary<br/>直接读分位值\"]
    D -->|都不是| G[\"Gauge<br/>可直接画 / sum / avg / delta\"]
\n
# 3.5　二元运算符：从 "原始数据" 到 "业务指标"
\n
官方文档：https://prometheus.io/docs/prometheus/latest/querying/operators/
\n
三类二元运算符：算术、比较、逻辑。
\n
# 3.5.1　算术运算符
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
运算符含义
+加
-减
*乘
/除
%取模
^幂运算
\n
最实用的四个用法：
\n
# ① 单位换算：字节 → MB（除两次 1024）
node_memory_MemFree_bytes / 1024 / 1024
node_memory_MemFree_bytes / (1024 * 1024)      # 等价写法
# ② 可用内存百分比
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
# ③ 内存使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
  / node_memory_MemTotal_bytes * 100
# ④ 根分区磁盘使用率
(node_filesystem_size_bytes{mountpoint=\"/\"} - node_filesystem_free_bytes{mountpoint=\"/\"})
  / node_filesystem_size_bytes{mountpoint=\"/\"} * 100
\n
🔗 呼应第 1 章：1.4 节讲 "数据处理" 时，我们推导过内存使用率公式；1.5.1 节讲  free  vs  available  时，我们强调过 "只看 available"。上面第 ③ 条就是那个知识点的最终落地形态。
\n
\n
# ⭐ 关于 "字节换算成 GB"
\n
严格来说 1 GB = 1024³ 字节 = 1073741824。所以：
\n
node_memory_MemTotal_bytes / 1024 / 1024 / 1024     # 严格的 GiB
但很多运维习惯用  1024^3  而口语称 "GB"。在面板上标注清楚单位（GiB 还是 GB），比争论哪个更对更有意义。
\n
# 3.5.2　比较运算符
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
运算符含义
==等于
!=不等于
>   >=大于 / 大于等于
<   <=小于 / 小于等于
\n
# ⭐ 关键区别：加不加  bool
\n
这是 PromQL 与 "普通编程语言" 最大的不同点，必须理解透。
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
写法语义结果
expr > 80过滤（filter）只保留 "比较成立" 的序列，不成立的直接消失
expr > bool 80转换（bool）保留所有序列，成立的输出  1 ，不成立的输出  0
\n
# 只看 \"内存利用率 > 80%\" 的主机（结果集里没有那些主机，它们 \"消失\" 了）
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 80
# 输出 0/1，所有主机都保留（适合画状态图、做告警计数）
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > bool 80
# 请求数是否超过 1000 → 超了是 1，没超是 0
prometheus_http_requests_total > bool 1000
\n
📌 官方说明：使用  bool  后，布尔运算不会过滤时间序列，而是依次把每个样本与标量比较，结果  0  或  1  形成一条新时间序列。
\n
🎯 告警规则里大量使用 +bool 会比较 "好用"，但要注意：告警规则本身用  expr > 80  就够了（Alertmanager 只需要 "有没有结果"）。 bool  更适合画 "状态图" 和做 "计数"（如  count(up == bool 0)  数挂了几台）。
\n
\n
# 3.5.3　逻辑运算符（集合运算）
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
运算符含义类比 SQL
and交集INNER JOIN  /  INTERSECT
or并集UNION
unless补集（排除）EXCEPT  /  NOT IN
\n
# 并集：两个序列都出现（注意两者指标名不同，结果会各自保留）
node_memory_MemTotal_bytes{instance=\"10.0.0.104:9100\"}
  or node_memory_MemFree_bytes{instance=\"10.0.0.105:9100\"}
# 交集：两边都存在的序列才保留（左侧的序列留下，但只用左侧的 \"身份\" 匹配）
node_memory_MemTotal_bytes{instance=\"10.0.0.101:9100\"}
  and node_memory_MemFree_bytes{instance=\"10.0.0.104:9100\"}
# 补集：从左侧排除掉右侧匹配到的
node_memory_MemTotal_bytes{job=\"k8s-node\"}
  unless node_memory_MemTotal_bytes{instance=\"10.0.0.104:9100\"}
\n
⚠️ 注意  and  容易踩的坑：
\n and  的结果保留左侧的序列和值，右侧只是用来 "做匹配判断"。
\n上面第二个例子里，左右两边的  instance  不同（101 vs 104），没有共同的标签集 → 交集为空 → 结果什么都没有。这是新手最迷惑的地方。
\n
\n
\n
📌 限制： and  /  or  /  unless  只支持两个即时向量之间运算，不支持标量参与。
\n（算术与比较运算符是可以和标量运算的，例如  * 100 、 > 80 。笔记里 "不支持标量参与运算" 这句话，仅针对逻辑运算符。）
\n
\n
# 3.5.4　运算符优先级
\n
从高到低：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
优先级运算符
1^
2*   /   %
3+   -
4==   !=   <=   <   >=   >
5and   unless
6or
\n
规则：
\n\n
# 建议这样写，而不是依赖优先级
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100
\n
# 3.6　向量匹配：让两个指标 "对上号"
\n
# 3.6.1　默认规则：标签必须完全一致
\n
两个向量做二元运算时，Prometheus 要给左边每条序列在右边找到 "同一条" 序列。
\n
\n
默认要求：除  __name__  之外，所有标签必须完全一致。
\n
\n
大部分时候这没问题（比如  sum / count ，都是同一条序列的总和与总数）。但一旦两边标签 "不完全一样"，就匹配不上。
\n
go_gc_duration_seconds_sum{instance=\"prometheus:9090\", job=\"prometheus\"}
  / go_gc_duration_seconds_count{instance=\"prometheus:9090\", job=\"prometheus\"}
上面这样能算（两边标签一致），但如果写成：
\n
go_gc_duration_seconds_sum / go_gc_duration_seconds_count      # ✅ 也能算（同名标签）
一旦两侧标签集不同，就需要匹配修饰符。
\n
# 3.6.2　 ignoring  与  on
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
关键字含义
ignoring(<labels>)匹配时忽略这些标签
on(<labels>)匹配时只使用这些标签
\n
<vector expr> <bin-op> ignoring(<label list>) <vector expr>
<vector expr> <bin-op> on(<label list>) <vector expr>
# 3.6.3　一对一匹配（One-to-one）
\n
用官方例子把这件事讲透。 输入数据：
\n
# 左侧：按 method + code 统计的 5 分钟错误率
method_code:http_errors:rate5m{method=\"get\",  code=\"500\"} 24
method_code:http_errors:rate5m{method=\"get\",  code=\"404\"} 30
method_code:http_errors:rate5m{method=\"put\",  code=\"501\"}  3
method_code:http_errors:rate5m{method=\"post\", code=\"500\"}  6
method_code:http_errors:rate5m{method=\"post\", code=\"404\"} 21
# 右侧：按 method 统计的 5 分钟总请求量
method:http_requests:rate5m{method=\"get\"}  600
method:http_requests:rate5m{method=\"del\"}   34
method:http_requests:rate5m{method=\"post\"} 120
需求：算出 "每个 method 下 code=500 的请求占比"。
\n
method_code:http_errors:rate5m{code=\"500\"} / ignoring(code) method:http_requests:rate5m
为什么必须加  ignoring(code) ？
\n
因为左边有  method  和  code  两个标签，右边只有  method 。不忽略  code ，两边标签永远对不上，结果为空。
\n
结果：
\n
{method=\"get\"}  0.04    # 24 / 600
{method=\"post\"} 0.05    #  6 / 120
注意两个现象：
\n\n
# 3.6.4　多对一 / 一对多： group_left  与  group_right
\n
上例中，如果我想同时算出 500 和 404 的占比，左侧一个  method  对应多条序列（多个 code），右侧一个  method  只有一条 —— 这就是多对一。
\n
method_code:http_errors:rate5m / ignoring(code) group_left method:http_requests:rate5m
结果：
\n
{method=\"get\",  code=\"500\"} 0.04    # 24 / 600
{method=\"get\",  code=\"404\"} 0.05    # 30 / 600
{method=\"post\", code=\"500\"} 0.05    #  6 / 120
{method=\"post\", code=\"404\"} 0.175   # 21 / 120
 group_left  /  group_right  的语义：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
关键字含义记忆法
group_left左侧为 "多"，右侧为" 一 "把右侧那一条值，广播给左侧的多条
group_right右侧为 "多"，左侧为" 一 "反方向
\n
\n
🧠 一句话记住： left  /  right  标记的是 "多" 的那一侧。
\n名字有点反直觉 —— 它不是说 "多的一方在左边"，而是说 " 多的一侧是 left（或 right）"。
\n
\n
完整语法（四个字段可组合）：
\n
<vector expr> <bin-op> ignoring(<labels>) group_left(<labels>)  <vector expr>
<vector expr> <bin-op> ignoring(<labels>) group_right(<labels>) <vector expr>
<vector expr> <bin-op> on(<labels>)      group_left(<labels>)  <vector expr>
<vector expr> <bin-op> on(<labels>)      group_right(<labels>) <vector expr>
\n
💡  group_left(...)  括号里可以写 " 要从右侧额外带过来的标签 "。这是 kube-prometheus 里做  kube_pod_info * on(pod) group_left(node) ...  这类关联时的关键技巧。
\n
但请注意课件的态度：向量匹配本身比较复杂，初级运维阶段用得不多。先理解 "为什么需要 ignoring"，等 4.x 讲 k8s 与服务发现时再回头啃多对多。
\n
\n
# 3.6.5　⭐ 高频报错： vector cannot contain metrics with the same labelset
\n
先看一个 "看起来对、其实错" 的写法：
\n
# ❌ 报告里常见的错误写法
prometheus_http_requests_total{code=\"200\", handler=\"/-/reload\", instance=\"localhost:9090\"}
  / sum(prometheus_http_requests_total{handler=\"/-/ready\", instance=\"localhost:9090\"})
问题在哪？
\n\n
两边标签完全对不上 → 无匹配 → 结果为空。（不是语法错，是逻辑错，最坑的一类）
\n
正确写法（两边都聚合成同样 "无标签" 的形态）：
\n
# ✅ 200 响应码占全部请求的百分比
sum(prometheus_http_requests_total{code=\"200\", handler=\"/-/reload\", instance=\"localhost:9090\"})
  / sum(prometheus_http_requests_total{instance=\"localhost:9090\"})
另一个典型场景：
\n
# ✅ /metrics 这个 handler 占所有 handler 的百分比
sum(prometheus_http_requests_total{handler=\"/metrics\", instance=\"localhost:9090\"})
  / sum(prometheus_http_requests_total{instance=\"localhost:9090\"})
\n
💡 规律：算 "占比" 时，分子分母必须用相同的聚合维度。
\n分子  sum(...)  单序列、分母  sum(...)  单序列 → 一对一，完美匹配。
\n
\n
\n
# 3.7　聚合操作：从 "一堆数" 到 "一个结论"
\n
# 3.7.1　为什么必须聚合
\n
\n
单个指标的价值不大。 监控场景中往往需要把一组指标 "联合" 起来看。
\n
\n
聚合的本质：对一组值进行计算，返回单个值或少量值 —— 也就是数据库里说的 "聚合函数"。
\n
# 3.7.2　11 种聚合操作
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
操作符作用
sum()求和
avg()求平均值（指标数据分析的标准方法）
min()最小值
max()最大值
count()统计时间序列条数
count_values()按样本值分组计数（值计数）
topk()降序返回前 K 个最大值的序列
bottomk()升序返回前 K 个最小值的序列
quantile()返回分组内指定分位数
stddev()标准差（波动程度）
stdvar()方差（求标准差的中间量）
\n
两种格式：
\n
# 普通聚合
聚合操作符(表达式)                     →  sum(node_memory_MemTotal_bytes)
# 需要额外参数的聚合
聚合操作符(参数, 表达式)               →  topk(5, http_requests_total)
                                         count_values(\"os_version\", node_os_version)
                                         quantile(0.9, http_request_duration_seconds)
# 3.7.3　⭐  by  与  without ：等价于 SQL 的 GROUP BY
\n
这是本章最重要的语法点之一。
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
关键字语义类比
 by(<labels>) 只按这些标签分组统计，结果里只保留这些标签GROUP BY <labels>
 without(<labels>) 排除这些标签，用其余所有标签分组统计GROUP BY 除这些之外的所有列
\n
两种书写位置，完全等价：
\n
# 格式 1：by/without 写在括号外（推荐，读起来更像 SQL）
sum(node_memory_MemTotal_bytes) by (instance)
sum(node_memory_MemTotal_bytes) without (instance, job)
# 格式 2：by/without 写在函数名后
sum by (instance) (node_memory_MemTotal_bytes)
sum without (instance, job) (node_memory_MemTotal_bytes)
\n
💡 选哪个？ 官方文档示例用格式 2 较多，但格式 1 更接近 SQL 直觉。团队统一即可，别混用。
\n
\n
# 3.7.4　一串由浅入深的例子
\n
先看数据长什么样：
\n
node_os_version{id=\"ubuntu\", id_like=\"debian\", instance=\"10.0.0.200:9100\", job=\"node_exporter\", name=\"Ubuntu\"} 1
node_os_version{id=\"ubuntu\", id_like=\"debian\", instance=\"10.0.0.201:9100\", job=\"node_exporter\", name=\"Ubuntu\"} 1
node_os_version{id=\"ubuntu\", id_like=\"debian\", instance=\"10.0.0.202:9100\", job=\"node_exporter\", name=\"Ubuntu\"} 1
node_os_version{id=\"ubuntu\", id_like=\"debian\", instance=\"10.0.0.203:9100\", job=\"node_exporter\", name=\"Ubuntu\"} 1
① 数一数有几台 Ubuntu 主机
\n
count(node_os_version{id=\"ubuntu\"})        # → 4
② 按操作系统版本分别统计数量
\n
count_values(\"os_version\", node_os_version)
# {os_version=\"22.04\"} 4
# {os_version=\"20.04\"} 2
\n
💡  count_values("标签名", expr)  会创建一个新标签，值为样本值本身，然后统计每个值出现了几次。这是 "按值分布统计" 的神器。
\n
\n
③ 所有主机的内存总和
\n
sum(node_memory_MemTotal_bytes)            # 单条结果，无标签
④ 每台主机的内存总量（分组）
\n
sum(node_memory_MemTotal_bytes) by (instance)
# {instance=\"10.0.0.101:9100\"} 2.1e+09
# {instance=\"10.0.0.102:9100\"} 2.1e+09
# ...
\n
⚠️ 注意一个容易迷惑的现象： sum(...) without (instance, job)  和  sum(...) by (instance)  结果不同！
\n\n
想清楚 "我要的结果带哪些标签"，再决定用  by  还是  without 。
\n
\n
⑤ 数每台主机的 CPU 核心数
\n
count(node_cpu_seconds_total{mode=\"system\"})              # 所有主机加起来多少个核
count(node_cpu_seconds_total{mode=\"system\"}) by (instance) # 每台主机几个核
\n
💡 这个技巧很实用： node_cpu_seconds_total  每条序列对应一个  cpu  核心，数序列条数 = 数核心数。
\n
\n
⑥ 找最忙的接口 / 最大的值
\n
max(prometheus_http_requests_total)
max(prometheus_http_requests_total) by (handler, instance)
topk(5, prometheus_http_requests_total)      # 前 5 大
bottomk(5, prometheus_http_requests_total)   # 前 5 小
\n
💡  topk  /  bottomk  相当于 SQL 的  ORDER BY ... LIMIT K 。注意： topk  会保留原始标签（不是聚合掉），所以你能看到 "是哪条序列"。
\n
\n
⑦ 按 mode 分组看 CPU 时间
\n
sum(node_cpu_seconds_total) by (mode)
⑧ 多维度分组
\n
count(prometheus_http_requests_total) by (code, instance, job)
# 3.7.5　⭐ 报错现场：算 "占比" 时的标签不匹配
\n
这是运维工作中最高频的 PromQL 报错，值得单独讲。
\n
# ❌ 报错：vector cannot contain metrics with the same labelset
nginx_http_requests_total{path=\"/api\", method=\"GET\", code=\"200\"}
  / sum(nginx_http_requests_total{path=\"/api\", method=\"GET\"})
症状：要么报  labelset  冲突，要么返回空。
\n
根因：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
侧标签集
左path 、 method 、 code 、 instance 、 job
右空（ sum()  清空了所有标签）
\n
标签对不上 → 要么无匹配（空结果），要么在全无标签的情况下多对一冲突。
\n
正确写法 —— 两边聚合到同一粒度：
\n
# ✅ 200 占比
sum(nginx_http_requests_total{path=\"/api\", method=\"GET\", code=\"200\"})
  / sum(nginx_http_requests_total{path=\"/api\", method=\"GET\"})
  * 100
如果确实要保留  code  维度：
\n
# ✅ 每个 code 占该 path+method 总量的比例
sum(nginx_http_requests_total{path=\"/api\", method=\"GET\"}) by (code)
  / ignoring(code) group_right
  sum(nginx_http_requests_total{path=\"/api\", method=\"GET\"})
\n
🎯 面试加分点：能说出 "算占比时分子分母必须同粒度聚合" 并且知道用  ignoring  +  group_right  保留维度，说明你真的写过 PromQL，不是背的。
\n
\n
\n
# 3.8　功能函数：让 Counter 变得有意义
\n
官方文档：https://prometheus.io/docs/prometheus/latest/querying/functions/
\n
Prometheus 内置函数有数十个，按官方分组主要分四类：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
分类代表函数
计算相关abs   deriv   exp   ln   log2   log10   sqrt   ceil   floor   round   delta   idelta   increase   rate   irate   resets   holt_winters   histogram_quantile   predict_linear   *_over_time
取样相关absent   sort   sort_desc   changes   scalar   clamp_max   clamp_min   absent_over_time
时间相关time   timestamp   hour   minute   month   year   day_of_month   day_of_week   days_in_month
标签相关label_join   label_replace
\n
# 3.8.1　取整三兄弟（别搞混）
\n
ceil(node_load15 * 10)      # 向上取整：4.1 → 5, 4.9 → 5
floor(node_load15 * 10)     # 向下取整：4.1 → 4, 4.9 → 4  ← 直接砍掉小数，不看大小
round(node_load15 * 10)     # 四舍五入：4.1 → 4, 4.9 → 5
\n
🧠  floor  不是四舍五入！ 它是 "把小数部分直接删掉"。 floor(4.9) = 4 ，这跟  round(4.9) = 5  完全不同。这是最容易答错的一个。
\n
\n
# 3.8.2　⭐ 核心四兄弟： increase  /  rate  /  irate  /  delta
\n
这是全章最需要 "真的理解" 的部分。
\n
先看它们各自的定义：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
函数输入输出一句话
increase(v[d])range vector区间内增长总量"这段时间一共涨了多少"
rate(v[d])range vector每秒平均增长率"平均下来每秒涨多少"
irate(v[d])range vector最近两点的瞬时增长率"现在这一刻每秒涨多少"
delta(v[d])range vector区间首尾差值（可负）给 Gauge 用，不是给 Counter 用
idelta(v[d])range vector最近两点差值给 Gauge 用
\n
\n
⚠️ 先纠正一个常见误解： increase()  不是 "最后两个点相减"。
\n它等于  rate(v[d]) × 区间秒数 ，也就是基于区间首尾值做外推估算得到的增长总量。
\n（笔记里写 "increase = last 值 − last 前一个值"，那是  idelta  的语义，不是  increase 。）
\n
\n
# 用 "薪水" 理解  increase  和  rate （讲师原话，非常好用）
\n
假设你的月薪从 1 万 涨到了 2 万：
\n\n
\n
结论：光看 "涨了多少" 意义不大，"单位时间涨了多少" 才有意义。这就是  rate 。
\n
\n
rate=区间末值−区间首值区间秒数\\text{rate} = \\frac{\\text{区间末值} - \\text{区间首值}}{\\text{区间秒数}}\nrate=区间秒数区间末值−区间首值​
\n
#  rate  的计算方式与 "被平均" 问题
\n
假设采集间隔 10s，取  [1m] ，区间内有 6 个采样点：
\n
t=0s    t=10s   t=20s   t=30s   t=40s   t=50s   t=60s\n 100     110     120     130     140     150     160\n  ↑                                              ↑\n首值                                           末值\n\nrate   = (160 - 100) / 60 = 1.0   ← 只用首尾两个点，中间 4 个点被"忽略"\n
\n
问题：如果中间发生了剧烈波动（比如  t=50s  时突然涨到 500 又回落）， rate  完全看不出来 —— 因为它已经把这段变化 "平均" 掉了。
\n
#  irate  的计算方式：只看最后两步
\n
irate = (末值 - 末值前一个点) / 这两点的时间差\n      = (160 - 150) / 10 = 1.0    ← 只看最后两个点\n
\n
优势：能反映最近一瞬间的变化，尖峰不会被抹平。
\n
# 一张图对比
\n
场景：前 50 秒请求量平稳（0~10），最后 10 秒暴增到 100+\n\n         rate（平均）              irate（瞬时）\n         ┌────────────────┐        ┌────────────────┐\n   数值  │      ╱         │        │              ╱ │\n        │    ╱           │        │            ╱   │\n        │  ╱             │        │          ╱     │\n        └────────────────┘        └────────────────┘\n          平缓、削平了峰值            尖锐、捕捉到尖峰\n\n   适合：SLO 统计、容量规划        适合：突发流量、异常检测\n
\n
\n
📌 官方建议：
\n\n
\n
# 实战写法
\n
# ① 单块磁盘过去 1 分钟的读取速率
rate(node_disk_read_bytes_total[1m])
irate(node_disk_read_bytes_total[1m])
# ② 网卡出口流量（MB/s）
rate(node_network_transmit_bytes_total{device=\"eth0\"}[1m]) / 1024 / 1024
# ③ 最近 1 分钟 CPU 空闲时间增量
increase(node_cpu_seconds_total{cpu=\"0\", mode=\"idle\"}[1m])
# ④ ⭐ CPU 使用率（最经典的写法）
(1 - avg by (instance) (irate(node_cpu_seconds_total{mode=\"idle\"}[5m]))) * 100
第 ④ 条拆解：
\n
    \n
  1. node_cpu_seconds_total{mode="idle"}[5m]  —— 所有 CPU 所有核的空闲时间（range vector）
    2. \n
  2. irate(...)  —— 每个核的空闲速率（instant vector）
    3. \n
  3. avg by (instance)(...)  —— 把 "多核" 平均掉，得到 "这台机器的平均空闲率"（0~1）
    4. \n
  4. 1 - ...  —— 得到使用率（0~1）
    5. \n
  5. * 100  —— 转成百分比
    6. \n
\n
\n
💡 为什么用  avg by (instance)  而不是  sum ？
\n因为每个核的  idle  速率已经是 0~1 的比例，平均才对； sum  会得到 "核心数" 倍的值，完全错。
\n这是 PromQL 里最容易算错的指标，面试高频。
\n
\n
# 另一个经典：QPS
\n
# 每秒请求数（QPS）
sum by (handler) (rate(prometheus_http_requests_total[5m]))
# 5xx 错误率是否超过总请求的 10%
rate(http_requests_total{status_code=~\"5.*\"}[5m])
  > rate(http_requests_total[5m]) * 0.1
# 3.8.3　 time()  与运行时长
\n
# 每台主机已运行多少小时
(time() - node_boot_time_seconds) / 3600
# 所有主机运行时间总和
sum(time() - node_boot_time_seconds) / 3600
\n
💡  time()  返回 "当前时间戳"， node_boot_time_seconds  返回 "开机时间戳"，相减就是 uptime—— 这是一个非常经典的 "两个指标相减" 的用法。
\n
\n
# 3.8.4　 histogram_quantile ：算分位数
\n
# 过去 10 分钟 HTTP 请求耗时的 P90
histogram_quantile(0.9, rate(prometheus_http_request_duration_seconds_bucket[10m]))
三个使用要点：
\n
    \n
  1. 必须配合  rate() （ _bucket  是 Counter，累加值不能直接算分位）；
    2. \n
  2. 必须用  _bucket  序列，不是  _sum  /  _count ；
    3. \n
  3. 结果只是估算值，精度取决于桶的划分。桶太少、太粗，误差会很大。
    4. \n
\n
按维度分组算：
\n
histogram_quantile(0.9,
  sum by (le, handler) (rate(http_request_duration_seconds_bucket[5m]))
)
\n
⚠️ 注意  sum by (le, handler)  里必须保留  le ！ 丢了  le ，函数就不知道桶边界，直接报错。这是新手最常见的  histogram_quantile  错误。
\n
\n
# 3.8.5　 absent ：专门为告警设计
\n
absent(node_memory_SwapTotal_bytes)
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
情况返回值
有数据空（无结果）
没数据1
\n
\n
💡 用途："指标消失了" 本身就是要告警的事件。 比如某个 Exporter 挂了， node_memory_*  全没了 —— 这时候正常表达式会返回空，告警不会触发，你就 "什么都不知道"。用  absent()  才抓得住这种 "彻底失联"。
\n
这条是告警规则设计的必备技巧，第 5 章会反复用到。
\n
\n
# 3.8.6　标签处理函数
\n
# label_replace：用正则重命名 / 改写标签
label_replace(up, \"host\", \"$1\", \"instance\", \"(.*):.*\")
# label_join：把多个标签拼成一个
label_join(up, \"endpoint\", \"/\", \"instance\", \"job\")
\n
⚠️ 重要提醒： label_replace  /  label_join  是查询时的临时改写，不会改变存储中的序列。真正的 "标签管理" 要用第 4 章的  relabel_configs  /  metric_relabel_configs —— 那是落盘的、永久的。
\n
\n
\n
# 3.9　本章小结
\n
mindmap
  root((\"第3章<br/>PromQL\"))
    类型系统
      instant vector 可画图
      range vector 只能进函数
      scalar
      string
    选择器
      指标名
      四种匹配器
      正则全锚定
      范围 m h d w y
      offset 移基点
    指标类型
      Counter 配 rate
      Gauge 可直画
      Histogram 服务端算分位
      Summary 客户端算分位
    二元运算
      算术 单位换算
      比较 bool 不过滤
      逻辑 and or unless
      向量匹配 ignoring group
    聚合
      sum avg min max count
      topk bottomk
      count_values
      by without
    函数
      rate 平均
      irate 瞬时
      increase 增量
      delta Gauge 差值
      histogram_quantile
      predict_linear
      absent
七条必须带走的知识：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
#知识为什么重要
1范围向量不能直接画图必须先降维（ rate / avg_over_time ）
2 =~  是整值匹配不写  .*  就匹配不到
3Counter 的总数没意义必须配  rate / irate / increase
4 > 80  过滤、 > bool 80  转换决定结果里 "有没有这条序列"
5 rate  被平均、 irate  抓瞬时选错就看不到尖峰
6算占比分子分母必须同粒度否则空结果或 labelset 报错
7CPU 使用率用  avg by(instance) ，不是  sum sum  结果会乘上核心数
\n
\n
# 3.10　面试高频问答
\n
Q1： rate  和  irate  有什么区别？分别什么时候用？
\n
\n
rate  用区间首尾两个值相减再除以区间秒数，得到平均增长率，会把中间的波动抹平； irate  用最后两个采样点相减除以它们的时间差，得到瞬时增长率，能反映尖峰。
\n快速变化的计数器（高 QPS 接口、突发流量）用  irate ；缓慢变化的计数器（磁盘 IO、网络流量、SLO 统计）用  rate 。
\n
\n
Q2：为什么不能直接画  node_cpu_seconds_total ？
\n
\n
因为它是 Counter，值是 "开机至今的累计秒数"，单调递增，画出来就是一条斜线，毫无意义。必须用  rate  /  irate  转成 "每秒的增长率" 才有观察价值。
\n
\n
Q3： by  和  without  有什么区别？
\n
\n
by(labels)  是白名单：只按这些标签分组，结果只保留这些标签，等价于 SQL 的  GROUP BY 。
\n without(labels)  是黑名单：排除这些标签，用其余全部标签分组，结果保留除它们外的所有标签。
\n
\n
Q4：Histogram 和 Summary 怎么选？
\n
\n
优先 Histogram。因为 Histogram 的分位数由服务端用  histogram_quantile  计算，桶可以跨实例相加，所以能算全局分位数，也能事后换分位数；Summary 的分位数在客户端算好，不可聚合（10 个实例的 P99 不能相加得到整体 P99），只能用预定义的分位点。
\nSummary 只适合分位数固定、实例少、不需要聚合的场景。代价是 Histogram 受桶划分影响，结果是估算值。
\n
\n
Q5： absent()  有什么用？
\n
\n
检测 "指标完全消失" 的情况。有数据返回空，无数据返回 1。因为普通表达式在指标消失时返回空结果，告警不会触发，而 "Exporter 挂了" 恰恰是最需要告警的场景。
\n
\n
Q6： > 80  和  > bool 80  有什么区别？
\n
\n
> 80  是过滤：只保留满足条件的序列，不满足的直接从结果中消失。
\n > bool 80  是转换：保留所有序列，满足的返回 1，不满足的返回 0，从而形成一条新的 0/1 时间序列。适合画状态图和做计数。
\n
\n
Q7：算占比时经常没结果，怎么排查？
\n
\n
九成是分子分母聚合粒度不一致：一边带多个标签、一边被  sum()  清空，导致两边标签集对不上、无法匹配。解决方法是两边都用相同维度聚合（如都  sum() ），或者用  ignoring(...)  /  group_left  明确匹配规则。
\n
\n
\n
# 3.11　动手实验
\n
# 实验一　类型识别训练
\n
打开  http://<node>:9100/metrics ，找出下面这些指标，判断类型并写出正确的查询写法：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
指标类型正确写法
node_cpu_seconds_total??
node_memory_MemAvailable_bytes??
node_filesystem_size_bytes??
node_load1??
node_boot_time_seconds??
\n
\n
参考答案要点： cpu_seconds_total  是 Counter → 配  rate ； MemAvailable  是 Gauge → 直接算比例； filesystem_size  是 Gauge → 算使用率； load1  是 Gauge → 直接画或  avg_over_time ； boot_time  是 Gauge（但语义是时间戳）→ 配  time()  相减。
\n
\n
# 实验二　写出五个业务指标
\n
在 Graph 页面依次跑通，并解释每一步：
\n
# 1. 单位换算：可用内存（MB）
node_memory_MemAvailable_bytes / 1024 / 1024
# 2. 可用内存百分比
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
# 3. 内存使用率 > 70% 的主机（过滤）
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 70
# 4. 同上，但输出 0/1（转换）
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > bool 70
# 5. 根分区使用率
(node_filesystem_size_bytes{mountpoint=\"/\"} - node_filesystem_free_bytes{mountpoint=\"/\"})
  / node_filesystem_size_bytes{mountpoint=\"/\"} * 100
思考题：第 3 条和第 4 条的结果有什么不同？分别在什么场景下用？
\n
# 实验三　 rate  vs  irate  的肉眼对比
\n
# 制造流量尖峰：平稳访问 → 突然猛刷
while true; do curl -s http://<your-app>:8001/metrics > /dev/null; sleep 1; done
# 另一个终端执行 \"暴刷\"
while true; do curl -s http://<your-app>:8001/metrics > /dev/null; done
在 Grafana 同一个面板上画两条曲线：
\n
rate(request_count_total[1m])
irate(request_count_total[1m])
观察：哪条曲线更早反映出暴刷？哪条更平滑？把这幅图记在脑子里，以后选函数就不会错。
\n
# 实验四　聚合练习
\n
# 1. 数主机数
count(node_os_version)
# 2. 按系统版本分组统计
count_values(\"os_version\", node_os_version)
# 3. 每台主机的内存总量
sum(node_memory_MemTotal_bytes) by (instance)
# 4. 全部主机内存总和
sum(node_memory_MemTotal_bytes)
# 5. 每台主机的 CPU 核心数
count(node_cpu_seconds_total{mode=\"system\"}) by (instance)
# 6. 内存占用最多的前 3 台
topk(3, node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
# 7. /metrics 接口占总请求的百分比
sum(prometheus_http_requests_total{handler=\"/metrics\", instance=\"localhost:9090\"})
  / sum(prometheus_http_requests_total{instance=\"localhost:9090\"}) * 100
# 实验五　故意犯错（很重要）
\n
依次执行下面的错误写法，把报错信息抄下来：
\n
# ① 范围向量直接画图
node_load1[5m]
# ② 正则没写 .*
node_cpu_seconds_total{mode=~\"idle\"}
# ③ 全空标签（应被拒绝）
{job=~\".*\"}
# ④ 占比分子分母粒度不同
prometheus_http_requests_total{code=\"200\", handler=\"/-/reload\", instance=\"localhost:9090\"}
  / sum(prometheus_http_requests_total{handler=\"/-/ready\", instance=\"localhost:9090\"})
\n
💡 认得报错，比背对语法更有价值。 真实故障现场，你看到的一定是报错信息。
\n
\n
\n
# 3.12　下章预告
\n
PromQL 会写了，但还有两个 "咽不下去" 的问题：
\n
    \n
  1. 业务指标从哪来？ 公司自研的 Java / Python 程序，既没有  /metrics ，也没有现成 Exporter—— 只能自己写一个。
    2. \n
  2. 标签为什么会错？ 明明采集到了，Grafana 面板却是空的；想删掉没用的指标却不知道从哪下手。
    3. \n
\n
下一章解决：
\n\n
本章作业：把 "七条必须带走的知识" 背下来，并且能不看笔记写出 CPU 使用率和内存使用率两条表达式。这两条是运维面试的 "入场券"。
\n",
            "tags": [
                "Prometheus"
            ]
        },
        {
            "id": "http://blog.jaxxwang.cn/posts/3486386405.html",
            "url": "http://blog.jaxxwang.cn/posts/3486386405.html",
            "title": "02 部署与点亮：让 Prometheus 真正跑起来",
            "date_published": "2026-10-23T16:00:00.000Z",
            "content_html": "
# 第 2 章　部署与点亮：让 Prometheus 真正跑起来
\n
\n
本章导读
\n
第 1 章我们讲了架构，但架构是 "纸上的图"。本章开始动手，把图上的每一个方框都变成一台机器上的一个进程。
\n
这一章信息密度很高，涉及五个软件的安装、一份配置文件的逐行讲解、以及六个真实踩过的坑。请务必不要跳过 "故障现场" 这类小节 —— 面试官不问你装成功过什么，只问你出过错之后怎么定位的。
\n
一句话总结本章目标：把 9090（Prometheus）、9100（Node Exporter）、3000（Grafana）、9091（Pushgateway）这四个端口全部点亮，并且能在 Grafana 上看到四台主机的 CPU 曲线。
\n
\n
学习目标
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
序号学完本章，你应当能够
1独立完成 Prometheus Server 的二进制安装，并写出规范的 systemd 服务单元
2解释  --web.enable-lifecycle  的作用与安全风险，说明生产环境为何要禁用
3逐行读懂  prometheus.yml  的四段式结构，独立新增一个采集 job
4用  promtool  做配置语法检查，并说清 "不重启生效" 的三种方式
5用 Docker / Docker Compose 跑起 Prometheus，并正确处理配置与数据两个持久化问题
6在任意节点上部署 Node Exporter，并让 Prometheus 采集到它
7用 "五步法" 排查 "目标抓不到数据" 的故障
8完成 Grafana 的数据源配置与社区 Dashboard 导入，并解释 "监控 Grafana 自己为什么绕一圈"
9说清 Pushgateway 的适用场景、工作原理与四个固有缺陷
\n
\n
# 2.1　开工之前：先把拼图摆好
\n
# 2.1.1　五个软件，各管一段
\n
第 1 章我们列过组件职责表，现在把它落成 "要装什么"：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
软件默认端口一句话职责类比 Zabbix
Prometheus Server9090拉取指标 + 内置 TSDB 存储 + 规则计算zabbix-server  + 数据库
Node Exporter9100把本机的 CPU / 内存 / 磁盘 / 网络指标用 HTTP 暴露出来 zabbix-agent 
Grafana3000把数据画成漂亮的图zabbix-web （但强太多）
Alertmanager9093接收告警、去重、分组、路由、发送内置告警动作（本章不展开）
Pushgateway9091给 "抓不到" 的瞬时指标当中转代理 zabbix-proxy （角色相近）
\n
\n
📌 一个重要认知：Prometheus Server 只做两件事 —— 采集、存储。它自带的那个 Web 界面（9090）只用于调试查询，从来没打算让你拿它当监控大屏。所以 "要装 Grafana" 不是可选项，而是必选项。
\n
\n
# 2.1.2　部署拓扑：谁装在哪
\n
flowchart TB
    subgraph MON[\"监控服务器（可合设，也可分离部署）\"]
        direction LR
        P[\"Prometheus Server<br/>:9090\"]
        G[\"Grafana<br/>:3000\"]
        PG[\"Pushgateway<br/>:9091\"]
        P <-->|PromQL 查询| G
        PG -->|被 Pull| P
    end
    subgraph NODES[\"被监控节点\"]
        direction LR
        N1[\"node101<br/>Node Exporter :9100\"]
        N2[\"node102<br/>Node Exporter :9100\"]
        N3[\"node103<br/>Node Exporter :9100\"]
        N4[\"监控服务器自己<br/>Node Exporter :9100\"]
    end
    N1 -->|Pull /metrics| P
    N2 -->|Pull /metrics| P
    N3 -->|Pull /metrics| P
    N4 -->|Pull /metrics| P
三条部署原则（经验，不是规定）：
\n
    \n
  1. Prometheus / Grafana / Pushgateway 可以装在同一台（实验环境、小规模环境），也可以分开装。分开装的好处是性能互不干扰、故障不连带。
    2. \n
  2. Node Exporter 必须装在被监控的每一台机器上，一台不能少 —— 包括 Prometheus 自己那台，因为监控系统本身也需要被监控。
    3. \n
  3. 生产环境请把  --storage.tsdb.path （数据目录）独立挂一个分区，避免数据把根分区写满导致整机不可用。
    4. \n
\n
# 2.1.3　版本怎么选：先看兼容性
\n
监控栈是 "多组件协同"，版本乱配最容易出问题。下面是一套经过验证、兼容性良好的企业级组合：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
组件推荐版本示例文件
Prometheus2.53.xprometheus-2.53.2.linux-amd64.tar.gz
Alertmanager0.27.xalertmanager-0.27.0.linux-amd64.tar.gz
Node Exporter1.8.xnode_exporter-1.8.2.linux-amd64.tar.gz
Grafana11.xgrafana-enterprise_11.2.0_amd64.deb
Pushgateway1.10.xpushgateway-1.10.0.linux-amd64.tar.gz
\n
\n
⚠️ 关于 2.x 还是 3.x
\n
Prometheus 已经发布了 3.x，并且提供了 LTS（长期支持） 版本。课程的演示环境用的是 3.5.0 LTS，功能上比 2.x 多了些改进。
\n但要注意：大量企业存量环境仍然是 2.53.x，生态里的部分 Exporter、Dashboard、规则文件是按 2.x 写的。所以：
\n\n
\n
# 2.1.4　六种部署方式
\n
官方文档：https://prometheus.io/docs/prometheus/latest/installation/
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
方式适用场景一句评价
包安装（apt /yum）快速验证、小规模最省事，但版本由仓库决定，往往偏旧
二进制安装生产主力（学完再看第 4 行）版本可控、零依赖，必须掌握
Ansible批量部署几十上百台有现成 Role，改改变量就行
Docker快速起、CI 环境一条命令，注意挂载
Docker Compose一键起整套监控栈适合实验与中小规模
Kubernetes云原生环境用 kube-prometheus / Operator / Helm
\n
\n
💡 学习路径建议：先二进制，再容器。
\n你只有先在裸机上手动装过一遍，才知道容器里那个  -v  到底在挂什么、那个  --config.file  到底指向哪。反过来学，你会永远停留在 "复制粘贴能跑，坏了不会修" 的层次。
\n
\n
\n
# 2.2　方式一：包安装（5 分钟上手）
\n
# 2.2.1　Ubuntu / Debian
\n
Ubuntu 的官方仓库里直接带 Prometheus 包：
\n
# 先看看仓库里有哪个版本
apt list prometheus
# ubuntu 22.04
# prometheus/jammy 2.31.2+ds1-1ubuntu1 amd64
# ubuntu 24.04
# prometheus/noble-security 2.45.3+ds-2ubuntu0.2 amd64
apt -y install prometheus
装完服务自动启动，并且 —— 这是很多人不知道的一点 —— 包里自带了一个 Node Exporter：
\n
systemctl status prometheus
systemctl status prometheus-node-exporter.service
ss -ntlp | grep prometheus
# LISTEN 0 4096 *:9090 users:((\"prometheus\",pid=2969,fd=4))
# LISTEN 0 4096 *:9100 users:((\"prometheus-node\",pid=2195,fd=3))
所以你会看到 9090 和 9100 同时被监听，进程名分别是  /usr/bin/prometheus  和  /usr/bin/prometheus-node-exporter 。
\n
\n
💡 包安装的价值：适合 "我今天就想看一眼 Prometheus 长啥样"。它的配置文件在  /etc/prometheus/prometheus.yml ，数据目录在  /var/lib/prometheus ，都由打包者安排好了，你不用操心。
\n
\n
# 2.2.2　RHEL / Rocky / CentOS
\n
RHEL 系默认没有 Prometheus 仓库，需要自己配  yum  repo（packagecloud 提供）：
\n
[prometheus]
name=prometheus
baseurl=https://packagecloud.io/prometheus-rpm/release/el/$releasever/$basearch
repo_gpgcheck=1
enabled=1
gpgkey=https://packagecloud.io/prometheus-rpm/release/gpgkey
       https://raw.githubusercontent.com/lest/prometheus-rpm/master/RPM-GPG-KEY-prometheus-rpm
gpgcheck=1
metadata_expire=300
\n
⚠️ 包安装的两大局限（也正是生产偏爱二进制的原因）：
\n
    \n
  1. 版本被仓库锁死，仓库里是什么版本你就用什么版本，通常落后官方好几个小版本，甚至大版本；
    2. \n
  2. 目录布局固定，想自定义数据目录、想和别的实例并存，就很别扭。
    3. \n
\n
\n
\n
# 2.3　方式二：二进制安装（生产标准做法）
\n
# 2.3.1　为什么 Go 程序装起来这么简单
\n
Prometheus 全套组件都是 Go 写的，编译产物是静态链接的单一二进制文件。这意味着：
\n\n
验证一下就明白了：
\n
ldd prometheus promtool
# prometheus:
#     不是动态可执行文件
# promtool:
#     不是动态可执行文件
"不是动态可执行文件"，就是静态编译的意思。
\n
# 2.3.2　下载与解压
\n
官方下载：https://prometheus.io/download/
\n 历史版本：https://github.com/prometheus/prometheus/releases
\n
cd /usr/local
wget https://github.com/prometheus/prometheus/releases/download/v2.53.2/prometheus-2.53.2.linux-amd64.tar.gz
tar xf prometheus-2.53.2.linux-amd64.tar.gz
# 建软链接，去掉版本号，将来升级只改软链
ln -s prometheus-2.53.2.linux-amd64 prometheus
\n
💡 软链接的价值：以后从 2.53.2 升级到 2.53.3，只需要解压新目录、把软链指过去、重启服务。所有配置和 systemd 单元里的路径一个字都不用改。这是运维的标准习惯。
\n
\n
\n
⚠️ 国内下载慢的老问题：GitHub 直连经常断。稳妥做法是一次性把安装包下载好，随安装脚本一起分发，做离线安装 —— 生产环境装东西，永远不要指望 "现场 wget 能成功"。
\n
\n
解压后目录内容：
\n
/usr/local/prometheus/
├── console_libraries/      # 内置控制台模板的库
├── consoles/               # 内置控制台模板
├── LICENSE                 # 可以删
├── NOTICE                  # 可以删
├── prometheus              # ★ 主程序
├── prometheus.yml          # ★ 默认配置
└── promtool                # ★ 运维神器（语法检查/查询调试/TSDB 工具）
# 2.3.3　目录规划与权限
\n
原始包里的文件平铺在一起，不够规整。按 "程序 / 配置 / 数据" 分离：
\n
cd /usr/local/prometheus
mkdir bin conf data
mv prometheus promtool bin/
mv prometheus.yml conf/
# 创建专用的服务账号：不要用 root，也不要让它能登录 shell
useradd -r -s /sbin/nologin prometheus
# 统一属主属组
chown -R prometheus:prometheus /usr/local/prometheus/
最终结构：
\n
/usr/local/prometheus/
├── bin/       prometheus, promtool
├── conf/      prometheus.yml
└── data/      ← TSDB 数据（不建也行，首次启动会自动创建）
\n
📌  -r  表示系统账号（UID 较小、默认不建家目录）， -s /sbin/nologin  表示禁止交互登录。服务账号就该是这种 "只存在、不登录" 的形态，安全上更干净。
\n
\n
再把  bin  加到 PATH，省得每次写全路径：
\n
cat > /etc/profile.d/prometheus.sh <<'EOF'
export PROMETHEUS_HOME=/usr/local/prometheus
export PATH=${PROMETHEUS_HOME}/bin:$PATH
EOF
source /etc/profile
# 2.3.4　第一次启动：先让它 "裸跑" 一下
\n
主程序参数很多，但初始化阶段只需要关心两个：
\n
prometheus --help | head -20
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
参数含义默认值
--config.file配置文件路径prometheus.yml （相对于当前工作目录）
--web.listen-addressUI / API 监听地址0.0.0.0:9090
--storage.tsdb.pathTSDB 数据目录data/
\n
先什么都不带，直接跑一次，你会看到报错：
\n
cd /usr/local/prometheus/bin
./prometheus
# level=error msg=\"Error loading config\" err=\"open prometheus.yml: no such file or directory\"
\n
🧠 为什么？ 因为默认配置文件名是相对路径  prometheus.yml ，它在当前工作目录下找。而我们刚把配置文件挪到了  conf/ 。
\n
\n
那就在上层的工作目录里启动，把配置路径指过去：
\n
cd /usr/local/prometheus
./bin/prometheus --config.file=conf/prometheus.yml
起来了。此时浏览器访问  http://<IP>:9090  就能看到那个 "简陋但够用" 的 Web 界面。
\n
# 2.3.5　⭐ 故障现场一：以 root 启动过一次，之后再也起不来
\n
这是初学者 90% 会踩、且完全不知道原因的坑。完整重现一遍：
\n
现象：手动用  root  跑通了，然后删掉进程、改成 systemd 以  prometheus  用户启动，服务起不来。
\n
systemctl start prometheus
systemctl status prometheus
# 一直 failed
排查过程（这才是重点）：
\n
    \n
  1. 先看端口有没有起来 —— ss -ntlp | grep 9090 ，没有。
    2. \n
  2. 再看服务状态 —— systemctl status prometheus ，只有一行 "启动失败"，信息不够。
    3. \n
  3. 看日志 —— journalctl -u prometheus -n 50 --no-pager （或看  /usr/local/prometheus/data  同级目录下有没有生成日志文件），发现关键的一句：
    4. \n
\n
msg=\"Error opening storage\" err=\"open /usr/local/prometheus/data/queries.active: permission denied\"
    \n
  1. 验证猜想 —— ls -l /usr/local/prometheus/data/ ，发现里面的文件属主是  root:root 。
    2. \n
\n
根因：
\n
\n
我第一次是用 root 身份手动启动的，Prometheus 在  data/  目录下自动创建了  queries.active 、 lock 、 wal/  等文件，属主全部是 root。
\n现在 systemd 以  prometheus  普通用户启动，去写这些 root 拥有的文件 —— 权限不足。
\n
\n
解决：
\n
chown -R prometheus:prometheus /usr/local/prometheus/
# 特别是 data 目录，重新设一遍
chown -R prometheus:prometheus /usr/local/prometheus/data
systemctl restart prometheus
\n
⭐ 这条经验请写进笔记：
\n调试阶段用哪个身份启动，生产就用哪个身份。
\n不要图省事用 root 试跑 —— 它会污染数据目录、日志文件、以及你自己都没意识到的 PID 文件。"先 root 试跑，再改普通用户" 是典型的错误顺序。
\n
\n
# 2.3.6　写 systemd 服务单元
\n
标准单元文件（Ubuntu 在  /lib/systemd/system/ ，Rocky 在  /usr/lib/systemd/system/ ，两者都兼容  /etc/systemd/system/ ）：
\n
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target
[Service]
Restart=on-failure
User=prometheus
Group=prometheus
WorkingDirectory=/usr/local/prometheus/
ExecStart=/usr/local/prometheus/bin/prometheus \\
          --config.file=/usr/local/prometheus/conf/prometheus.yml
ExecReload=/bin/kill -HUP $MAINPID
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
逐行解释，这几行每一行都有用：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
配置作用为什么必须有
After=network.target在网络就绪后再启动否则开机可能先于网络起来，抓取全部失败
User  /  Group以专用账号运行最小权限原则，避免被拿下后拿整机
WorkingDirectory工作目录关键：决定了相对路径（ data/ ）解析到哪里
ExecStart  ...  --config.file启动命令与配置路径用绝对路径，不依赖 PATH
ExecReload=/bin/kill -HUP $MAINPIDsystemctl reload  发 SIGHUP让不重启进程重载配置成为可能
LimitNOFILE=65535打开文件数上限TSDB 会打开大量 chunk 文件，默认 1024 不够。这是性能优化项
Restart=on-failure异常退出自动拉起提高可用性
WantedBy=multi-user.target允许开机自启systemctl enable  才有意义
\n
启用：
\n
systemctl daemon-reload
systemctl enable --now prometheus.service
systemctl is-active prometheus
ss -ntlp | grep 9090
\n
⚠️  LimitNOFILE  到底影响什么？
\n它的效果你能亲眼看到 —— 访问  http://<IP>:9090/metrics ，搜索  process_max_fds ：
\n
process_max_fds 6.5535e+04
改一下 service 文件里的值（比如改成 66666），重启服务后再看，这个指标就跟着变了。"配置文件的每一个数字，都会在某个指标里体现"—— 这是理解监控系统的一个非常好的思维方式。
\n
\n
# 2.3.7　验证：Web UI 的三个菜单
\n
浏览器访问  http://<prometheus-ip>:9090/ ，顶部菜单四项：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
菜单作用你需要知道的
Alerts当前处于活动状态的告警显示由规则计算出的 pending /firing 告警
Graph查询与画图界面默认落地页，PromQL 就在这里写
Status各种运行状态排障时最常用，见下
Help帮助与文档链接很少用
\n
Status 下的子菜单（排障必去）：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
子菜单内容典型用途
Runtime & Build Information版本、启动时间、构建信息、内存等确认版本、确认服务是否刚重启
Command-Line Flags实际生效的启动参数确认 service 文件里写的参数真的生效了
Configuration当前生效的配置（YAML 原文）确认 reload 之后配置真的变了
Rules规则文件的加载与计算情况告警不触发时第一个该看的地方
Targets所有采集目标的健康状态⭐ 抓不到数据时第一个该看的地方
Service Discovery服务发现得到的动态目标列表排查 K8s /file_sd 不生效
\n
\n
⚠️ 两个 "只存在于内存" 的认知：
\n
    \n
  1. Graph 页面里写的表达式，刷新就没了。 这就是为什么必须要有 Grafana—— 它负责把表达式 "存下来" 变成面板。
    2. \n
  2. Targets 页面上的  Last Scrape  时间和  State  颜色，是你判断 "数据到底有没有进来" 最快的方式。绿色 UP = 抓到了；红色 DOWN = 抓不到。
    3. \n
\n
\n
\n
# 2.4　管理 API 与  --web.enable-lifecycle  的安全陷阱
\n
# 2.4.1　四个 API 端点
\n
Prometheus 提供了一组管理 API 用于自动化运维：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
端点方法作用是否需要  --web.enable-lifecycle
/-/healthyGET健康检查，通常恒返回 200❌ 不需要
/-/readyGET就绪检查，能响应查询后返回 200❌ 不需要
/-/reloadPOST / PUT重载配置文件✅ 需要
/-/quitPOST / PUT关闭 Prometheus 进程✅ 需要
\n
# 健康 / 就绪：永远可用
curl http://prom.example.com:9090/-/healthy
# Prometheus Server is Healthy.
curl http://prom.example.com:9090/-/ready
# Prometheus Server is Ready.
# 重载 / 关闭：需要开启 lifecycle
curl -X POST http://prom.example.com:9090/-/reload
curl -X POST http://prom.example.com:9090/-/quit
# Requesting termination... Goodbye!
未开启该选项时：
\n
curl -X POST http://prom.example.com:9090/-/quit
# Lifecycle API is not enabled.
# 2.4.2　⭐ 故障现场二：我在另一台机器上，一行命令关掉了你的监控
\n
开  --web.enable-lifecycle  之后，会发生这样的事：
\n
# 注意：这是在【另一台无关的远程主机】上执行
curl -X POST http://10.0.0.100:9090/-/quit
# 服务直接退出
ss -ntlp | grep 9090        # 端口没了
systemctl is-active prometheus  # inactive
不需要任何认证，不需要登录服务器，只要能访问 9090 端口。 整个监控系统被一行 curl 干掉了。
\n
\n
🚨 结论必须记住：
\n --web.enable-lifecycle  生产环境不要开。
\n
它的收益是什么？—— 能通过 API 触发 reload。
\n但问题是：我们本来就有  systemctl reload prometheus （靠  ExecReload  发 SIGHUP），效果完全一样，还不需要暴露任何危险接口。
\n
我在很多人的 service 文件里见过这一行，他们大多不知道这行意味着 "谁都能远程关掉你的监控"。别做那个人。
\n
\n
# 2.4.3　重载配置的四种方式对比
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
方式命令是否重启进程前提建议
systemd reloadsystemctl reload prometheus❌ 不重启ExecReload  配了  kill -HUP⭐ 生产首选
信号kill -HUP <pid>❌ 不重启无手工排障可用
API reloadcurl -X POST :9090/-/reload❌ 不重启必须开 lifecycle（不建议）不推荐
重启服务systemctl restart prometheus✅ 重启无改了启动参数时才需要
\n
\n
📌 分清两类配置：
\n\n
改了什么，就用对应的方式生效，不要图省事一律 restart。
\n
\n
# 2.4.4　顺带一提：谁来监控 Prometheus 自己
\n
/-/healthy  和  /-/ready  的价值在于：它们让外部系统可以监控 Prometheus 本身。
\n
Prometheus 监控万物  ——  但 Prometheus 挂了，谁来发现？\n
\n
三种常见做法：
\n
    \n
  1. 双机互监控：A 的 Prometheus 抓 B 的指标，B 的抓 A 的，任一方挂了另一方告警；
    2. \n
  2. 外部探活：另一个系统（Zabbix / 云监控 / 负载均衡健康检查）定时 curl  /-/healthy ；
    3. \n
  3.  up  指标自监控：用另一个 Prometheus 实例抓本实例的  /metrics ，看  up{job="prometheus"} 。
    4. \n
\n
\n
💡 回到第 1 章的比喻：警察管普通人，那谁管警察？—— 这既是技术问题，也是一个非常好的面试发散点。
\n
\n
\n
# 2.5　常用启动参数与容量规划
\n
完整参数表：https://prometheus.io/docs/prometheus/latest/command-line/prometheus/
\n
不过真正需要你关心的是下面这几个：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
参数默认值作用调优建议
--config.fileprometheus.yml配置文件路径用绝对路径
--web.listen-address0.0.0.0:9090监听地址对外暴露时建议配合反向代理 + 认证
--web.read-timeout5m请求读超时，关闭空闲连接防止空闲连接堆满
--web.max-connections512最大并发连接数大屏轮询多时适当调大
--storage.tsdb.pathdata/TSDB 数据目录⭐ 独立分区，别和根分区放一起
--storage.tsdb.retention.time15d样本保留时长企业通常 15d；太长吃磁盘和内存，太短查不到历史
--query.timeout2m单次查询最长执行时间复杂 PromQL 多时可调大
--query.max-concurrency20最大并发查询数与 Grafana 面板数量相关
--web.enable-lifecyclefalse允许 API reload/quit🚨 生产保持 false
\n
保留期的取舍（面试常问）：
\n
磁盘占用≈活跃序列数×采样频率×保留时长×单点字节数\\text{磁盘占用} \\approx \\text{活跃序列数} \\times \\text{采样频率} \\times \\text{保留时长} \\times \\text{单点字节数}\n磁盘占用≈活跃序列数×采样频率×保留时长×单点字节数
\n
\n
举例：10 万条活跃序列、每 15 秒采一次、保留 15 天、压缩后按 1.5 字节 / 点估算：
\n100000 \\times \\frac{86400}{15} \\times 15 \\times 1.5 \\approx 1.3\\ \\text
\n
注意：这个公式只用于量级估算。真实占用还要看标签基数、chunk 对齐、索引大小等。但把 "序列数" 和 "采样频率" 作为两个乘法因子放在分子上，这个直觉是对的 —— 序列爆炸和采集频率过高，是磁盘被打满的两大主因。
\n
\n
\n
# 2.6　 prometheus.yml ：逐行读懂配置文件
\n
官方参考：https://prometheus.io/docs/prometheus/latest/configuration/configuration/
\n
# 2.6.1　两类配置的分工
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
配置方式存什么例子
命令行参数不可变的系统级参数数据目录、保留期、监听地址
配置文件（YAML）与 "数据动态获取" 相关的配置抓谁、怎么抓、告警规则、告警发往哪
\n
# 2.6.2　默认配置的四段式结构
\n
global:
  scrape_interval: 15s        # 抓取间隔，默认 1m
  evaluation_interval: 15s    # 规则计算间隔，默认 1m
  # scrape_timeout 默认取 global 默认值 10s，且不应超过 scrape_interval
alerting:
  alertmanagers:
  - static_configs:
    - targets:                # 这里留空，等第 6 章再填
rule_files:                   # 告警规则文件列表，先空着
  # - \"rules/*.yml\"
scrape_configs:               # ★ 最核心：监控谁
  - job_name: \"prometheus\"
    static_configs:
    - targets: [\"localhost:9090\"]
四大段各自的作用：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
段作用本章是否要改
global全局默认值，被各 job 继承可能微调  scrape_interval
alerting告警发给哪个 Alertmanager留空
rule_files外置规则文件（告警规则 / 记录规则）留空
scrape_configs采集目标列表（一组 job）⭐ 本章重点
\n
除此之外，还有扩展配置 8 项（ tls_config 、 relabel_config 、 metric_relabel_configs 、 remote_write 、 remote_read …）和平台集成配置 12 项（ file_sd_config 、 dns_sd_config 、 consul_sd_config 、 kubernetes_sd_config …），后面章节逐个展开。
\n
# 2.6.3　 scrape_configs  的结构
\n
scrape_configs:
  - job_name: \"<job_name>\"
    metrics_path: /metrics      # 默认值，可省略
    scheme: http                # 默认值，可省略
    static_configs:
    - targets: [ \"<host_ip>:<host_port>\", ... ]
      labels: { <labelname>: <labelvalue>, ... }
三个概念对应第 1 章的知识点：
\n\n
\n
💡 给 job 命名的建议：起一个 " 能看出这是什么东西 " 的名字，比如  node_exporter 、 mysql 、 redis 、 nginx 。这个名字会原封不动地出现在  up{job="..."} 、Grafana 的变量下拉框、以及告警模板里。名字起得烂，后面到处难受。
\n
\n
# 2.6.4　⭐ 故障现场三：缩进错了，targets 永远不生效
\n
YAML 是缩进敏感的语言，而  scrape_configs  的结构是 "列表套列表套字典"，嵌套很深。典型错误：
\n
# ❌ 错误：targets 和 static_configs 不对齐
  - job_name: 'node_exporter'
    static_configs:
        - targets: ['10.0.0.101:9100']
或者：
\n
# ❌ 错误：把 targets 写成了 static_configs 的兄弟
  - job_name: 'node_exporter'
    static_configs:
    - targets: ['10.0.0.101:9100']
  - targets: ['10.0.0.102:9100']     # ← 这一行变成了一个新的 job（且没有 job_name）
后果： promtool check config  可能报错；也可能不报错但语义完全变了 ——targets 变成了另一个匿名 job，或者根本没被解析。
\n
\n
⭐ 所以：改完配置，先检查语法，再 reload。
\n
promtool check config /usr/local/prometheus/conf/prometheus.yml
# Checking /usr/local/prometheus/conf/prometheus.yml
#  SUCCESS: ... is valid prometheus config file syntax
故意少写一个冒号试试，它会准确告诉你第几行出错 —— 这个反馈比 "reload 之后没数据，然后你猜了半天" 高效一百倍。
\n
\n
# 2.6.5　 promtool ：被严重低估的运维工具
\n
promtool --help
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
子命令用途
promtool check config <file>⭐ 检查配置语法与语义
promtool check rules <file>检查告警 / 记录规则文件
promtool query instant <url> <expr>命令行直接跑 PromQL，便于脚本化
promtool tsdb ...TSDB 分析（如  analyze  看块与序列统计）
\n
\n
💡 养成习惯：任何配置变更 → 先  check config  → 再 reload → 再去看 Targets 页面。 三步走，能省掉 80% 的 "改完没生效" 的困惑。
\n
\n
\n
# 2.7　方式三：容器化部署
\n
# 2.7.1　官方 Dockerfile 全解读
\n
官方镜像： prom/prometheus （注意是  prom  组织，不是  prometheus ，直接搜全名经常搜不到）
\n
来源：https://github.com/prometheus/prometheus/blob/main/Dockerfile
\n
ARG ARCH=\"amd64\"
ARG OS=\"linux\"
FROM quay.io/prometheus/busybox-${OS}-${ARCH}:latest
COPY .build/${OS}-${ARCH}/prometheus /bin/prometheus
COPY .build/${OS}-${ARCH}/promtool   /bin/promtool
COPY documentation/examples/prometheus.yml /etc/prometheus/prometheus.yml
WORKDIR /prometheus
RUN chown -R nobody:nobody /etc/prometheus /prometheus && chmod g+w /prometheus
USER nobody
EXPOSE 9090
VOLUME [ \"/prometheus\" ]
ENTRYPOINT [ \"/bin/prometheus\" ]
CMD [ \"--config.file=/etc/prometheus/prometheus.yml\", \"--storage.tsdb.path=/prometheus\" ]
看懂了这 10 行，你就看懂了所有 Go 程序的官方镜像：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
行含义对我们的启示
FROM busybox基础镜像只是提供 shell 和根证书镜像可以做到很小（甚至  scratch ）
COPY prometheus /bin/就是把我们手动装的那个二进制拷进去二进制会了，镜像就是 "打包"
配置文件在  /etc/prometheus/默认配置路径修改配置 = 覆盖这个文件
USER nobody以 nobody 运行非 root，安全
VOLUME ["/prometheus"]数据目录不挂载就随容器删掉而丢失
CMD [...]默认启动参数传入自己的参数会完全覆盖 CMD
\n
\n
💡 这就是为什么 "二进制学扎实" 如此重要：容器里跑的就是那个二进制，参数一模一样，只是配置文件位置和数据目录换成了镜像里约定的路径。没有任何魔法。
\n
\n
# 2.7.2　三种启动姿势
\n
# ① 最简：默认配置 + 默认数据目录（不持久化）
docker run -d --name prometheus -p 9090:9090 prom/prometheus
# ② 生产可用：挂载配置 + 数据卷
docker run -d --name prometheus -p 9090:9090 \\
  -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml \\
  -v prometheus_data:/prometheus \\
  prom/prometheus:v2.53.0
# ③ 自定义配置路径（不覆盖镜像内文件，而是改变启动参数）
docker run -d --name prometheus -p 9090:9090 \\
  -v $PWD/prometheus.yml:/prometheus-config/prometheus.yml \\
  prom/prometheus \\
  --config.file=/prometheus-config/prometheus.yml
\n
⚠️ 注意第 ③ 种：一旦你在镜像名后面跟了参数，镜像里的  CMD  会被整体替换。所以必须把  --storage.tsdb.path  之类的必要参数一起写全，否则会回落到默认值（ data/ ，相对于容器内工作目录）。
\n
\n
# 2.7.3　⭐ 故障现场四：容器里的配置文件改不动
\n
用  docker run  起完之后，你会发现一个尴尬事：
\n
\n
配置文件在镜像里。想改？得  docker exec  进去用  vi  改 —— 而大多数精简镜像里根本没有  vi 。
\n
\n
正确做法（三步）：
\n
# 1. 把镜像内的默认配置拷出来
docker cp prometheus:/etc/prometheus/prometheus.yml ./prometheus.yml
# 2. 在宿主机上修改它（想改采集间隔就改）
vi ./prometheus.yml
# 3. 删掉旧容器，用 -v 挂载覆盖镜像内的配置
docker rm -f prometheus
docker run -d --name prometheus -p 9090:9090 \\
  -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml \\
  -v prometheus_data:/prometheus \\
  prom/prometheus
验证是否生效：访问 9090 → Status → Configuration，看里面的  scrape_interval  是不是你改的值。
\n
\n
📌 容器化不是 "更好的方式"，而是 "另一种打包方式"。
\n它把 "改配置文件" 这件简单的事，变成了 "覆盖镜像内文件" 这件事。
\n所以：实验环境用容器图快，生产环境很多人仍然用二进制 + systemd—— 改配置、看日志、排障都更直接。两种方式都要会，别只会一种。
\n
\n
# 2.7.4　Docker Compose：一键起整套监控栈
\n
中小规模环境可以直接用 Compose 拉起完整栈：
\n
version: '3.6'
volumes:
  prometheus_data: {}
  grafana_data: {}
networks:
  monitoring:
    driver: bridge
services:
  prometheus:
    image: prom/prometheus:v2.53.0
    volumes:
      - ./prometheus/:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=15d'
    ports:
      - \"9090:9090\"
    networks: [monitoring]
    restart: unless-stopped
  alertmanager:
    image: prom/alertmanager:v0.27.0
    command:
      - '--config.file=/etc/alertmanager/config.yml'
      - '--storage.path=/alertmanager'
    ports:
      - \"9093:9093\"
    networks: [monitoring]
    restart: unless-stopped
  node-exporter:
    image: prom/node-exporter:v1.8.2
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--path.rootfs=/rootfs'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    ports:
      - \"9100:9100\"
    networks: [monitoring]
    restart: unless-stopped
  pushgateway:
    image: prom/pushgateway:v1.10.0
    ports:
      - \"9091:9091\"
    networks: [monitoring]
    restart: unless-stopped
  grafana:
    image: grafana/grafana:11.2.0
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
      - GF_USERS_ALLOW_SIGN_UP=false
    ports:
      - \"3000:3000\"
    networks: [monitoring]
    restart: unless-stopped
有两点必须提醒：
\n
    \n
  1.  node-exporter  的三个挂载不是可选项 —— 它要读宿主机的  /proc 、 /sys  和根文件系统，否则采集到的是容器自己的（几乎为空的）指标。下一节会详细解释。
    2. \n
  2. 容器内的  prometheus  抓容器内的  node-exporter  时，target 要写  node-exporter:9100 （服务名），而不是  localhost:9100 。这是 Compose 网络里的 DNS 解析规则，也是新手最常见的 "抓不到" 原因之一。
    3. \n
\n
\n
# 2.8　Node Exporter：把主机指标 "出口" 出去
\n
# 2.8.1　为什么必须有它
\n
回到第 1 章的结论：Prometheus 的所有指标都必须以 HTTP 形式暴露。
\n
而 Linux 操作系统本身不提供 HTTP 指标端点。你不可能让内核主动开个端口给你读  /proc/stat 。
\n
所以中间必须有个 "转换器"：
\n
flowchart LR
    K[\"Linux 内核<br/>/proc /sys\"] -->|读取| NE[\"Node Exporter<br/>:9100\"]
    NE -->|\"HTTP GET /metrics<br/>纯文本格式\"| P[\"Prometheus Server\"]
Node Exporter 干的事：
\n
    \n
  1. 读取本机的  /proc 、 /sys 、系统调用，拿到 CPU、内存、磁盘、网络、文件系统等原始数据；
    2. \n
  2. 转换成 Prometheus 文本格式（ # HELP  /  # TYPE  /  指标 值 ）；
    3. \n
  3. 在本机 9100 端口起一个 HTTP 服务，把结果暴露在  /metrics 。
    4. \n
\n
\n
🧠 名字的由来：它把本节点的指标 " 出口（export）"出去，让 Prometheus 来" 进货 "。你不" 出口 "，人家就采不到 —— 这个命名非常形象。
\n
和 Zabbix 的对照：
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ZabbixPrometheus
采集代理zabbix-agentnode_exporter
通信协议Zabbix 专有协议HTTP/HTTPS
数据方向Server 拉（被动）或 Agent 推（主动）只有 Server 拉
谁的客户端 / 服务端Server 是服务端，Agent 是客户端⭐ 反过来了：Prometheus 是 HTTP 客户端，Node Exporter 是 HTTP 服务端
\n
最后一行请特别注意：角色是反的。Prometheus 主动发起 HTTP 请求（像浏览器），Node Exporter 被动响应（像 Web 服务器）。
\n
# 2.8.2　安装（与 Prometheus 二进制安装几乎同构）
\n
官方下载：https://prometheus.io/download/
\nGitHub：https://github.com/prometheus/node_exporter
\n
在每一台需要监控的节点上执行：
\n
cd /usr/local
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xf node_exporter-1.8.2.linux-amd64.tar.gz
ln -s node_exporter-1.8.2.linux-amd64 node_exporter
cd node_exporter
mkdir bin
mv node_exporter bin/
useradd -r -s /sbin/nologin prometheus
chown -R prometheus:prometheus /usr/local/node_exporter/
\n
💡 看出来了吗？解压 → 软链 → 分目录 → 建账号 → 改属主，和装 Prometheus 的步骤一模一样。这就是 Go 生态的统一 "手感"。学会一个，就会一串。
\n
\n
# 2.8.3　service 文件（含两个坑）
\n
[Unit]
Description=Prometheus Node Exporter
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/node_exporter/bin/node_exporter --collector.cgroups
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
User=prometheus
Group=prometheus
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now node_exporter.service
systemctl is-active node_exporter
ss -ntlp | grep 9100
两个参数坑，来自实战：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
参数作用坑
--collector.cgroups额外启用 cgroups 采集器想采容器资源占用时需要
--no-collector.uname禁用 uname 采集器❌ 千万别加！ 禁用后 Grafana 里的 Dashboard 拿不到主机名和内核版本，面板上会显示  N/A
\n
\n
⚠️ 第二个坑非常隐蔽：有人为了 "减少指标数量" 加了  --no-collector.uname ，结果所有社区 Dashboard 的主机信息栏全是空的，还以为是模板不兼容。优化指标量请用 relabel 丢弃，不要随手关采集器。
\n
\n
# 2.8.4　验证暴露结果
\n
curl http://localhost:9100/metrics | head -40
浏览器访问  http://<node-ip>:9100/ ，会看到一个只有一个  metrics  链接的极简页面 —— 点进去就是全部指标。
\n
\n
💡 这个页面本身就是最好的学习材料。随便挑几个指标，对照  # HELP  的说明，你就能明白它代表什么。比看文档快得多。
\n
\n
# 2.8.5　常见指标速查（背诵级）
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
前缀 / 指标含义
node_cpu_seconds_total各 CPU、各模式（user/system/idle/iowait/softirq…）的累计秒数（Counter）
node_memory_*内存： MemTotal 、 MemFree 、 MemAvailable 、 Buffers 、 Cached 、 Swap*
node_filesystem_*文件系统的容量与可用空间（按挂载点、设备、fstype 分标签）
node_disk_*磁盘 IO：读写字节、IOPS、耗时、队列长度
node_network_*网卡收发字节、包数、错误数、丢包（按  device  分标签）
node_load1  /  5  /  151/5/15 分钟平均负载（Gauge）
node_boot_time_seconds系统启动时间（1970 起的秒数）
node_time_seconds当前系统时间
go_*Exporter 自身的 Go 运行时指标（GC、goroutine、堆）
process_*Exporter 自身进程指标（ process_max_fds  就属于这类）
node_uname_info主机名、内核版本、架构等信息
\n
\n
🔗 回忆第 1 章： top  里的 user /system/nice /idle/iowait /irq/softirq /steal，在  node_cpu_seconds_total  里就是  mode="user"|"system"|"nice"|"idle"|"iowait"|"irq"|"softirq"|"steal"  这几个标签值。命令行的每一列，在 Prometheus 里都是一个标签维度。
\n
\n
# 2.8.6　为什么容器里的 Node Exporter 必须 "三件套"
\n
这是本章最值得深入理解的一处。官方推荐命令：
\n
docker run -d \\
  --net=\"host\" \\
  --pid=\"host\" \\
  -v \"/:/host:ro,rslave\" \\
  quay.io/prometheus/node-exporter:latest \\
  --path.rootfs=/host
三个参数，各有其不可替代的原因：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
参数作用不加会怎样
--net="host"与宿主机共享网络命名空间采集到的网卡（ node_network_* ）是容器虚拟网卡的，看不到 eth0 /bond/ 物理网卡
--pid="host"与宿主机共享 PID 命名空间进程类指标（进程数、 node_processes_* ）只看到容器内的 1 号进程
-v "/:/host:ro,rslave"把宿主机根挂进来 +  --path.rootfs=/host文件系统指标全是容器 overlay 的，磁盘使用率完全失真； /proc 、 /sys  读到的也是容器自己的
\n
\n
⭐ 一句话记忆：
\nNode Exporter 不是来监控 "自己" 的，是来监控 "宿主机" 的 —— 所以它必须能看见宿主机。
\n同理，K8s 里部署 node-exporter 一定要用 DaemonSet +  hostNetwork: true  +  hostPID: true  +  hostPath  挂载  /proc   /sys   / 。
\n
\n
# 2.8.7　批量部署：脚本 → Ansible → DaemonSet
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
规模方案说明
1～5 台手工 / Shell 脚本课程提供的  install_node_exporter.sh  支持在线与离线安装
10～100 台Ansible官方 Role：https://github.com/prometheus-community/ansible/tree/main/roles/node_exporter，改改变量即可
K8s 集群DaemonSet保证每个节点恰好一个 Pod
\n
Shell 脚本的核心结构（值得学习它的工程化写法）：
\n
NODE_EXPORTER_VERSION=1.8.2
NODE_EXPORTER_FILE=\"node_exporter-${NODE_EXPORTER_VERSION}.linux-amd64.tar.gz\"
GITHUB_PROXY=https://mirror.ghproxy.com/     # 加速代理，会失效，注意维护
install_node_exporter() {
    [ -f \"${NODE_EXPORTER_FILE}\" ] || wget \"${GITHUB_PROXY}${NODE_EXPORTER_URL}\" || { color \"下载失败!\" 1; exit; }
    tar xf \"${NODE_EXPORTER_FILE}\" -C \"${INSTALL_DIR}\"
    ln -s node_exporter-${NODE_EXPORTER_VERSION}.linux-amd64 node_exporter
    mkdir -p node_exporter/bin && mv node_exporter bin/
    id prometheus &>/dev/null || useradd -r -s /sbin/nologin prometheus
    chown -R prometheus:prometheus node_exporter/
}
node_exporter_service() { ...  写 service 文件、daemon-reload、enable --now ... }
\n
💡 脚本里的三个好习惯：
\n
    \n
  1. 版本号抽成变量 —— 升级只改一行；
    2. \n
  2. 先判断本地包是否存在 —— 存在就不下载，天然支持离线安装；
    3. \n
  3. 幂等 —— id prometheus &>/dev/null || useradd ，重复执行不报错。
    4. \n
\n
\n
Ansible（官方已现成）：
\n
- hosts: all
  become: true
  roles:
    - prometheus.prometheus.node_exporter
K8s DaemonSet（关键字段）：
\n
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prometheus-node-exporter
  namespace: prom
spec:
  selector:
    matchLabels: { app: prometheus, component: node-exporter }
  template:
    metadata:
      labels: { app: prometheus, component: node-exporter }
    spec:
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master      # 主节点也要装，需要容忍污点
      containers:
      - image: prom/node-exporter:v1.8.2
        name: prometheus-node-exporter
        args:
        - --path.procfs=/host/proc
        - --path.sysfs=/host/sys
        - --path.rootfs=/host
        ports:
        - containerPort: 9100
          hostPort: 9100
        volumeMounts:
        - { name: proc,   mountPath: /host/proc }
        - { name: sys,    mountPath: /host/sys  }
        - { name: rootfs, mountPath: /host      }
      hostNetwork: true     # ⭐ 与宿主机共享网络
      hostPID: true         # ⭐ 与宿主机共享 PID
      volumes:
      - { name: proc,   hostPath: { path: /proc } }
      - { name: sys,    hostPath: { path: /sys  } }
      - { name: rootfs, hostPath: { path: /     } }
\n
📌  DaemonSet  = "每个节点跑一个"。这正是 Node Exporter 需要的语义 —— 它不是 "一个服务"，而是 "每台机器上的一个探针"。
\n
\n
\n
# 2.9　让 Prometheus 采集 Node Exporter
\n
到这里，Node Exporter 已经在 9100 上 "出口" 了指标，但 Prometheus 还不知道它的存在 —— 所以你在 Prometheus 里搜  node_memory_*  会一无所获。
\n
这是新手最常见的困惑："我明明在浏览器里能看到指标，为什么 Prometheus 里查不到？"
\n
\n
记住这句话："暴露" 是 Node Exporter 的事，"采集" 是 Prometheus 的事。两件事必须都做。
\n
\n
# 2.9.1　修改配置
\n
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
scrape_configs:
  - job_name: \"prometheus\"
    static_configs:
    - targets: [\"localhost:9090\"]
  # ★ 新增：采集 Node Exporter
  - job_name: 'node_exporter'
    metrics_path: /metrics        # 默认值，可省略
    scheme: http                  # 默认值，可省略
    static_configs:
    - targets:
      - '10.0.0.101:9100'
      - '10.0.0.102:9100'
      - '10.0.0.103:9100'
      - '10.0.0.100:9100'         # 别忘了 Prometheus 自己这台
      labels:
        env: prod
        region: bj
targets 的两种写法（都合法，选顺眼的）：
\n
# 写法 A：写在一行（机器少时更紧凑）
    - targets: ['10.0.0.101:9100','10.0.0.102:9100']
# 写法 B：一行一个（机器多时更清晰，推荐）
    - targets:
      - '10.0.0.101:9100'
      - '10.0.0.102:9100'
\n
⚠️ 无论哪种写法， targets  都是列表，列表项以  -  开头。这是 YAML 缩进错误最高发的位置。
\n
\n
# 2.9.2　检查 → 生效 → 验证
\n
# 1. 语法检查
promtool check config /usr/local/prometheus/conf/prometheus.yml
# 2. 热加载（不重启）
systemctl reload prometheus
# 3. 验证：三种方式
curl -s http://localhost:9090/-/ready
# 浏览器 → Status → Targets：应看到 node_exporter 这个 job，状态 UP
# 4. 用 PromQL 确认
up{job=\"node_exporter\"}
up  指标的返回值：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
值含义
1上一次抓取成功
0上一次抓取失败（连不上、超时、非 2xx）
\n
四个 target 全部  1 ，说明采集链路通了。此时再查  node_memory_MemTotal_bytes ，四台机器的数据就都出来了。
\n
# 2.9.3　⭐ 故障现场五：端口写错，一个字符排查半小时
\n
真实过程，值得完整复盘：
\n
    \n
  1. 配好了 job， reload  之后浏览器刷新 Graph 页面，搜  memory  —— 什么都没有。
    2. \n
  2. 第一反应："是不是要等一会？"—— 对，采集是周期性的。当前  scrape_interval  是 20s，那就等 20s 再看。
    3. \n
  3. 等了 20s，还是没数据。
    4. \n
  4. 第二反应："是不是配置没生效？"—— 去 Status → Configuration 确认新 job 在不在。在。
    5. \n
  5. 第三反应："那到底抓没抓到？"—— 去 Status → Targets，看到  node_exporter  这个 job 是红色 DOWN，报错类似：
    6. \n
\n
Get \"http://10.0.0.101:9010/metrics\": dial tcp 10.0.0.101:9010: connect: connection refused
    \n
  1. 一眼看出问题： 9010 ，不是  9100 。打错了一个数字。
    2. \n
\n
改完 reload，颜色变绿，数据立刻就有了。
\n
\n
⭐ 这就是 "看 Targets 页面" 的价值：它把 "为什么没数据" 这个问题，直接翻译成了一个具体的 URL 和一个具体的错误。
\n不要一上来就怀疑 Prometheus 有 bug、怀疑版本不兼容、怀疑网络 —— 先看 Targets。
\n
\n
# 2.9.4　"抓不到数据" 五步排查法
\n
把上面的经验固化成流程，以后照着走：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
步骤动作判断依据结论
① 目标端自测在目标机上  curl -s localhost:9100/metrics \\| head有输出？无 → exporter 没起 / 端口不对
② 跨机自测在 Prometheus 机上  curl -s <target>:9100/metrics通了？不通 → 防火墙 / 监听地址是 127.0.0.1 / 网络不通
③ 看 TargetsWeb UI → Status → TargetsUP / DOWN + 错误信息DOWN → 错误信息直接指出原因
④ 看配置Status → Configuration新 job 在不在、targets 对不对不在 → reload 没成功 / 配置语法被拒
⑤ 看日志journalctl -u prometheus -n 50有无  Error reloading config有 → 配置有问题
\n
四个高频根因（按出现频率排序）：
\n
    \n
  1. 端口写错（ 9100  →  9010  /  9091  /  910 ）；
    2. \n
  2. 服务监听在  127.0.0.1  而不是  0.0.0.0 —— 本机 curl 通、跨机不通，这是最迷惑人的一种；
    3. \n
  3. 防火墙 / 安全组没放行（ firewalld 、 ufw 、云安全组）；
    4. \n
  4. 改完没 reload /reload 失败但没人看日志。
    5. \n
\n
\n
💡 还有一个 "假故障"：指标有延迟。刚配好就查，必然查不到 —— 必须等至少一个  scrape_interval 。学习时把间隔调成  10s ，能少等很多；但生产不要低于 10s，否则序列数与磁盘写入会成倍增长。
\n
\n
\n
# 2.10　Grafana：让数据变成图
\n
# 2.10.1　它是什么
\n
Grafana 是一个开源的度量分析与可视化套件，同样用 Go 开发。
\n
核心能力：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
能力说明
多数据源Prometheus、Zabbix、Graphite、InfluxDB、Elasticsearch、MySQL… 一个界面对接所有
统一查询编辑器每种数据源有自己的查询语言，Grafana 统一包装并保留各自特性
同屏混合展示同一个 Dashboard 上可以混用多个数据源
海量现成模板https://grafana.com/grafana/dashboards/ 上有几万个社区面板
告警内置 Grafana Alerting（本章不展开）
默认端口3000
自带  /metrics 能暴露自身运行指标给 Prometheus 采集
\n
\n
💡 和 Zabbix 的关键差异：Zabbix 内置的数据源能力有限（要装插件才支持某些源），而 Grafana 天生一等公民支持 Prometheus—— 数据源列表里 Prometheus 排第一。这也是 "Prometheus + Grafana" 成为事实标准组合的原因。
\n
\n
# 2.10.2　安装（deb 包）
\n
官方下载：https://grafana.com/grafana/download
\n
# 官方源（慢）
wget https://dl.grafana.com/enterprise/release/grafana-enterprise_11.2.0_amd64.deb
# 或清华镜像（快）
wget https://mirrors.tuna.tsinghua.edu.cn/grafana/apt/pool/main/g/grafana-enterprise/grafana-enterprise_11.2.0_amd64.deb
三种安装方式，强烈推荐第 2 种：
\n
# ① dpkg 装：依赖需要手工解决
dpkg -i grafana-enterprise_11.2.0_amd64.deb
apt -y --fix-broken install          # 缺依赖时补救
# ② apt 装本地 deb 文件：依赖自动解决  ⭐ 推荐
apt -y install ./grafana-enterprise_11.2.0_amd64.deb
# ③ 先装依赖再 dpkg（等价于 ①，但更可控）
apt-get install -y adduser libfontconfig1 musl
dpkg -i grafana-enterprise_11.2.0_amd64.deb
\n
📌 为什么  apt install ./xxx.deb  比  dpkg -i  好？
\n dpkg  只管解包，不解决依赖； apt  会自动把缺的包（如  musl 、 libfontconfig1 ）一并装上。"先装依赖还是先装包" 这种顺序问题，用 apt 直接消失。
\n
\n
启动与验证：
\n
systemctl daemon-reload
systemctl enable --now grafana-server.service
systemctl status grafana-server
ss -ntulp | grep 3000
\n
💡 关于 "企业版"： grafana-enterprise  并不是收费版，核心功能完全免费开源（Apache 2.0 部分 + AGPLv3 部分）。企业版只是额外包含了一些企业级特性（如 SSO、报表）。个人和中小团队放心用。
\n
\n
# 2.10.3　首次登录与添加数据源
\n
浏览器访问：http://<grafana-ip>:3000/\n默认账号密码：admin / admin\n
\n
首次登录会要求改密码（可以跳过，生产环境请务必改）。
\n
添加数据源（这是 Grafana 的 "第一课"，Zabbix 课程里也练过）：
\n
    \n
  1. 左侧菜单 → Connections → Data sources（或首页 "Add your first data source"）；
    2. \n
  2. 选择 Prometheus（列表里排第一）；
    3. \n
  3. Connection URL 填  http://<prometheus-ip>:9090\n\n
    4. \n
  4. 认证：Prometheus 默认无认证，留空；
    5. \n
  5. 拉到最下面点 Save & Test，看到绿色提示 "Data source is working" 即成功。
    6. \n
\n
\n
⚠️ Grafana 服务端为你 "代发请求"：Grafana 后端会去访问那个 URL。所以填  localhost:9090  只在 Grafana 和 Prometheus 同机时才有效。分机部署时必须填 Prometheus 的真实 IP。
\n
\n
# 2.10.4　⭐ 认知难点：内置 Dashboard 为什么 "部分没数据"
\n
添加完 Prometheus 数据源后，Grafana 会自动提示导入三个内置面板：
\n\n
导入后你会发现：有的能显示，有的全是  No data 。
\n
原因有两个，性质完全不同：
\n
原因一：指标名变了（版本兼容问题）
\n
内置模板是几年前写的，里面用的 PromQL 表达式引用的指标，在新版本 Prometheus 里可能已经改名或移除。
\n
验证方法（非常值得掌握）：
\n
    \n
  1. 打开出问题面板 → 点 Edit（或 "Panel options"）；
    2. \n
  2. 看下面的 Query 里的表达式，例如  prometheus_tsdb_... ；
    3. \n
  3. 把这段表达式复制出来，粘到 Prometheus 的 Graph 页面执行；
    4. \n
  4. 如果 Prometheus 里也查不到 → 不是 Grafana 的问题，是这个指标在当前版本里不存在；
    5. \n
  5. 反过来，在 Graph 页输入  prometheus_  前缀，看下拉提示里有哪些指标 —— 就能找到 "改名后的那个"。
    6. \n
\n
\n
💡 这个排查手法适用于所有 "面板没数据" 的场景：永远先在 Prometheus 里验证表达式，再去怀疑 Grafana。
\n
\n
原因二：数据源根本没被采集（逻辑问题）
\n
Grafana metrics  这个面板展示的是 Grafana 自身的指标。但你现在还没有让 Prometheus 去采集 Grafana—— 所以 Prometheus 里压根没有这些数据。详见 2.11 节，那里会完整解释这条 "绕一圈" 的链路。
\n
# 2.10.5　导入社区 Dashboard 展示 Node Exporter 数据
\n
内置模板不适合看主机指标，得用社区模板。
\n
第 1 步：找模板
\n
访问 https://grafana.com/grafana/dashboards/，搜索  node exporter 。
\n
第 2 步：筛选（关键）
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
筛选条件为什么
Data source = Prometheus数据源必须匹配
按下载量 / 评分排序经过大量用户验证，踩坑少
看更新时间⭐ 太老的模板别用 —— 指标名可能已经变了，会重演 2.10.4 的 "没数据"
看是否中文英文面板不是不能用，但中文面板日常更顺手
\n
几个常用 ID（注意：ID 会随社区更新变化，请以官网当前状态为准）：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ID说明
1860Node Exporter Full，英文 / 日文，更新较新，指标最全
8919Node Exporter 中文版，日常查看更友好
16098Node Exporter 中文版（另一套风格）
10465Zookeeper 监控（2.12 节会用到）
\n
第 3 步：导入
\n
Grafana → Dashboards → New → Import\n→ 输入 Dashboard ID（如 1860）→ Load\n→ 选择数据源 Prometheus → Import\n
\n
\n
💡 两个实用技巧：
\n
    \n
  1. 导入失败（网络拿不到 JSON）时，可以在官网页面直接下载 JSON 文件，再走 "Upload JSON file" 离线导入；
    2. \n
  2. 给面板改名时带上 ID，例如  Node Exporter Full (1860) —— 半年后你还能知道它是从哪来的。
    3. \n
\n
\n
第 4 步：看不到数据的四个检查点
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
检查点现象处理
节点上没装 Node Exporter面板全空装
Prometheus 没采集该节点部分主机空加 target + reload
浏览器时间与服务器时间差 > 3 秒数据 "看起来是空的"⭐ 校时（NTP）
选了错误的数据源 / Cluster 变量全空或只有部分检查 Dashboard 顶部的变量下拉框
\n
\n
⚠️ 时间误差 > 3 秒会导致查不到数据，这一条很多人不知道，遇到 "明明有数据但图是空的" 时，先  date  对比一下。
\n
\n
# 2.10.6　时间显示：UTC 还是本地时间
\n
Prometheus 内部统一使用 UTC 时间戳。Grafana 面板默认可能按 UTC 显示，导致 "我明明下午 4 点起的服务，图上显示 8 点"。
\n
解决：Dashboard 右上角时间选择器 → 切到 Browser Time / Local。
\n
\n
💡 这不是 bug，是时区约定。记住：Prometheus 存 UTC，展示时再转本地时区。 排查告警时间对不上时，先确认时区。
\n
\n
\n
# 2.11　递归之美：监控 Grafana 自己
\n
# 2.11.1　那条 "绕一圈" 的链路
\n
这是本章最反直觉、也最值得理解的一个知识点。
\n
问题：我想在 Grafana 上看到 Grafana 自己的指标，怎么办？
\n
直觉答案：Grafana 自己展示自己就行了嘛。
\n
正确答案：不行。必须绕一圈。
\n
flowchart LR
    G1[\"Grafana<br/>:3000/metrics<br/>（自带暴露能力）\"]
    P[\"Prometheus Server<br/>:9090\"]
    G2[\"Grafana<br/>Dashboard<br/>（数据源指向 Prometheus）\"]
    G1 -->|\"① Prometheus Pull 采集\"| P
    P -->|\"② Grafana 用 PromQL 查询\"| G2
    G2 -.->|\"③ 画出来的就是 Grafana 自己的指标\"| G1
为什么必须这样？
\n
\n
Grafana 是 "展示层"，不是 "数据源"。它只能从数据源读数据，而它自己不是数据源。
\n
\n
即使要展示 Grafana 自己的指标，也必须：
\n
    \n
  1. Grafana 把自身指标暴露在  :3000/metrics ；
    2. \n
  2. Prometheus 去采集它（在  prometheus.yml  里加一个 job）；
    3. \n
  3. Grafana 通过 Prometheus 数据源把这些指标查出来画图。
    4. \n
\n
同理可推：Prometheus 自己的指标也是这么来的 ——Prometheus 默认就采集自己（ localhost:9090 ），所以  Prometheus Stats  面板有数据；而  Grafana metrics  面板没数据，因为没人去采集 Grafana。
\n
# 2.11.2　配置
\n
先验证 Grafana 确实暴露了指标：
\n
curl -s http://localhost:3000/metrics | head -20
# HELP go_gc_duration_seconds ...
# HELP grafana_api_response_status_total ...
然后在  prometheus.yml  里加一个 job：
\n
- job_name: 'grafana'
    static_configs:
    - targets: ['10.0.0.100:3000']
promtool check config /usr/local/prometheus/conf/prometheus.yml
systemctl reload prometheus
验证：
\n
up{job=\"grafana\"}          # 应为 1
grafana_http_request_duration_seconds_count   # 应该有数据了
回到 Grafana，刷新  Grafana metrics  面板 —— 数据出来了。
\n
# 2.11.3　由此总结出的一条重要分类
\n
现在我们可以把 "指标从哪来" 分成三类，这是理解 Exporter 生态的钥匙：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
类型特征例子需要额外装 Exporter 吗
① 天生自带软件内部主动暴露  /metricsPrometheus 自己、Grafana、Zookeeper、Nacos、Etcd、Traefik❌ 不需要
② 需要 Exporter软件本身没有 HTTP 指标端点（尤其老软件）Linux 系统（→ node_exporter）、MySQL（→ mysqld_exporter）、Redis（→ redis_exporter）、Nginx、HAProxy✅ 需要
③ 只能推生命周期太短或无法被访问一次性脚本、定时任务、批处理作业✅ 用 Pushgateway
\n
\n
🧠 一句话决策法：
\n先  curl http://<软件>:<端口>/metrics  试试。
\n有 → 直接加 job 采；没有 → 找对应 Exporter；连 "常驻" 都做不到 → 上 Pushgateway。
\n
\n
\n
# 2.12　Pushgateway：给 "抓不到" 的指标开一扇门
\n
# 2.12.1　为什么会有这个组件
\n
考虑一个真实需求：统计当前有多少用户登录在这台机器上。
\n
who | wc -l
# 1
就一个数字。但问题是：
\n\n
Prometheus 抓不到它。 这就是 Pushgateway 存在的理由。
\n
# 2.12.2　工作原理：一个 "代收点"
\n
sequenceDiagram
    participant J as 脚本或定时任务
    participant PG as Pushgateway-9091
    participant P as Prometheus-9090
    J->>PG: ① HTTP POST 推送指标（主动推）
    Note over PG: ② 暂存指标（不会自动过期！）
    P->>PG: ③ GET /metrics（Pull 拉取）
    PG-->>P: 返回暂存的指标
它就是一个 "代理 / 中转站"：
\n
\n
你没有 HTTP 服务？我替你有。
\n你把数据交给我（POST /metrics），我挂在  /metrics  上等 Prometheus 来拉。
\n
\n
关键结论：Pushgateway 并没有改变 Prometheus"只拉不推" 的本质 —— 它只是给 "无法被拉" 的目标，额外增加了一个 "可以被拉" 的中转点。数据链路的最后一跳，仍然是 Pull。
\n
# 2.12.3　与 Exporter、与 Zabbix Proxy 的对照
\n
这是最容易混淆的一组概念，用表格彻底分清：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
维度ExporterPushgatewayZabbix Proxy
采集方向被动（等 Prometheus 来拉）主动接收（应用推过来）主动采集后上报
装在哪儿⭐ 每个被监控节点都要装一个⭐ 只装一个（任何位置都行，不必在被监控端）每个区域 / 网段一个
是否需要专属⭐ 每种应用一个专用 Exporter（MySQL、Redis 各有各的）一个就够，所有应用都能往它推一个通用的即可
类比 zabbix-agent  zabbix-proxy zabbix-proxy
\n
\n
🧠 记忆锚点：
\n\n
\n
# 2.12.4　必须知道的四个固有缺陷
\n
Pushgateway 官方文档明确定义了这些局限，面试常问，生产必知：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
缺陷具体表现后果
① 单点瓶颈只有一份 Pushgateway，多个应用同时推送进程挂了 → 全链路数据中断
②  up  指标失效Prometheus 只能看到 Pushgateway 是否活着，看不到真实应用是否活着⭐ 服务挂了，旧数据还在，图表上一片 "正常"—— 假存活！
③ 永不清理推上去的数据永久保留并持续暴露，除非手动 DELETE已下线任务的指标一直 "诈尸"
④ 不做校验脚本算错了、推了脏数据，它照单全收错误数据进入 TSDB，无法追溯
\n
\n
🚨 ② 号缺陷最危险。举个真实场景：你的备份任务每天推一次 "备份成功 = 1"。某天任务彻底挂了，不再推送 —— 但 Pushgateway 上那条  backup_success 1  还在，Prometheus 一直抓到  1 ，你的大屏一直显示 "备份正常"。你会在真正需要备份的那天发现它已经坏了三个月。
\n
应对：在应用侧实现 "心跳 / 时间戳" 指标，用  time() - backup_last_success_timestamp > 86400  这类表达式告警。不要指望  up 。
\n
\n
# 2.12.5　安装
\n
官方下载：https://prometheus.io/download/ 或 https://github.com/prometheus/pushgateway/releases
\n
cd /usr/local
wget https://github.com/prometheus/pushgateway/releases/download/v1.10.0/pushgateway-1.10.0.linux-amd64.tar.gz
tar xf pushgateway-1.10.0.linux-amd64.tar.gz -C /usr/local/
ln -s pushgateway-1.10.0.linux-amd64 pushgateway
mkdir -p /usr/local/pushgateway/bin
mv /usr/local/pushgateway/pushgateway /usr/local/pushgateway/bin/
useradd -r -s /sbin/nologin prometheus
chown -R prometheus:prometheus /usr/local/pushgateway/
service 文件：
\n
[Unit]
Description=Prometheus Pushgateway
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/pushgateway/bin/pushgateway
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
User=prometheus
Group=prometheus
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now pushgateway.service
ss -ntlp | grep 9091
浏览器访问  http://<ip>:9091/  —— 界面是空的，因为还没人往里推过东西。这正是它的本质：数据不来自它自己，来自 "推给它的应用"。
\n
\n
💡 但它自己也需要被监控 —— http://<ip>:9091/metrics  里能看到它自身的指标（请求数、推送成功数等）。所以按 2.11 节的分类，它属于 "① 天生自带 "，直接加 job 采就行。
\n
\n
# 2.12.6　让 Prometheus 采集 Pushgateway
\n
- job_name: \"pushgateway\"
    honor_labels: true          # ⭐ 关键
    scrape_interval: 10s
    static_configs:
    - targets: [\"10.0.0.100:9091\"]
 honor_labels: true  到底解决什么问题？
\n
不加它时，Prometheus 会把自己配置里的  job="pushgateway"  和  instance="10.0.0.100:9091"  强加到所有指标上 —— 于是所有应用推上来的指标看起来都来自同一台机器，标签全被覆盖了。
\n
加上它之后，Pushgateway 上的  job  /  instance  标签优先保留，Prometheus 自己的标签会被改名为  exported_job  /  exported_instance 。这样你才能区分 "这条指标是哪个应用推的"。
\n
\n
⚠️ 所以：采集 Pushgateway， honor_labels: true  几乎是必选项。
\n
\n
也支持文件形式自动发现：
\n
- job_name: pushgateway
    honor_labels: true
    file_sd_configs:
    - files:
      - targets/pushgateway/*.json
    refresh_interval: 5m
// targets/pushgateway/test.json
[{\"targets\": [\"pushgateway1.example.com:9091\"]}]
# 2.12.7　推送数据：URL 格式详解
\n
http://<pg-addr>:<pg-port>/metrics/job/<job_name>/[<label_name>/<label_value>]/...\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
路径片段作用
/metrics固定接收接口
/job/<job_name>设置  job  标签
/instance/<value>设置  instance  标签
其它  <label>/<value>任意附加标签
\n
最小示例（推一条： age = 18 ）：
\n
echo \"age 18\" | curl --data-binary @- \\
  http://pushgateway.example.com:9091/metrics/job/demo/instance/$(hostname -I | awk '{print $1}')
\n
带类型与帮助的完整示例：
\n
cat <<EOF | curl --data-binary @- http://pushgateway.example.com:9091/metrics/job/some_job/instance/some_instance
# TYPE some_metric counter
some_metric{label=\"val1\"} 42
# TYPE another_metric gauge
# HELP another_metric Just an example.
another_metric 2398.283
EOF
三者作用（呼应第 1 章）：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
行作用
# TYPE声明类型（counter /gauge/histogram /summary/untyped）
# HELP人类可读的说明，Grafana 面板会显示
some_metric{...} 42真正的样本： 指标名{标签} 值
\n
# 2.12.8　删除数据（重要，别只会推不会删）
\n
# 删除某个组下的全部指标
curl -X DELETE http://pushgateway.example.com:9091/metrics/job/some_job/instance/some_instance
# 删除某个 job 下的全部指标
curl -X DELETE http://pushgateway.example.com:9091/metrics/job/some_job
也可以直接在 Pushgateway 的 Web 界面点删除按钮。
\n
\n
⚠️ 生产纪律：任何上线了又下线的任务，必须清理它在 Pushgateway 上的残留。否则那些 "僵尸指标" 会一直出现在查询结果里，污染图表和告警判断。
\n
\n
# 2.12.9　生产可用脚本
\n
一个通用的自定义指标推送脚本，把 "采集命令" 和 "推送" 解耦：
\n
#!/bin/bash
set -uo pipefail
# ===== 只改这几行：想监控什么，就换 METRIC_* =====
METRIC_NAME=\"login_number\"
METRIC_VALUE_CMD='who | wc -l'
METRIC_TYPE=\"gauge\"
METRIC_HELP=\"Current login user number\"
PUSHGATEWAY_HOST=\"pushgateway.example.com:9091\"
JOB_NAME=\"custom_metrics\"
INSTANCE=$(hostname -I | awk '{print $1}')
INTERVAL=60
PUSH_URL=\"http://${PUSHGATEWAY_HOST}/metrics/job/${JOB_NAME}/instance/${INSTANCE}\"
trap 'echo \"[$(date \"+%F %T\")] Exit.\"; exit 0' INT TERM
while true; do
    VALUE=$(eval \"$METRIC_VALUE_CMD\")
    cat <<EOF | curl --silent --show-error --fail --data-binary @- \"$PUSH_URL\" >/dev/null
# HELP ${METRIC_NAME} ${METRIC_HELP}
# TYPE ${METRIC_NAME} ${METRIC_TYPE}
${METRIC_NAME} ${VALUE}
EOF
    if [ $? -eq 0 ]; then
        echo \"[$(date '+%F %T')] Push OK: ${METRIC_NAME}=${VALUE}\"
    else
        echo \"[$(date '+%F %T')] Push FAILED!\"
    fi
    sleep \"${INTERVAL}\"
done
从 "一次性任务" 推数据，交给 cron 定时执行。但不要写超长的单行 cron 命令（引号嵌套会把你逼疯），正确做法是先写一个小脚本，cron 只负责调用它：
\n
# 1. 写脚本 /usr/local/bin/push_login_number.sh
#!/bin/bash
set -euo pipefail
PG=\"http://pushgateway.example.com:9091\"
IP=$(hostname -I | awk '{print $1}')
N=$(who | wc -l)
cat <<EOF | curl -s --fail --data-binary @- \"${PG}/metrics/job/custom_metrics/instance/${IP}\" >/dev/null
# HELP login_number Current login user number
# TYPE login_number gauge
login_number ${N}
EOF
# 2. 授权
chmod +x /usr/local/bin/push_login_number.sh
# 3. cron 只负责调用脚本（/etc/cron.d/push_login_number）
*/5 * * * * root /usr/local/bin/push_login_number.sh
\n
💡 脚本里的三个好习惯：
\n
    \n
  1.  --fail ：HTTP 4xx/5xx 时让 curl 返回非 0，从而能判断推送失败；
    2. \n
  2. 输出成功 / 失败日志：不然任务 "看起来在跑"，其实一直在失败；
    3. \n
  3.  trap  优雅退出：systemd 停止服务时不会留下僵尸循环。
    4. \n
\n
\n
# 2.12.10　验证
\n
    \n
  1. Pushgateway 页面： http://<ip>:9091/  能看到你推上去的指标组；
    2. \n
  2. Prometheus Graph：查  login_number  或  mem_free ，能看到数据。
    3. \n
\n
\n
⚠️ 这里有个小陷阱：如果  honor_labels: true  没配，你在 Prometheus 里查到的  instance  是 Pushgateway 的地址，而不是推送方的地址。查不到特定主机的数据时，先检查这一点。
\n
\n
\n
# 2.13　一个完整例子：监控 Zookeeper
\n
前面所有例子里，被监控对象要么 "本来没有指标"（Linux），要么 "指标要中转"（脚本）。Zookeeper 属于第三类：软件自己就能开指标端口。
\n
# 2.13.1　三种指标来源分类
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
来源例子要点
① 软件内置Grafana、Zookeeper、Nacos、Etcd改配置打开即可，不用装 Exporter
② 第三方 ExporterMySQL、Redis、Nginx需要单独部署 exporter
③ Pushgateway一次性脚本、定时任务主动推
④ 自行编程业务指标需要开发能力，用客户端库
\n
# 2.13.2　打开 Zookeeper 的内置指标端点
\n
Zookeeper 的  zoo_sample.cfg  里已经预置了 Prometheus 相关注释，取消注释即可：
\n
# 在 zoo.cfg 末尾添加（模板里默认就有，只是被注释了）
metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
metricsProvider.httpPort=7000
metricsProvider.exportJvmInfo=true
systemctl restart zookeeper.service
curl http://localhost:7000/metrics | head
\n
💡  metricsProvider.httpPort=7000  就是这个软件给自己开的 "出口"。凡是能在某个端口  curl  到  /metrics  的软件，都不需要额外装 Exporter。
\n
\n
# 2.13.3　加 job，看数据
\n
- job_name: 'zookeeper'
    static_configs:
    - targets: ['10.0.0.101:7000']
promtool check config /usr/local/prometheus/conf/prometheus.yml
systemctl reload prometheus
\n
\n
# 2.14　本章小结
\n
mindmap
  root((\"第2章<br/>部署与点亮\"))
    五个软件
      Prometheus 9090 采集+存储
      Node Exporter 9100 系统指标
      Grafana 3000 展示
      Alertmanager 9093 告警
      Pushgateway 9091 中转
    安装方式
      包安装 快但版本旧
      二进制 生产标准
      容器 注意挂载
      Ansible 批量
    关键参数
      config.file
      storage.tsdb.path
      storage.tsdb.retention.time
      web.enable-lifecycle 危险
    配置文件
      global
      alerting
      rule_files
      scrape_configs
    踩过的坑
      root启动污染权限
      YAML缩进
      端口写错
      容器内配置文件
      指标有延迟
      uname采集器
    Pushgateway
      up指标失效
      永不清理
      单点
      不校验
六条必须记住的运维经验：
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
#经验出处
1调试用哪个身份启动，生产就用哪个身份root 污染 data 目录
2 --web.enable-lifecycle  生产禁用一行 curl 就能远程关掉服务
3改配置：先  promtool check config ，再 reload，再查 Targets三步固定流程
4"暴露" 和 "采集" 是两件事Node Exporter 有了还得加 job
5抓不到数据先看 Targets，它会告诉你具体 URL 和错误端口写成 9010 的教训
6容器化 Node Exporter 必须 host 网络 + host PID + 挂载 /否则采的是容器自己
\n
\n
# 2.15　面试高频问答
\n
Q1：Prometheus 有几种安装方式？生产推荐哪种，为什么？
\n
\n
包安装、二进制、Ansible、Docker、Docker Compose、K8s 六种。
\n生产推荐二进制 + systemd：版本可控（不被发行版仓库锁死）、零依赖（Go 静态编译）、目录布局自由（配置 / 数据可分离、数据目录可独立分区）、排障直观（日志、进程、路径都在明处）。大规模机器建议 Ansible，云原生环境用 Operator / Helm。
\n
\n
Q2： --web.enable-lifecycle  是干什么的？为什么不建议开？
\n
\n
它允许通过 HTTP API 触发  /-/reload  和  /-/quit 。风险在于无任何认证：任何能访问 9090 的人都能  POST /-/quit  直接把监控服务关掉。而 reload 这件事用  systemctl reload （配合  ExecReload=/bin/kill -HUP ）完全能实现。所以生产保持默认 false。
\n
\n
Q3：改了配置文件怎么让它生效？
\n
\n
三步： promtool check config  校验语法 →  systemctl reload prometheus （SIGHUP 热加载）→ 在 Status → Configuration 确认生效、Status → Targets 确认目标 UP。
\n注意：改启动参数（如  --storage.tsdb.path ）必须 restart，热加载不了。
\n
\n
Q4：为什么 Node Exporter 装在容器里要  --net=host --pid=host -v /:/host ？
\n
\n
因为它的职责是采集宿主机的指标，而不是容器自己的。共享网络命名空间才能看到真实网卡；共享 PID 命名空间才能看到宿主机全部进程；挂载宿主机根目录并指定  --path.rootfs=/host  才能读到真实的  /proc 、 /sys  和文件系统使用率。否则采到的全是容器 overlay 里的数据。
\n
\n
Q5：Pushgateway 有什么缺点？
\n
\n
四个：① 单点故障；②  up  指标失效（看不到真实目标存活，服务挂了旧数据还在，造成 "假存活"）；③ 数据永不自动清理，必须手动 DELETE；④ 不做数据校验，脏数据照单全收。
\n因此它只适合短周期 / 一次性任务的指标，长期运行的服务应该用 Exporter。
\n
\n
Q6：如何监控 Grafana 自身？
\n
\n
Grafana 自带  /metrics  端点（:3000），在  prometheus.yml  里加一个 job 采集它，然后在 Grafana 里用 Prometheus 数据源查询展示。注意它不能自己展示自己 ——Grafana 是展示层不是数据源，必须经 Prometheus 中转。
\n
\n
Q7： honor_labels: true  有什么作用？
\n
\n
采集 Pushgateway 时必须加。否则 Prometheus 会用自己配置的  job / instance  覆盖掉推送方设置的标签，导致所有应用的数据都像是同一个来源。加上之后保留 Pushgateway 上的标签，Prometheus 自己的标签改名为  exported_job / exported_instance 。
\n
\n
\n
# 2.16　动手实验
\n
# 实验一（必做）　二进制装全套 + 采集四台主机
\n
目标： up{job="node_exporter"}  返回 4 条，值全为 1。
\n
步骤清单（打勾）\n□ 1. 三台机器规划：100=监控服务器，101/102/103=被监控节点\n□ 2. 100 上二进制安装 Prometheus（2.53.x 或 3.x LTS）\n□ 3. 目录规划 bin/conf/data + 建 prometheus 服务账号 + chown\n□ 4. 先手动启动一次验证（注意：用 prometheus 身份，别用 root！）\n□ 5. 写 systemd 单元（含 LimitNOFILE、ExecReload），enable --now\n□ 6. 访问 9090，看 Status → Runtime 确认版本与启动时间\n□ 7. 四台机器全装 node_exporter，加 service，9100 监听\n□ 8. curl 各自 9100/metrics 确认暴露正常\n□ 9. prometheus.yml 新增 node_exporter job，4 个 target\n□ 10. promtool check config → systemctl reload\n□ 11. Status → Targets 确认 4 个全 UP\n□ 12. Graph 里查 node_memory_MemAvailable_bytes，应有 4 条序列\n
\n
思考题（做完实验再回答）：
\n
    \n
  1. 为什么  data/  目录第一次启动是空的，第二次启动就有内容了？
    2. \n
  2. process_max_fds  这个指标的值，是从哪里来的？（提示：service 文件）
    3. \n
  3. 如果把  scrape_interval  改成  1s ， up  的变化会更快，但会带来什么代价？
    4. \n
\n
# 实验二　容器化对照实验
\n
用 Docker 起 Prometheus 和 Node Exporter，故意不加  --net=host ，然后：
\n
    \n
  1. 在容器里执行  curl localhost:9100/metrics | grep node_network  —— 看有几块网卡？
    2. \n
  2. 加上  --net=host  再执行一次 —— 有几块？
    3. \n
  3. 用两行命令理解 "网络命名空间隔离" 这句话是什么意思。
    4. \n
\n
# 实验三　Grafana 全链路
\n
□ 1. 安装 Grafana（apt install ./xxx.deb）\n□ 2. 登 3000，admin/admin，改密码\n□ 3. 加 Prometheus 数据源，Save & Test 成功\n□ 4. 导入内置 Prometheus Stats → 看数据\n□ 5. 导入内置 Grafana metrics → 看到 No data，解释原因\n□ 6. 在 prometheus.yml 加 grafana job，reload\n□ 7. 回 Grafana 刷新 → Grafana metrics 有数据了\n□ 8. 导入 Dashboard 1860 / 8919 → 看到四台主机 CPU 曲线\n
\n
关键问答：第 5 步为什么没数据？第 7 步为什么就有了？用一句话讲清这条链路。
\n
# 实验四　Pushgateway 推一个自定义指标
\n
# 1. 装 Pushgateway，9091 监听
# 2. prometheus.yml 加 job（务必 honor_labels: true），reload
# 3. 推一个登录数
echo \"login_number $(who | wc -l)\" | curl --data-binary @- \\
  http://<pg-ip>:9091/metrics/job/custom_metrics/instance/$(hostname -I | awk '{print $1}')
# 4. Pushgateway 页面看到指标组
# 5. Prometheus 里查 login_number
# 6. 故意停掉脚本，等 5 分钟，再查 login_number —— 数据还在吗？为什么？
# 7. 用 DELETE 清掉，再查 —— 没了吧
第 6 步的答案，就是 Pushgateway 最大的坑。 请务必亲手做一次。
\n
\n
# 2.17　下章预告
\n
本章我们把 "能跑起来" 这件事做到了：四个端口全亮，四台主机的 CPU 曲线出现在 Grafana 上。
\n
但你会发现一个尴尬的事实：图虽然有了，可我看不懂那些指标名，也不知道该怎么算。
\n
node_cpu_seconds_total  为什么是一个只增不减的巨大数字？为什么不能直接画它就要先做  rate() ？
\n
下一章专门解决这个问题：
\n\n
本章作业：把 "抓不到数据五步排查法" 抄在笔记本第一页。后面所有实验，你都会用到它。
\n",
            "tags": [
                "Prometheus"
            ]
        },
        {
            "id": "http://blog.jaxxwang.cn/posts/3825997150.html",
            "url": "http://blog.jaxxwang.cn/posts/3825997150.html",
            "title": "01 ELK 日志收集系统概述",
            "date_published": "2025-12-09T16:00:00.000Z",
            "content_html": "
# ELK 相关技术介绍
\n
# 1. ELK 诞生的背景
\n
# 1.1 没有 ELK 分析日志前
\n
没有日志分析工具之前，运维工作存在哪些痛点？
\n\n
# 1.2 使用 ELK 分析日志后
\n
如上所有的痛点都可以使用日志分析系统 ELK 解决，通过 ELK，将运维所有的服务器日志，业务系统日志都收集到一个平台下，然后提取想要的内容，比如错误信息，警告信息等，当过滤到这种信息，就马上告警，告警后，运维人员就能马上定位是哪台机器、哪个业务系统出现了问题，出现了什么问题。
\n
# 2. ELK 技术栈是什么
\n
# 2.1 什么是 ELK
\n
其实 ELK 不是一个单独的技术，而是一套技术的组合，是由 Elasticsearch、Logstash、Kibana 组合而成的。
\nELK 是一套开源免费、功能强大的日志分析管理系统。ELK 可以将我们的系统日志、网站日志、应用系统日志等各种日志进行收集、过滤、清洗，然后进行集中存放并可用于实时检索、分析。
\n\n
缺点：
\n\n
# 2.2 什么是 EFK
\n
简单来说就是将 Logstash 替换成了 Filebeat，那为什么要进行替换？
\n因为 Logstash 是基于 JAVA 开发的，在收集日志时会大量的占用业务系统资源，从而影响正常线上业务。而替换成 filebeat 这种较为轻量的日志收集组件，会让业务系统的运行更加的稳定。
\n
缺点：
\n\n
# 2.3 什么是 ELFK
\n
# 2.4 ELK + Kafka
\n
该解决方案可支持每日 1TB 级别的业务日志处理。若贵公司业务日志量达到每日 10 TB，建议根据业务系统进行横向拆分，部署多套独立 ELK 集群。
\n
Kafka 消息队列 可以将 Filebeat 与 ElasticSearch 进行解耦，从而可以避免 ES 被打爆的现象；
\n
Logstash
\n\n
# 2.4 EFK 收集哪些日志
\n\n
# 2.5 ELK 软件下载地址
\n
# 2.5.1 RedHat 系列
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
软件名称版本下载地址
ElasticSearch8.18.2https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.18.2-x86_64.rpm
Logstash8.18.2https://artifacts.elastic.co/downloads/logstash/logstash-8.18.2-x86_64.rpm
Kibana8.18.2https://artifacts.elastic.co/downloads/kibana/kibana-8.18.2-x86_64.rpm
Filebeat8.18.2https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.18.2-x86_64.rpm
\n
# 2.5.2 Debian 系统
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
软件名称版本下载地址
ElasticSearch8.18.2https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.18.2-amd64.deb
Logstash8.18.2https://artifacts.elastic.co/downloads/logstash/logstash-8.18.2-amd64.deb
Kibana8.18.2https://artifacts.elastic.co/downloads/kibana/kibana-8.18.2-amd64.deb
Filebeat8.18.2https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.18.2-amd64.deb
\n",
            "tags": [
                "ELK"
            ]
        },
        {
            "id": "http://blog.jaxxwang.cn/posts/4103087246.html",
            "url": "http://blog.jaxxwang.cn/posts/4103087246.html",
            "title": "02 Elasticsearch 入门",
            "date_published": "2025-12-09T16:00:00.000Z",
            "content_html": "
# 1、ES 基本概念介绍
\n
# 1.1 ES 是什么
\n
Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎。
\n
# 1.2 ES 主要功能
\n
数据存储、数据搜索、数据分析。
\n
# 2、ES 相关术语
\n
# 2.1 文档 Document
\n
Document 文档就是用户存在 es 中的数据，它是 es 中存储的最小单元。（类似于表中的一行数据）
\n注意：每个文档都有一个唯一的 ID 表示，可以自行指定，如果不指定 es 会自动生成。
\n
# 2.2 索引 Index
\n
索引其实是一堆文档 Document 的集合。（它类似数据库的中的一个表）
\n在一个索引中，会有多个文档，而每个文档是由多个不同类型的字段拼接在一起的。
\n
# 2.3 字段 Filed
\n
在 ES 中，Document 就是一个 Json Object，一个 Json Object 其实是由多个字段组成的，每个字段它有不同的数据类型。
\n\n
# 2.4 ES 术语总结
\n
ES 索引、文档、字段关系小结：
\n一个索引里面存储了很多的 Document 文档，一个文档就是一个 Json Object，一个 Json Object 是由多个不同或相同的 filed 字段组成。
\n
# 3、ES 操作方式
\n
ES 的操作和我们传统的数据库操作不太一样，它是通过 Restful API 方式进行操作的，其实本质上就是通过 HTTP 的方式去变更我们的资源状态：
\n\n
常见操作 ES 的两种方式：Curl、Kibana DevTools
\n
# 3.1 ES 单节点部署
\n
# 3.1.1 CentOS 系列
\n
# 1、安装 Java 环境
[root@es-node1 ~]# yum install java-17-openjdk java-17-openjdk-devel
# 2、安装 ES
[root@es-node1 ~]# rpm -ivh elasticsearch-8.18.2-x86_64.rpm
# 3、关闭 ES 默认开启的 Security 认证
[root@es-node1 ~]# vim /etc/elasticsearch/elasticsearch.yml
# Enable security features
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# 4、修改 ES 的 JVM 堆内存
[root@es-node1 ~]# vim /etc/elasticsearch/jvm.options
-Xms1g
-Xmx1g
# 5、启动 ES 单节点
[root@es-node1 ~]# systemctl enable --now elasticsearch
# 6. 端口验证
[root@es-node1 ~]# netstat -nltp
# 9200    <= HTTP 通信端口
# 9300    <= 内部集群通信端口
# 7、访问 ES
[root@es-node1 ~]# curl localhost:9200
访问 ES 正常返回结果：
\n
{
  \"name\" : \"es-node01.oldwang.net\",
  \"cluster_name\" : \"elasticsearch\",
  \"cluster_uuid\" : \"HJlIqvnXQx2KfPzttxcA7A\",
  \"version\" : {
    \"number\" : \"8.18.2\",
    \"build_flavor\" : \"default\",
    \"build_type\" : \"rpm\",
    \"build_hash\" : \"16cc90cd2d08a3147ce02b07e50894bc060a4cbf\",
    \"build_date\" : \"2099-04-05T14:45:26.420424304Z\",
    \"build_snapshot\" : false,
    \"lucene_version\" : \"9.10.0\",
    \"minimum_wire_compatibility_version\" : \"7.17.0\",
    \"minimum_index_compatibility_version\" : \"7.0.0\"
  },
  \"tagline\" : \"You Know, for Search\"
}
# 3.1.2 Ubuntu 系列
\n
# 1. 安装 Java 环境
[root@es-node1 ~] apt update
[root@es-node1 ~] apt install -y openjdk-17-jdk
# 2. 安装 Elasticsearch
[root@es-node1 ~] wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.18.2-amd64.deb
[root@es-node1 ~] dpkg -i elasticsearch-8.18.2-amd64.deb
# 3. 关闭 ES 默认开启的 Security 认证
[root@es-node1 ~] vim /etc/elasticsearch/elasticsearch.yml
# 修改以下内容
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# 4. 修改 ES 的 JVM 堆内存
[root@es-node1 ~] vim /etc/elasticsearch/jvm.options
# 修改
-Xms1g
-Xmx1g
# 5. 启动 ES 单节点
[root@es-node1 ~] systemctl enable --now elasticsearch
# 6. 端口验证
[root@es-node1 ~] ss -nltp
# 9200 <= HTTP 通信端口
# 9300 <= 内部集群通信端口
# 7. 访问 ES
[root@es-node1 ~] curl localhost:9200
访问 ES 正常返回结果：
\n
{
  \"name\" : \"es-node1.wang.org\",
  \"cluster_name\" : \"elasticsearch\",
  \"cluster_uuid\" : \"xQUmZCMTQ7Ohi3TB25H0Yw\",
  \"version\" : {
    \"number\" : \"8.18.2\",
    \"build_flavor\" : \"default\",
    \"build_type\" : \"deb\",
    \"build_hash\" : \"c6b8d8d951c631db715485edc1a74190cdce4189\",
    \"build_date\" : \"2025-05-23T10:07:06.210694702Z\",
    \"build_snapshot\" : false,
    \"lucene_version\" : \"9.12.1\",
    \"minimum_wire_compatibility_version\" : \"7.17.0\",
    \"minimum_index_compatibility_version\" : \"7.0.0\"
  },
  \"tagline\" : \"You Know, for Search\"
}
# 3.2 Curl 命令操作 ES
\n
# 1、使用 Curl 命令来创建索引，录入一份文档
[root@es-node1 ~]# curl -XPUT 'http://localhost:9200/oldwang_index/_doc/1' \\
-H \"Content-Type: application/json\" \\
-d '{
\"name\":\"oldwang\",
\"age\":18,
\"salary\": 1000000
}'
# 2、使用 Curl 命令来查看录入的数据
[root@es-node1 ~]# curl -XGET 'http://localhost:9200/oldwang_index/_doc/1'
查看数据返回结果：
\n
{\"_index\":\"oldwang_index\",\"_id\":\"1\",\"_version\":1,\"_seq_no\":0,\"_primary_term\":1,\"found\":true,\"_source\":{
  \"username\": \"oldwang\",
  \"age\": 18,
  \"salary\": 1000000
}}
# 3.3 安装 Kibana 操作 ES
\n
# 3.3.1 CentOS 系列
\n
# 1、安装 kibana
[root@es-node1 ~]# rpm -ivh kibana-8.18.2-x86_64.rpm
# 2、配置 Kibana
[root@es-node1 ~]# vim /etc/kibana/kibana.yml
# 配置内容：
server.port: 5601                                  # kibana 默认监听端口
server.host: \"0.0.0.0\"                             # kibana 监听地址段
server.name: \"kibana-node\"                         # kibana 实例名称
server.publicBaseUrl: \"http://kibana.oldwang.net\"    # Kibana 的公共 URL, 例如分享链接、API 调用等都会使用该地址
elasticsearch.hosts: [\"http://localhost:9200\"]     # kibana 从 coordinating 节点获取数据 (此处 ES. Kibana 属同节点，因此填写 localhost; 正常应该填写 ES 服务器地址)
i18n.locale: \"zh-CN\"                               # kibana 汉化
# 3、启动 kibana
[root@es-node1 ~]# systemctl enable kibana --now
# 3.3.2 Ubuntu 系列
\n
# 1、安装 kibana
[root@kibana ~]# dpkg -i kibana-8.18.2-amd64.deb
# 2、配置 Kibana
[root@kibana ~]# vim /etc/kibana/kibana.yml
# 配置内容：
server.port: 5601                                  # kibana 默认监听端口
server.host: \"0.0.0.0\"                             # kibana 监听地址段
server.name: \"kibana-node\"                         # kibana 实例名称
server.publicBaseUrl: \"http://192.168.80.150\"      # Kibana 的公共 URL, 例如分享链接、API 调用等都会使用该地址 (推荐使用域名地址)
elasticsearch.hosts: [\"http://192.168.80.151:9200\"] # 此处填写 ES 服务器地址，kibana 从 coordinating 节点获取数据
i18n.locale: \"zh-CN\"                               # kibana 汉化
# 3、启动 kibana
[root@kibana ~]# systemctl enable kibana --now
# 3.4 访问 Kibana
\n
访问地址： http://192.168.80.150:5601
\n
# 3.5 启用堆栈监测（或 安装 Metricbeat 实现）
\n
操作路径： Management > 堆栈监测 > 使用内部收集设置 > 打开 Monitoring
\n
# 4、索引 API
\n
ES 有专门的 Index API，用于创建、更新、删除索引配置等。
\n操作入口： Management > 开发工具
\n
# 4.1 创建索引
\n
创建索引相关 API：
\n
# 创建索引
PUT /oldwang_index
# 查看所有已存在的索引
GET _cat/indices
# 查看健康状态
GET _cat/health
# 查看节点主机
GET _cat/nodes
使用方式：在 Kibana 开发工具中输入需要运行的命令，单击运行发送请求。
\n
# 4.2 删除索引
\n
删除索引 API：
\n
# 删除索引
DELETE /oldwang_index
# 4.3 查看索引
\n
使用 Kibana 查看索引路径： Stack Management > 索引管理 > 索引
\n
# 5、文档 API
\n
ES 为索引添加文档，有专门的 Document API：
\n\n
# 5.1 创建文档
\n
# 创建文档（指定 ID）
\n
# 创建一个文档 (指定 ID)
POST /oldwang_index/_doc/1
{
  \"username\": \"oldwang\",
  \"age\": 18,
  \"salary\": 1000000
}
说明：创建文档时，如果索引不存在，ES 会自动创建对应的 index 和 type。
\n
# 创建文档（不指定 ID）
\n
# 创建文档，不指定 ID（id 会生成随机字符串）
POST /oldwang_index/_doc
{
  \"username\": \"oldwang\",
  \"age\": 18,
  \"salary\": 1000000
}
# 5.2 查询文档
\n
# 查询指定 ID 文档
\n
GET /oldwang_index/_doc/1
# 查询所有文档
\n
GET /oldwang_index/_search
# 查询指定内容
\n
GET /oldwang_index/_search
{
  \"query\": {
    \"match\": {
      \"username\": \"oldwang\"    
    }
  }
}
# 5.3 批量创建文档
\n
ES 允许通过  _bulk  一次创建多个文档，从而减少网络传输开销，提升写入速率。
\n
# 批量创建 Document
POST _bulk
{\"index\":{\"_index\":\"tt\",\"_id\":\"1\"}}
{\"name\":\"oldwang\",\"age\":\"18\"}
{\"create\":{\"_index\":\"tt\",\"_id\":\"2\"}}
{\"name\":\"oldqiang\",\"age\":\"30\"}
{\"delete\":{\"_index\":\"tt\",\"_id\":\"2\"}}
{\"update\":{\"_id\":\"1\",\"_index\":\"tt\"}}
{\"doc\":{\"age\":\"20\"}}
# 5.4 批量查询文档
\n
ES 允许通过  _mget  一次查询多个文档。
\n
# 批量查询 Document
GET _mget
{
  \"docs\": [
    {
      \"_index\": \"tt\",
      \"_id\": \"1\"
    },
    {
      \"_index\": \"tt\",
      \"_id\": \"2\"
    }
  ]
}
# 总结
\n
    \n
  1. ES 核心概念：文档是最小存储单元（对应数据库行）、索引是文档集合（对应数据库表）、字段是文档的属性且有多种数据类型。
    2. \n
  2. ES 操作核心：基于 RESTful API，可通过 Curl 命令行或 Kibana 可视化工具操作，核心 HTTP 方法包括 PUT/GET/POST/DELETE。
    3. \n
  3. 部署与使用：CentOS/Ubuntu 系统均支持 ES 和 Kibana 部署，Kibana 可汉化且提供友好的可视化操作界面，支持索引和文档的增删改查及批量操作。
    4. \n
\n",
            "tags": [
                "ELK"
            ]
        },
        {
            "id": "http://blog.jaxxwang.cn/posts/2265425726.html",
            "url": "http://blog.jaxxwang.cn/posts/2265425726.html",
            "title": "04 Filebeat 日志收集入门",
            "date_published": "2025-12-09T16:00:00.000Z",
            "content_html": "
# 1、Filebeat 基本介绍
\n
# 1.1 Filebeat 是什么
\n
Filebeat 是用于 "转发" 和 "集中日志数据" 的 "轻量型数据采集器"；
\nFilebeat 会监视指定的日志文件路径，收集日志事件并将数据转发到 Elasticsearch、Logstash、Redis、Kafka 存储服务器。
\n
# 1.2 Filebeat 主要组件
\n
Filebeat 主要由两个核心组件组成：Input 和 Harvester。
\n\n
这两个组件协同工作，确保将日志文件尾部 最新的数据 发送到指定的输出端。
\n
配置示例：
\n
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/oldwang.log      # 指定日志路径
      - /var/log/*.log          # 指定日志，匹配方式
      # - /var/log/**/*.log     # 递归目录，完成日志的匹配
# 1.3 Filebeat 工作流程
\n
当 filebeat 启动后，filebeat 通过 Input 读取指定的日志路径，然后为该日志启动一个收割进程 harvester，每一个收割进程读取一个日志文件的新内容，并发送这些新的日志数据到处理程序 spooler，处理程序会集合这些事件，最后 filebeat 会发送集合的数据到你指定的位置。
\n
# 2、Filebeat 安装配置
\n
# 2.1 Filebeat 安装
\n
    \n
  1. 安装 Filebeat
    2. \n
\n
[root@web01 ~]$ dpkg -i filebeat-8.18.2-amd64.deb
[root@web01 ~]# rpm -ivh filebeat-8.18.2-x86_64.rpm
    \n
  1. 启动 Filebeat
    2. \n
\n
[root@web01 ~]# systemctl enable --now filebeat.service
# 2.2 Filebeat 配置说明
\n
# 定义 Filebeat 输入源
filebeat.inputs:
  - type: log                      # 输入类型为日志文件
    enabled: true                  # 启用该输入
    paths:
      - /var/log/nginx/access.log  # 指定日志路径
    tags: [\"nginx-access\"]         # 为该日志添加标签，可用于后续过滤或分析
  
  - type: log
    enabled: true
    paths:
      - /var/log/nginx/error.log   # 指定日志路径
    tags: [\"nginx-error\"]          # 为该日志添加标签
# 定义输出，将日志发送到 Elasticsearch
output.elasticsearch:
  hosts: [\"elasticsearch:9200\"]     # 指定 Elasticsearch 地址
# 3、Filebeat 常用 Input 插件
\n
# 3.1 Filebeat 从终端读取数据
\n
    \n
  1. 配置 Filebeat 从终端读取数据，然后从终端输出消息
    2. \n
\n
[root@web01 ~]# mkdir /etc/filebeat/conf.d
[root@web01 ~]$ vim /etc/filebeat/conf.d/01-stdin-output-console.yml
配置文件内容：
\n
filebeat.inputs:
  - type: stdin
    enable: true
output.console:
  pretty: true
  enable: true
    \n
  1. 启动 Filebeat，并明确指定配置文件路径，然后输入一条测试内容
    2. \n
\n
\n
注意：基于如下方式启用 filebeat 的同时，需要将 filebeat 服务关闭。否则会报错： Exiting: /var/lib/filebeat/filebeat.lock: data path already locked by another beat. Please make sure that multiple beats are not sharing the same data path (path.data)
\n
\n
[root@web01 ~]# systemctl stop filebeat.service
[root@web01 ~]$ filebeat -e -c /etc/filebeat/conf.d/01-stdin-output-console.yml
# 输入内容
hello,filebeat
    \n
  1. 结果返回
    2. \n
\n
{
  \"@timestamp\": \"2025-07-26T04:37:46.332Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"log\": {
    \"offset\": 0,                      <== Filebeat 当前从日志文件中读取到的位置
    \"file\": {
      \"path\": \"\"                      <== 日志来源文件路径 (空值, 因为此日志来自 stdin 输入而非文件)
    }
  },
  \"message\": \"hello,filebeat\",        <== 核心日志内容
  \"input\": {
    \"type\": \"stdin\"                   <== 表示输入来源为标准输入
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"       <== 产生日志的主机名信息
  },
  \"agent\": {
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\",
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"ba6b6172-3cdf-4060-b43f-a018f79e5c42\"
  }
}
\n
说明： offset: 0  表示 Filebeat 刚开始读取该文件，从第一个字节（起始位置）开始读取。如果  offset: 1500 ，表示 Filebeat 已经读取了前 1500 字节，它会从第 1501 字节继续读取。
\n
\n
# 3.2 Filebeat 从网络中读取数据
\n
在分布式系统或多服务架构中，直接从本地系统采集日志有时不太方便。为此，可以将应用程序日志通过 TCP 或 UDP 协议发送到特定网络端口，然后通过 Filebeat 接收此端口的日志数据。
\n
# 3.2.1 监听 TCP 端口并输出到控制台
\n
    \n
  1. 编写配置
    2. \n
\n
[root@web01 ~]$ vim /etc/filebeat/conf.d/02-tcp-output-console.yml
配置文件内容：
\n
filebeat.inputs:
  - type: tcp                 # 指定类型为 TCP, 也可以是 UDP
    enable: true              # 启用该输入配置
    host: \"0.0.0.0:5656\"      # 监听网络地址及端口
    max_message_size: \"10M\"   # 限制单条消息最大为 10M. 默认值为 20MiB.
output.console:
  pretty: true                # 以格式化的美观方式输出日志
  enable: true
    \n
  1. 启动 Filebeat 并应用上述配置
    2. \n
\n
[root@web01 ~]$ filebeat -e -c /etc/filebeat/conf.d/02-tcp-output-console.yml
    \n
  1. 验证 Filebeat 是否成功监听了 5656 端口
    2. \n
\n
[root@web01 ~]$ netstat -nltp
tcp6       0      0 :::5656                 :::*                    LISTEN      64290/filebeat
# 3.2.2 监听 UDP 端口并输出到控制台
\n
    \n
  1. 编写配置
    2. \n
\n
[root@web01 ~]$ vim /etc/filebeat/conf.d/02-udp-output-console.yml
配置文件内容：
\n
filebeat.inputs:
  - type: udp                 # 指定类型为 UDP
    enable: true              # 启用该输入配置
    host: \"0.0.0.0:5658\"      # 监听网络地址及端口
    max_message_size: \"10M\"   # 限制单条消息最大为 10M. 默认值为 20MiB.
    
output.console:
  pretty: true                # 以格式化的美观方式输出日志
  enable: true
    \n
  1. 启动 Filebeat 并应用上述配置
    2. \n
\n
[root@web01 ~]$ filebeat -e -c /etc/filebeat/conf.d/02-udp-output-console.yml
    \n
  1. 验证 Filebeat 是否成功监听了 5658 端口
    2. \n
\n
[root@web01 ~]$ netstat -nltup
udp6       0      0 :::5658                 :::*                                86005/filebeat
# 3.2.3 模拟发送数据
\n
[root@web01 ~]$ echo \"hello,tcp\" | nc 192.168.80.154 5656      # TCP 协议方式
[root@web01 ~]$ echo \"hello,udp\" | nc -u 192.168.80.154 5658   # UDP 协议方式
# 3.2.4 查看接收数据
\n\n
{
  \"@timestamp\": \"2025-07-26T05:00:32.381Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"input\": {
    \"type\": \"tcp\"                  <== 当前日志的输入类型为 TCP
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"    <== 运行 Filebeat 代理的主机名
  },
  \"agent\": {
    \"type\": \"filebeat\",
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"f3cc997d-dfc0-4716-a9ae-c1da98e63532\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\"
  },
  \"message\": \"hello,tcp\",          <== 实际接收到的日志内容, 即通过 TCP 发送到 5656 端口的原始数据
  \"log\": {
    \"source\": {
      \"address\": \"192.168.80.151:44322\"   <== 发送日志的客户端 IP 地址
    }
  }
}
\n
{
  \"@timestamp\": \"2025-07-26T05:08:43.767Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\",
    \"truncated\": false
  },
  \"message\": \"hello,udp\\n\",    <== 实际接收到的日志内容, 即通过 UDP 发送到 5658 端口的原始数据
  \"log\": {
    \"source\": {
      \"address\": \"192.168.80.151:50754\"    <== 发送日志的客户端 IP 地址
    }
  },
  \"input\": {
    \"type\": \"udp\"                    <== 当前日志的输入类型为 UDP
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"      <== 运行 Filebeat 代理的主机名
  },
  \"agent\": {
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\",
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"af3b7435-9fc5-4c9b-882a-6a0e34ba1847\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  }
}
# 3.3 Filebeat 从文件中读取数据
\n
\n
注意：Filebeat 7.16.0 版本之后 Log 被废弃，官方建议使用 filestream 插件。
\n
\n
    \n
  1. 配置 Filebeat 从文件中读取数据
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/conf.d/03-file-output-console.yml
配置文件内容：
\n
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/test.log      # 指定需要监控的日志文件
      # - /var/log/*.log       # 监控 /var/log 目录下所有 .log 结尾的文件
      # - /var/log/**/*.log    # 递归监控 /var/log 及其子目录下所有 .log 结尾的文件
output.console:
  pretty: true
  enable: true
    \n
  1. 启动 Filebeat
    2. \n
\n
# 启动 Filebeat
[root@web01 ~]# filebeat -e -c /etc/filebeat/conf.d/03-file-output-console.yml
# 向 /var/log/test.log 文件追加内容
[root@web01 ~] echo \"hello,filebeat01\" >> /var/log/test.log
[root@web01 ~] echo \"hello,filebeat02\" >> /var/log/test.log
    \n
  1. 查看 Filebeat 接收到的数据
    2. \n
\n\n
{
  \"@timestamp\": \"2025-07-26T16:21:41.320Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"log\": {
    \"offset\": 0,                        <== 起始位置
    \"file\": {
      \"path\": \"/var/log/test.log\"
    }
  },
  \"message\": \"hello,filebeat01\",        <== 输入内容
  \"input\": {
    \"type\": \"log\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"agent\": {
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\",
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"e793a9b2-afaa-41c5-8075-c1899f770c14\"
  }
}
\n
{
  \"@timestamp\": \"2025-07-26T16:22:56.332Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"log\": {
    \"offset\": 17,                    <== 断点续读
    \"file\": {
      \"path\": \"/var/log/test.log\"
    }
  },
  \"message\": \"hello,filebeat02\",    <== 输入内容
  \"input\": {
    \"type\": \"log\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"agent\": {
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\",
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"e793a9b2-afaa-41c5-8075-c1899f770c14\"
  }
}
# 4、Filebeat 常用 Output
\n
Filebeat 常用的 Output 参考地址：https://www.elastic.co/guide/en/beats/filebeat/current/configuring-output.html
\n
# 4.1 Filebeat 输出至 ES 集群
\n
    \n
  1. 配置 Filebeat 将日志采集，并输出到 Elasticsearch 集群
    2. \n
\n
# 4.1.1 编写配置文件
\n
[root@web01 ~]# vim /etc/filebeat/filebeat.yml
配置文件内容：
\n
filebeat.inputs:
- type: log                        # 输入类型为日志文件
  enabled: true                    # 启用该输入配置
  paths: /var/log/test.log         # 监控 /var/log/test.log 文件的日志
# 输出目标为 Elasticsearch 集群
output.elasticsearch:
  hosts: [\"192.168.80.151:9200\",\"192.168.80.152:9200\",\"192.168.80.153:9200\"]
# 4.1.2 重启 Filebeat 服务
\n
[root@web01 ~]# systemctl restart filebeat
# 4.1.3 向监控的日志文件追加新内容
\n
[root@web01 ~]# echo \"hello,filebeat03\" >> /var/log/test.log
    \n
  1. \n
    通过 Cerebro 观察新写入到 ES 的索引数据
    \n
    2. \n
  2. \n
    索引默认格式说明
    \n默认没有定义索引名称的情况下，索引默认格式为： .ds-{name}-{version}-{date}-{date}-{counter} 
    \n 例如： .ds-filebeat-8.18.2-2099.05.01-000001
    \n
    3. \n
\n\n
# 4.2 Filebeat 自定义索引名称
\n
默认 Filebeat 写入 ES 的索引名称为  .ds-filebeat-* ，如果希望修改索引名称，则通过  index  关键字实现。
\n
    \n
  1. 修改 Filebeat 配置文件
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/filebeat.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/test.log
output.elasticsearch:
  hosts: [\"192.168.80.151:9200\",\"192.168.80.152:9200\",\"192.168.80.153:9200\"]
  index: \"test-log-%{[agent.version]}-%{+yyyy.MM.dd}\"      # 自定义索引名称
setup.ilm.enabled: false                 # 索引生命周期 ilm 功能默认开启，开启情况下索引名称只能为 .ds-filebeat-*
setup.template.name: \"test-log\"          # 定义模板名称
setup.template.pattern: \"test-log-*\"     # 定义模板的 \"匹配索引名称规则\"
# 8.x 必须配置如下内容，否则不会创建索引，而会创建对应的索引数据流
setup.template.enabled: false            # 关掉默认的模板配置
setup.template.overwrite: true           # 允许覆盖已存在的同名模板
    \n
  1. 重启 Filebeat 产生新的索引
    2. \n
\n
[root@web01 ~]# systemctl start filebeat
[root@web01 ~]# systemctl status filebeat
    \n
  1. 向监控的日志文件追加新内容
    2. \n
\n
[root@web01 ~]# echo \"hello,filebeat04\" >> /var/log/test.log
[root@web01 ~]# echo \"hello,filebeat05\" >> /var/log/test.log
    \n
  1. 检查结果
    2. \n
\n\n
# 4.3 Filebeat 自定义索引分片
\n
默认情况下 Filebeat 写入到 ES 的索引分片为 1，如果需要修改分片，可以通过以下两种方式：
\n
# 方式 1：通过 Filebeat 配置文件
\n
    \n
  1. 修改 filebeat 配置文件
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/filebeat.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/test.log
output.elasticsearch:
  hosts: [\"192.168.80.151:9200\",\"192.168.80.152:9200\",\"192.168.80.153:9200\"]
  index: \"test-log-%{[agent.version]}-%{+yyyy.MM.dd}\"      # 自定义索引名称
setup.ilm.enabled: false                 # 索引生命周期 ilm 功能默认开启，开启情况下索引名称只能为 .ds-filebeat-*
setup.template.name: \"test-log\"          # 定义模板名称
setup.template.pattern: \"test-log-*\"     # 定义模板的 \"匹配索引名称规则\"
# 8.x 必须配置如下内容，否则不会创建索引，而会创建对应的索引数据流
setup.template.enabled: false            # 关掉默认的模板配置
setup.template.overwrite: true           # 允许覆盖已存在的同名模板
setup.template.settings:
  index.number_of_shards: 3        # 每个索引的主分片数量为 3
  index.number_of_replicas: 1      # 每个主分片的副本分片数量为 1
    \n
  1. 删除索引、删除索引模板，最后重启 filebeat
    2. \n
\n
systemctl restart filebeat
    \n
  1. 产生新的数据及索引
    2. \n
\n
[root@web01 ~]# echo \"hello,filebeat04\" >> /var/log/test.log
[root@web01 ~]# echo \"hello,filebeat05\" >> /var/log/test.log
    \n
  1. 验证索引状态
    2. \n
\n
# 方式 2：手动创建索引模板
\n
    \n
  1. 修改 filebeat 配置文件
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/filebeat.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/test.log
output.elasticsearch:
  hosts: [\"192.168.80.151:9200\",\"192.168.80.152:9200\",\"192.168.80.153:9200\"]
  index: \"test-log-%{[agent.version]}-%{+yyyy.MM.dd}\"      # 自定义索引名称
setup.ilm.enabled: false                 # 索引生命周期 ilm 功能默认开启，开启情况下索引名称只能为 .ds-filebeat-*
setup.template.name: \"test-log\"          # 定义模板名称
setup.template.pattern: \"test-log-*\"     # 定义模板的 \"匹配索引名称规则\"
# 8.x 必须配置如下内容，否则不会创建索引，而会创建对应的索引数据流
setup.template.enabled: false            # 关掉默认的模板配置
setup.template.overwrite: true           # 允许覆盖已存在的同名模板
    \n
  1. 手动创建索引的模板，然后设定主分片数据和副本分片数量
    2. \n
\n
PUT /_index_template/test-log         // 索引模板名称
{
  \"index_patterns\": [\"test-log-*\"],   // 模板匹配并关联哪些索引;
  \"template\": {
    \"settings\": {
      \"index\": {
        \"number_of_shards\": 3,
        \"number_of_replicas\": 1
      }
    }
  }
}
    \n
  1. \n
    验证索引模板
    \n
    2. \n
  2. \n
    删除此前的索引，然后重启服务，验证索引状态 (三分片，一副本)
    \n
    3. \n
\n
# 5、Filebeat 字段添加
\n
# 5.1 使用 tags 添加标签
\n
在 Filebeat 中，可以使用  tags  配置项为每条数据添加一个标签列表。例如：可以为访问日志添加  access_log  标签，为错误日志添加  error_log  标签。这些标签在后续的日志处理和分析阶段可以用于有效地标识和筛选数据。
\n
    \n
  1. 配置文件编写
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/conf.d/04-log-output-console.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths: /var/log/access.log
  tags: [\"system-access\"]            # 为输入日志添加标签
- type: log
  enabled: true
  paths: /var/log/error.log
  tags: [\"system-error\"]             # 为输入日志添加标签
output.console:
  pretty: true
  enabled: true
    \n
  1. 启动对应的 filebeat
    2. \n
\n
[root@web01 ~]# filebeat -e -c /etc/filebeat/conf.d/04-log-output-console.yml
    \n
  1. 追加日志内容
    2. \n
\n
[root@web01 ~]# echo test-access >> /var/log/access.log
[root@web01 ~]# echo test-error >> /var/log/error.log
    \n
  1. 验证对应的结果
    2. \n
\n\n
{
  \"@timestamp\": \"2025-07-27T07:22:52.136Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"log\": {
    \"file\": {
      \"path\": \"/var/log/access.log\"  <== 日志路径
    },
    \"offset\": 0
  },
  \"message\": \"test-access\",          <== 日志内容
  \"tags\": [
    \"system-access\"                  <== 日志标签
  ],
  \"input\": {
    \"type\": \"log\"                    <== 输入类型
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"agent\": {
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"b5cc1683-2c57-47dc-811d-b1627c94d9ad\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\"
  }
}
\n
{
  \"@timestamp\": \"2025-07-27T07:22:52.136Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"log\": {
    \"file\": {
      \"path\": \"/var/log/error.log\"
    },
    \"offset\": 0
  },
  \"message\": \"test-error\",
  \"tags\": [
    \"system-error\"
  ],
  \"input\": {
    \"type\": \"log\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"agent\": {
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"b5cc1683-2c57-47dc-811d-b1627c94d9ad\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\"
  }
}
# 5.2 使用 fields 添加字段
\n
在 Filebeat 中，可以使用  fields  配置项为每条数据添加自定义字段。
\n
    \n
  1. 配置文件编写
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/conf.d/05-log-output-console.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths: /var/log/access.log
  
  fields:
    namespace: system-access       # 自定义字段
  fields_under_root: true          # 若设置为 true 时，则将 fields 添加的自定义字段放在顶级字段中，默认为 false.
output.console:
  pretty: true
  console: true
    \n
  1. 启动对应的 filebeat
    2. \n
\n
[root@web01 ~]# filebeat -e -c /etc/filebeat/conf.d/05-log-output-console.yml
[root@web01 ~]# echo test-access >> /var/log/access.log
    \n
  1. 查看 Filebeat 输出的结果
    2. \n
\n
{
  \"@timestamp\": \"2025-07-27T07:45:22.216Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"namespace\": \"system-access\",    <== 自定义字段内容
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"agent\": {
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"4d716c9b-06eb-4a30-a511-e2d0ddf32f60\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\"
  },
  \"log\": {
    \"offset\": 24,
    \"file\": {
      \"path\": \"/var/log/access.log\"
    }
  },
  \"message\": \"test-access\",
  \"input\": {
    \"type\": \"log\"
  }
}
# 6、Filebeat 处理器
\n
# 6.1 处理器 Processors
\n
在 Filebeat 中，Processors 用于在数据发送到目标后端之前，可以对源数据执行预处理的组件。这些处理器可以执行各种数据转换任务，如修改、添加或删除字段等。常见的处理器包括：
\n\n
参考文档：https://www.elastic.co/guide/en/beats/filebeat/8.18/filtering-and-enhancing-data.html
\n
# 6.2 删除消息中的内容
\n
    \n
  1. 配置文件编写（过滤掉 DEBUG 开头的日志）
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/conf.d/06-log-processors-output-console.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths: /var/log/test.log         # 目标日志文件路径
processors:
  - drop_event:                    # 丢弃符合条件的日志事件
      when:
        regexp:
          message: \"^DEBUG\"        # 匹配规则: message 字段以 DEBUG 开头
output.console:
  pretty: true
  console: true
\n
排除 log.level: info 的日志配置
\n
processors:
  - drop_event:
      when:
        equals:
          log.level: \"info\"
\n
    \n
  1. 启动 filebeat 并写入测试内容
    2. \n
\n
[root@web01 ~]# filebeat -e -c /etc/filebeat/conf.d/06-log-processors-output-console.yml
# 向 test.log 写入 4 条内容
echo \"DEBUG: Hello\" >> /var/log/test.log
echo \"DEBUG: Hello\" >> /var/log/test.log
echo \"ADEBUG: Hello\" >> /var/log/test.log
echo \"BDEBUG: Hello\" >> /var/log/test.log
    \n
  1. 输出结果
    \n仅显示 ADEBUG 和 BDEBUG 开头的日志，DEBUG 开头的日志被成功过滤。
    2. \n
\n
{
  \"@timestamp\": \"2025-07-27T13:13:43.324Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"log\": {
    \"offset\": 14,
    \"file\": {
      \"path\": \"/var/log/test.log\"
    }
  },
  \"message\": \"ADEBUG: Hello\",            <==
  \"input\": {
    \"type\": \"log\"
  },
  \"agent\": {
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"6bd21962-ed78-431b-9aac-e866a0643dd4\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\"
  }
}
{
  \"@timestamp\": \"2025-07-27T13:19:38.415Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  },
  \"log\": {
    \"offset\": 54,
    \"file\": {
      \"path\": \"/var/log/test.log\"
    }
  },
  \"message\": \"BDEBUG: Hello\",            <==
  \"input\": {
    \"type\": \"log\"
  },
  \"agent\": {
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\",
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"6bd21962-ed78-431b-9aac-e866a0643dd4\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  }
}
# 6.3 删除无用字段
\n
    \n
  1. 配置文件编写
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/conf.d/07-log-processors-output-console.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths: /var/log/test.log             # 目标日志文件路径
processors:
  - drop_fields:                       # 移除指定字段的处理器
      fields: [\"ecs\",\"host\",\"input\"]   # 需要删除的字段列表
output.console:
  pretty: true
  console: true
    \n
  1. 启动 filebeat 并写入测试内容
    2. \n
\n
[root@web01 ~]# filebeat -e -c /etc/filebeat/conf.d/07-log-processors-output-console.yml
# 向 test.log 写入内容
echo \"Hello filebeat\" >> /var/log/test.log
    \n
  1. 检查对应的结果
    \n会发现 ecs、host、input 等字段都被删除了。
    2. \n
\n
{
  \"@timestamp\": \"2025-07-27T13:25:48.805Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"log\": {
    \"offset\": 68,
    \"file\": {
      \"path\": \"/var/log/test.log\"
    }
  },
  \"message\": \"Hello filebeat\",
  \"agent\": {
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"d73fa509-7ce0-4832-94cb-9f572ca69ada\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\",
    \"name\": \"es-node4.wang.org\",
    \"type\": \"filebeat\"
  }
}
# 6.4 重写源数据信息
\n
    \n
  1. 配置文件编写
    2. \n
\n
[root@web01 ~]# vim /etc/filebeat/conf.d/08-log-processors-output-console.yml
配置文件内容：
\n
filebeat.inputs:
- type: log
  enabled: true
  paths: /var/log/test.log            # 目标日志文件路径
processors:
  - rename:                # 字段重命名处理器
      fields:              # 需要重命名的字段列表
      - from: \"agent.name\" # 原字段名
        to: \"agent_name\"   # 新字段名 (顶级字段)
      - from: \"agent.type\"
        to: \"agent_type\"
      - from: \"log.file.path\"
        to: \"log_file_path\"
output.console:
  pretty: true
  console: true
    \n
  1. 启动 filebeat 并写入测试内容
    2. \n
\n
[root@web01 ~]# filebeat -e -c /etc/filebeat/conf.d/08-log-processors-output-console.yml
# 向 test.log 写入内容
echo \"Hello filebeat\" >> /var/log/test.log
    \n
  1. 检查 filebeat 输出的结果
    \n字段结构从嵌套变为平级，更易于后续处理。
    2. \n
\n
{
  \"@timestamp\": \"2025-07-28T15:26:45.256Z\",
  \"@metadata\": {
    \"beat\": \"filebeat\",
    \"type\": \"_doc\",
    \"version\": \"8.18.2\"
  },
  \"agent\": {
    \"version\": \"8.18.2\",
    \"ephemeral_id\": \"dea0a33b-419f-4900-9e2c-0a2fbace6092\",
    \"id\": \"db23f4d1-8f1e-48ac-a632-b7411303f161\"
  },
  \"ecs\": {
    \"version\": \"8.0.0\"
  },
  \"log\": {
    \"offset\": 83,
    \"file\": {}
  },
  \"input\": {
    \"type\": \"log\"
  },
  \"agent_name\": \"es-node4.wang.org\",        <==
  \"agent_type\": \"filebeat\",                 <==
  \"log_file_path\": \"/var/log/test.log\",     <==
  \"message\": \"Hello filebeat\",
  \"host\": {
    \"name\": \"es-node4.wang.org\"
  }
}
",
            "tags": [
                "ELK"
            ]
        },
        {
            "id": "http://blog.jaxxwang.cn/posts/3192084428.html",
            "url": "http://blog.jaxxwang.cn/posts/3192084428.html",
            "title": "03 Elasticsearch 集群",
            "date_published": "2025-12-09T16:00:00.000Z",
            "content_html": "
# 1、ElasticSearch 集群
\n
# 1.1 ES 集群优势
\n
Elasticsearch 集群是由多个节点组成的一个分布式系统。
\n使用 Elasticsearch 集群有以下几个优点：
\n
    \n
  1. 扩展性：Elasticsearch 集群将数据分布在多个节点，也就是可以使用更多的 CPU、内存、磁盘等。从而能够进行大规模的数据存储和处理工作。随着数据不断的增长，可以通过向集群添加更多的节点来应对。这样即使数据量达到 PB 级别，Elasticsearch 集群仍可以正常工作。
    \n场景说明：应用程序每天生成数百万条日志。单个服务器可能很快就会被数据量压垮。使用 Elasticsearch 集群后，就可以将数据均匀分布到多个节点上，这样每个节点只需要负责处理一部分的数据，从而实现整体的扩展性，以应对大规模的数据增长。
    2. \n
  2. 数据的容灾：Elasticsearch 集群通过在多个节点上存储数据的副本，来实现数据的容灾。意味着，如果某个节点发生故障，数据仍然可以从其他节点的副本中快速恢复，无需人工干预，从而减少了业务中断的风险。从而保证了整个集群的正常运行。
    3. \n
  3. 服务的高可用性：Elasticsearch 集群具有自动检测节点故障的能力。当某个节点发生故障时，集群会将故障节点上的任务快速分配给其他正常运行的节点。这样，即使某个节点发生故障，整个集群仍可以继续正常运行。（用户几乎感觉不到任何影响。）
    4. \n
\n
# 1.2 ES 如何组集群
\n
    \n
  1. \n
    单节点 ES，如下图所示；
    \n
    2. \n
  2. \n
    如果单节点出现问题，服务就不可用了，新增一个 ES 节点加入集群
    \n
    3. \n
\n
Elasticsearch 集群是由多个节点组成的，通过  cluster.name  定义集群名称，然后每个节点通过  node.name  来标识在集群中的名称。
\n cluster.name  相同则表示隶属于同一个集群。
\n
# 2、ES 集群环境部署
\n
# 2.0 环境地址规划
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
系统版本主机名称IP 地址
RockyLinux9 | Ubuntu2204kibana.wang.org192.168.80.150
RockyLinux9 | Ubuntu2204es-node1.wang.org192.168.80.151
RockyLinux9 | Ubuntu2204es-node2.wang.org192.168.80.152
RockyLinux9 | Ubuntu2204es-node3.wang.org192.168.80.153
\n
# 2.1 node1 集群节点配置
\n
# 1、安装 elasticSearch
[root@es-node1 ~]# yum install java-17-openjdk java-17-openjdk-devel -y
[root@es-node1 ~]# rpm -ivh elasticsearch-8.18.2-x86_64.rpm
[root@es-node1 ~]$ dpkg -i elasticsearch-8.18.2-amd64.deb
# 2、配置 elasticSearch
[root@es-node1 ~]# vim /etc/elasticsearch/elasticsearch.yml
cluster.name: es-cluster                # 集群名称
node.name: es-node1                     # 节点名称
path.data: /var/lib/elasticsearch       # 数据存储路径
path.logs: /var/log/elasticsearch       # 日志存储路径
# bootstrap.memory_lock: true           # 内存锁定，避免 es 使用 swap
network.host: 192.168.80.151            # 本机 IP 地址，监听在本地哪个地址上
http.port: 9200                         # 监听端口
discovery.seed_hosts: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]  # 集群主机列表
cluster.initial_master_nodes: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]  # 参与选举的主机，仅第一次启动集群时进行选举 [可以填写 node.name 的名称]
# 注释如下行重复配置 [重要]
# cluster.initial_master_nodes: [\"es-node1.wang.org\"]
# 关闭 Security
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# 3. 配置 JVM 内存
[root@es-node1 ~]# vim /etc/elasticsearch/jvm.options
-Xms512m
-Xmx512m
# 4. 重启 ES 服务
[root@es-node1 ~]# rm -rf /var/log/elasticsearch/*
[root@es-node1 ~]# systemctl restart elasticsearch
[root@es-node1 ~]# systemctl enable --now elasticsearch
# 2.2 node2 集群节点配置
\n
# 1、安装 elasticSearch
[root@es-node2 ~]# yum install java-17-openjdk java-17-openjdk-devel -y
[root@es-node2 ~]# rpm -ivh elasticsearch-8.18.2-x86_64.rpm
[root@es-node2 ~]$ dpkg -i elasticsearch-8.18.2-amd64.deb
# 2、配置 elasticSearch
[root@es-node2 ~]# vim /etc/elasticsearch/elasticsearch.yml
cluster.name: es-cluster
node.name: es-node2
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 192.168.80.152            # 本机 IP 地址
discovery.seed_hosts: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]
cluster.initial_master_nodes: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]
# 注释如下行重复配置 [重要]
# cluster.initial_master_nodes: [\"es-node2.wang.org\"]
# 关闭 Security
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# 3. 配置 JVM 内存
[root@es-node2 ~]# vim /etc/elasticsearch/jvm.options
-Xms512m
-Xmx512m
# 4. 重启 ES 服务
[root@es-node2 ~]# rm -rf /var/log/elasticsearch/*
[root@es-node2 ~]# systemctl restart elasticsearch
[root@es-node2 ~]# systemctl enable --now elasticsearch
# 2.3 node3 集群节点配置
\n
# 1、安装 elasticSearch
[root@es-node3 ~]# yum install java-17-openjdk java-17-openjdk-devel -y
[root@es-node3 ~]# rpm -ivh elasticsearch-8.18.2-x86_64.rpm
[root@es-node3 ~]$ dpkg -i elasticsearch-8.18.2-amd64.deb
# 2、配置 elasticSearch
[root@es-node3 ~]# vim /etc/elasticsearch/elasticsearch.yml
cluster.name: es-cluster
node.name: es-node3
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 192.168.80.153        # 本机 IP 地址
discovery.seed_hosts: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]
cluster.initial_master_nodes: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]
# 注释如下行重复配置 [重要]
# cluster.initial_master_nodes: [\"es-node3.wang.org\"]
# 关闭 Security
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# 3. 配置 JVM 内存
[root@es-node3 ~]# vim /etc/elasticsearch/jvm.options
-Xms512m
-Xmx512m
# 4. 重启 ES 服务
[root@es-node3 ~]# rm -rf /var/log/elasticsearch/*
[root@es-node3 ~]# systemctl restart elasticsearch
[root@es-node3 ~]# systemctl enable --now elasticsearch
# 3、ES 集群状态检测
\n
# 3.1 ES 集群指标状态
\n
Cluster Health  获取集群的健康状态，整个集群状态包括以下三种：
\n
    \n
  1. green：健康状态，指所有主副分片都正常分配
    2. \n
  2. yellow：所有主分片都正常分配，但是有副本分片未正常分配
    3. \n
  3. red：有主分片未分配，也就是索引不完备，写可能有问题。（但不代表不能读取数据）
    4. \n
\n
检查 ES 集群是否正常运行，可以通过 curl、Cerebro 两种方式。
\n
curl http://127.0.0.1:9200/_cat/health
curl http://127.0.0.1:9200/_cat/nodes?v
# 3.2 Curl 命令检查集群状态
\n
# 1、使用 curl 工具检查 ES 集群状态
[root@es-node3 ~]# curl http://192.168.80.151:9200/_cluster/health?pretty=true
{
  \"cluster_name\" : \"es-cluster\",
  \"status\" : \"green\",
  \"timed_out\" : false,
  \"number_of_nodes\" : 3,
  \"number_of_data_nodes\" : 3,
  \"active_primary_shards\" : 36,
  \"active_shards\" : 72,
  \"relocating_shards\" : 0,
  \"initializing_shards\" : 0,
  \"unassigned_shards\" : 0,
  \"unassigned_primary_shards\" : 0,
  \"delayed_unassigned_shards\" : 0,
  \"number_of_pending_tasks\" : 0,
  \"number_of_in_flight_fetch\" : 0,
  \"task_max_waiting_in_queue_millis\" : 0,
  \"active_shards_percent_as_number\" : 100.0
}
# 2、也可以编写脚本监控 ES 集群状态
curl -s http://192.168.80.151:9200/_cluster/health?pretty=true | grep \"status\" | awk -F '\"' '{print $4}'
# 输出: green
# 3.3 安装 Cerebro 检查集群状态
\n
cerebro 是可视化工具，用于检查 ES 集群状态。
\n
# RockyLinux9 部署 Cerebro
\n
# 1、安装 java, 它目前仅支持 java1.8 版本
# 并不支持较高的 java 版本，\"因此不要与 ES 安装在同一节点上\"
[root@kibana ~]# yum install java-1.8.0-openjdk java-1.8.0-openjdk-devel -y
# 2、安装 Cerebro
[root@kibana ~]# wget https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4-1.noarch.rpm
[root@kibana ~]# rpm -ivh cerebro-0.9.4-1.noarch.rpm
# 3、配置 Cerebro
[root@kibana ~]# vim /etc/cerebro/application.conf
data.path: \"/var/lib/cerebro/cerebro.db\"
# data.path = \"./cerebro.db\"
# 4、启动 Cerebro
[root@kibana ~]# systemctl start cerebro
# 查看端口
[root@kibana ~]# netstat -lntp
Proto Recv-Q Send-Q Local Address   Foreign Address     State       PID/Program name
tcp6       0      0 :::9000         :::*                LISTEN     504/java
# Ubuntu2204 部署 Cerebro
\n
# 可以将其安装在 Kibana 主机
# 依赖 JDK-11
[root@ubuntu2204 ~]# apt -y install openjdk-11-jdk
# 下载包，官方提供了 DEB 和 RPM 包
[root@ubuntu2204 ~]# wget https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro_0.9.4_all.deb
# 安装
[root@ubuntu2204 ~]# dpkg -i cerebro_0.9.4_all.deb
# 启动
[root@ubuntu2204 ~]# systemctl start cerebro.service
# 默认服务无法启动，端口无法打开
[root@ubuntu2204 ~]# ss -ntlp | grep 9000
# 默认无法启动，查看日志，可以看到以下提示，原因是默认 cerebro.db 文件所有目录没有权限导致
[root@ubuntu2204 ~]# journalctl -u cerebro
# 报错: Caused by: java.sql.SQLException: opening db: './cerebro.db': 权限不够
# 修改配置文件
[root@ubuntu2204 ~]# vim /etc/cerebro/application.conf
data.path: \"/var/lib/cerebro/cerebro.db\"  # 取消此行注释
# data.path = \"./cerebro.db\"              # 注释此行，默认路径是 /usr/share/cerebro/cerebro.db
# 此目录自动生成
[root@ubuntu2204 ~]# ll -d /var/lib/cerebro
drwxr-xr-x 2 cerebro cerebro 4096   4月 10     2021 /var/lib/cerebro/
# 重启服务
[root@ubuntu2204 ~]# systemctl restart cerebro.service
[root@ubuntu2204 ~]# systemctl enable --now cerebro.service
# 默认监听 9000 端口
[root@ubuntu2204 ~]# ss -ntlp | grep 9000
LISTEN   0   100   *:9000           *:*         users:((\"java\",pid=26333,fd=155))
# 访问下面链接地址
http://192.168.80.150:9000
# 访问 Cerebro 页面
\n
在  Node address  输入框中输入任意 ES 集群节点的地址： http://192.168.80.151:9200
\n
# 4、ES 集群节点类型
\n
ES 集群中节点类型介绍：
\n\n
# 4.1 Cluster State
\n
Cluster State  是用来存储 Elasticsearch 集群相关的元数据信息。它存储在每个节点上，主要包含以下信息：
\n\n
# 4.2 Master 角色
\n
    \n
  1. Elasticsearch 集群中只能有一个处于激活状态的 Master 节点。Master 节点负责管理和控制整个集群的操作；
    2. \n
  2. Master 节点负责维护集群状态（Cluster State）。当集群状态发生变化（例如，新增或删除索引、修改索引设置等）时，Master 节点会将更新后的集群状态同步给其他节点，以保持整个集群的状态一致性。
    3. \n
  3. Master 节点是通过选举产生的。集群中的节点可以设置  node.master: true  来允许它成为 Master 节点的候选者（默认为 true）。如果当前的 Master 节点失效或不可用时，集群会自动触发选举过程，从候选者中选出一个新的 Master 节点。
    4. \n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
版本角色配置
7.X 版本Master 角色: 
  node.master: true  
  node.data: false  
 Data 角色: 
  node.master: false  
  node.data: true  
 Coordinating 角色: 
  node.master: false  
  node.data: false
8.X 版本Master 角色: 
  node.roles: ["master","data"]  (既当 master, 又当 data) 
 Data 角色: 
  node.roles: ["data"]  
 Coordinating 角色: 
  node.roles: []
\n
# 4.3 Data 角色
\n
Data 节点是 Elasticsearch 集群中负责存储数据的节点。默认情况下，集群中的所有节点都是 Data 类型。
\n
    \n
  1. 可以通过设置  node.data: true （默认为 true）来保持节点作为 Data 节点。
    2. \n
  2. 当创建索引后，索引中的数据会被存储在一个或多个 Data 节点上。这些能够存储索引数据的节点被称为 Data 节点。Data 节点负责处理数据查询、聚合和搜索等操作，它们直接影响整个集群的性能和存储能力。
    3. \n
\n
通过合理分配和管理 Data 节点，可以提高 Elasticsearch 集群的数据处理能力、查询性能和存储容量。在实际应用中，需要根据业务需求和硬件资源来调整 Data 节点的数量和配置。
\n
# 4.4 Ingest 角色
\n
Ingest 节点是 Elasticsearch 集群中负责预处理文档的过程，它允许文档在被写入到 Elasticsearch 之前，对其进行处理、清洗、或转换。
\n
    \n
  1. 假设你有一个包含日志数据的 JSON 文档，其中包含一个时间戳字段，但格式不符合标准。我们就可以在文档被写入之前，使用 date 处理器来转换时间戳字段的格式。
    2. \n
  2. node.ingest: true  表示该节点可以对文档进行预处理操作。如果你希望某个节点不处理 Ingest 任务，可以设置为 false。
    3. \n
\n
# 4.5 Coordinating 角色
\n
处理请求的节点被称为 Coordinating 节点。Coordinating 节点是 Elasticsearch 集群中所有节点的默认角色，无法取消。
\n
    \n
  1. Coordinating 节点主要负责将请求路由到正确的节点。例如，创建索引的请求会被 Coordinating 节点路由到 Master 节点进行处理，而数据查询或写入的请求会被路由到相应的 Data 节点上。
    2. \n
  2. 当一个节点同时设置  node.master：false 、 node.data：false  时，该节点仅充当 Coordinating 路由节点的角色。
    3. \n
\n
# 4.6 角色设定示例
\n
    \n
  1. 如果希望节点只作为主节点
    # ES7.X
    node.master: true
    node.data: false
    # ES8.X
    node.roles: [\"master\", \"ingest\"]    # 只做 master, 不当 data
    2. \n
  2. 如果希望节点只作为数据节点
    # ES7.X
    node.master: false
    node.data: true
    # ES8.X
    node.roles: [\"data\", \"ingest\"]    # 只当 data, 不做 master
    3. \n
  3. 如果希望节点同时担任数据节点和主节点
    # ES7.X
    node.master: true
    node.data: true
    # ES8.X
    node.roles: [\"master\", \"data\", \"ingest\"]    # 同时担任 master data
    4. \n
  4. 如果希望节点不担任任何特定角色（不推荐）
    # ES7.X
    node.master: false
    node.data: false
    # ES8.X
    node.roles: []    # 不担任任何角色
    5. \n
\n
# 5. 案例演示
\n
# 修改 ES 配置
root@es-node1: vim /etc/elasticsearch/elasticsearch.yml
node.roles: [\"data\", \"ingest\"]    # 不做 master 节点 (默认每个节点都存在: master data ingest)
# 重启 ES 服务
root@es-node1: systemctl restart elasticsearch
# 5、ES 集群分片
\n
# 5.1 什么是分片
\n
分片是处理和存储 PB 级别数据的基础。在 Elasticsearch 中，分片是一种数据分区机制，它允许将一份完整的数据分散存储到集群的多个不同服务器上。而每个分片只是索引的一个部分，这使得它们可以独立进行存储和查询。
\n
在 Elasticsearch 中，分片又被分为了两种类型：
\n
    \n
  1. 主分片：主要负责存储数据。创建后主分片的数量是固定的（不允许修改）。
    2. \n
  2. 副本分片：每个主分片可以配置一个或多个副本分片，以增强数据的容错能力。副本分片从对应的主分片同步数据，确保在主分片出现问题时仍能提供服务。
    3. \n
\n
# 5.2 什么是副本分片
\n
副本分片主要用于提高数据的可用性，这样即使某个节点发生故障，系统依然可以自动从其他节点上的副本分片中恢复，并继续提供数据访问服务。
\n
如下图所示，node2 上是 oldwang_index 索引的一个完整副本数据。
\n
# 5.3 ES 集群如何增大容量
\n
    \n
  1. 如下 3 个节点的 ES 集群，创建了一个 oldwang_index 索引，同时指定了 3 个分片，和 1 个副本
    # 创建索引，设定主分片和副本分片
    PUT /oldwang_index
    {
        \"settings\": {
        \"index\": {
            \"number_of_shards\": 3,    # 主分片
            \"number_of_replicas\": 1   # 副本分配
        }
    }
    }
    # 动态修改副本分片
    PUT /oldwang_index/_settings
    {
        \"number_of_replicas\": 2    # 三节点，三分片。因此最多只需要两副本就完全够了.
    }
    2. \n
\n
问题：目前一共有 3 个 ES 节点，如果此时增加一个新节点 是否能提高 oldwang_index 索引数据容量？
\n答案：不能，因为 oldwang_index 只有 3 个分片，已经分布在 3 台节点上，那么新增的第四个节点对于 oldwang_index 而言是无法使用到的。所以也无法带来数据容量的提升。
\n
# 5.4 ES 集群如何增加读性能
\n
问题：目前一共有 3 个 ES 节点，如果增加副本数是否能提高 oldwang_index 索引的读性能？
\n答案：不能，因为新增的副本还是会分布在这 node1、node2、node3 这三个节点上的，还是使用了相同的资源，也就意味着有读请求来时，这些请求还是会分配到 node1、node2、node3 上进行处理、也就意味着，还是利用了相同的硬件资源，所以不会提升读性能。
\n
问题：如果需要增加读吞吐量性能，应该怎么来做？
\n答案：增加读吞吐量还是需要添加节点，比如在增加三个节点 node4、node5、node6 那么将原来的 R0、R1、R2 分别迁移至新增的三个节点上，当有读请求来时会被分配 node4、node5、node6，也就意味着有新的 CPU、内存、IO，这样就不会在占用 node1、node2、node3 的硬件资源，那么这个时候读吞吐量才会得到真正的提升。
\n
# 5.5 ES 副本与分片总结
\n
分片数和副本的设定非常重要，需要在集群部署前进行仔细规划：
\n
    \n
  1. 分片过小：可能导致在后续需要水平扩容时无法通过增加节点来实现，因为数据已经在现有节点上达到了分布的极限。
    2. \n
  2. 分片过大：可能会导致单个节点上分布过多的分片，从而造成资源的浪费。此外，过多的分片也会影响 ES 的查询性能。
    3. \n
\n
# 6、ES 集群故障转移
\n
# 6.1 什么是故障转移
\n
所谓故障转移指的是，当集群中有节点发生故障时，这个集群是如何进行自动修复的。
\nES 集群目前是由 3 个节点组成，此时集群状态是 green。
\n
# 6.2 模拟节点故障案例
\n
假设：node1 所在机器宕机导致服务终止，此时 ES 集群会如何处理；大体分为三个步骤：
\n
    \n
  1. \n
    重新选举
    \n
    2. \n
  2. \n
    主分片调整
    \n
    3. \n
  3. \n
    副本分片调整
    \n
    4. \n
  4. \n
    重新选举阶段：node2 和 node3 发现 node1 无法响应；一段时间后会发起 master 选举。此时集群状态变为 Red 状态，假定选择 node2 为 master 节点；
    \n
    5. \n
  5. \n
    主分片调整阶段：node2 发现主分片 P0 未分配，将 node3 上的 R0 提升为主分片。此时所有的主分片都正常分配，集群状态变为 Yellow 状态；
    \n
    6. \n
  6. \n
    副本分片调整阶段：node2 将 P0 和 P1 主分片 重新生成新的副本分片 R0、R1。此时集群状态变为 Green；
    \n
    7. \n
\n
# 7、ES 文档路由原理
\n
ES 文档分布式存储，当一个文档存储至 ES 集群时，存储的原理是什么样的？
\n如图所示，当我们想在一个集群保存文档时，Document1 是如何存储到分片 P1 的？选择 P1 的依据是什么？
\n
其实是有一个 文档到分片的映射算法，其目的是使所有文档均匀分布在所有的分片上。ES 既不使用随机算法，也不使用轮询算法，而是通过以下公式计算文档对应的分片：
\n
shard = hash(routing) % number_of_primary_shards\n
\n\n
注意：该算法与主分片数相关，一旦确定后便不能更改主分片。因为一旦修改主分片数量， shard  的计算结果就会完全不一样，会导致无法定位到原有数据。
\n
总结：ES 用  hash(routing) % 主分片数  来把文档分配到对应分片，确保分布均衡且可定位，因此主分片数不能改，否则找不到数据。
\n
# 7.1 文档的创建流程
\n
    \n
  1. 客户端发送请求：请求发送到任意节点（协调节点）。
    2. \n
  2. 路由计算：协调节点 根据文档 ID 计算分片号： shard = hash(document_id) % 主分片数量
    3. \n
  3. 定位主分片：找到对应的主分片所在节点。
    4. \n
  4. 主分片写入：写入内存 + translog，同时转发给副本分片。
    5. \n
  5. 副本写入：副本分片完成相同写入操作。
    6. \n
  6. 写入成功：所有副本确认后，最终返回成功响应给客户端。
    7. \n
\n
# 7.2 文档的读取流程
\n
    \n
  1. 客户端发起查询请求：发送到任意节点（协调节点）。
    2. \n
  2. 协调节点分发请求到所有分片：查询是并行的，包括主分片和副本分片中任选一个。
    3. \n
  3. 每个分片独立查询：每个分片返回自己的匹配结果（文档 + 分数等）。
    4. \n
  4. 协调节点合并结果：统一排序、分页等，生成最终结果。
    5. \n
  5. 返回客户端：查询结果发送回客户端。
    6. \n
\n
# 7.3 文档批量创建的流程
\n
（原文未补充内容）
\n
# 7.4 文档批量读取的流程
\n
（原文未补充内容）
\n
# 8、ES 集群节点扩展
\n
# 8.1 环境准备
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
系统版本主机名称IP 地址
RockyLinux9es-node4192.168.80.154
RockyLinux9es-node5192.168.80.155
\n
# 8.2 ES 扩展 Data 节点
\n
[root@node4 ~]# grep \"^[a-Z]\" /etc/elasticsearch/elasticsearch.yml
cluster.name: es-cluster            # 集群名称
node.name: es-node4                 # 节点名称
node.roles: [\"data\", \"ingest\"]      # ES8.x 配置 Data 节点，不参与 Master 选举
http.port: 9200
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 192.168.80.154        # 内网 IP 地址
# bootstrap.memory_lock: true
discovery.seed_hosts: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]
# Enable security features
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# ES7.X 配置方式
# node.data: true          # Data 节点
# node.master: false       # 不参与 Master 选举
[root@node4 ~]# systemctl restart elasticsearch
访问 CereBro 验证节点，路径： Nodes > Data 角色
\n
# 8.3 ES 扩展 Coordinating 节点
\n
[root@node5 ~]# grep \"^[a-Z]\" /etc/elasticsearch/elasticsearch.yml
cluster.name: es-cluster                # 集群名称
node.name: es-node5                     # 节点名称
node.roles: []                          # ES8 配置 Coordinating 节点
http.port: 9200
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
# bootstrap.memory_lock: true
network.host: 192.168.80.155             # 内网 IP 地址
discovery.seed_hosts: [\"192.168.80.151\", \"192.168.80.152\", \"192.168.80.153\"]
# Enable security features
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
# ES7.X 配置方式
# node.data: false     # 不参与 Data 节点
# node.master: false   # 不参与 Master 选举
[root@node5 ~]# systemctl restart elasticsearch
# 8.4 节点扩展检查
\n
通过 cerebro 检查集群扩展后的状态。
\n如果出现集群无法加入、或者加入集群被拒绝，尝试删除  /var/lib/elasticsearch  下的文件，然后重启 ES：
\n
[root@node5 ~]# rm -rf /var/lib/elasticsearch/*
[root@node5 ~]# systemctl restart elasticsearch
如果将 data 节点修改为 Coordinating 节点，需要清理数据，否则无法启动：
\n
# repurpose 重新调整
[root@node5 ~]# /usr/share/elasticsearch/bin/elasticsearch-node repurpose
------------------------------------------------------------------------
WARNING: Elasticsearch MUST be stopped before running this tool.
Found 1 indices (1 shards and 1 index meta data) to clean up
Use -v to see list of paths and indices affected
Node is being re-purposed as no-master and no-data. Clean-up of index data will be performed.
Do you want to proceed?
Confirm [y/N] y
Node successfully repurposed to no-master and no-data.
访问 CereBro 验证节点，路径： Nodes > Coordinating 角色
\n
# 9、ES 集群调优建议
\n
# 9.1 内核参数优化
\n
    \n
  1. 内核参数优化
    [root@node ~]# vim /etc/sysctl.conf
    fs.file-max=655360                        # 设定系统最大打开文件描述符数，建议修改为 655360 或者更高；
    vm.max_map_count = 262144                 # 用于限制一个进程可以拥有的虚拟内存大小，建议修改成 262144 或更高。
    net.core.somaxconn = 32768                # 设置系统允许的最大套接字监听（TCP SYN）队列长度；
    net.ipv4.tcp_tw_reuse = 1                 # 启用 TCP TIME-WAIT 状态的套接字重用。
    # net.ipv4.ip_local_port_range = 1000 65535 # 设置本地端口范围，即操作系统分配给本地套接字的端口号范围。
    net.ipv4.tcp_max_tw_buckets = 400000      # 表示操作系统允许 TIME_WAIT 数量的最大值，如果超过这个数字，TIME_WAIT 套接字将立刻被清除
    [root@node ~]# sysctl -p
    2. \n
  2. 调整用户最大进程数（nproc），调整进程最大打开的文件描述符（nofile）
    [root@node ~]# rm -f /etc/security/limits.d/20-nproc.conf     # 删除默认 nproc 设定文件
    [root@node ~]# vim /etc/security/limits.conf
    *                soft    core           unlimited
    *                hard    core           unlimited
    *                soft    nproc          1000000
    *                hard    nproc          1000000
    *                soft    nofile         1000000
    *                hard    nofile         1000000
    *                soft    memlock        32000
    *                hard    memlock        32000
    *                soft    msgqueue       8192000
    *                hard    msgqueue       8192000
    3. \n
\n
# 9.2 配置参数优化
\n
# 1. 启用内存锁定，避免 ES 使用 swap 交换分区，频繁的交换，会导致 IOPS 变高.
[root@es-node ~]# vim /etc/elasticsearch/elasticsearch.yml
bootstrap.memory_lock: true
# 2. 当 ES 配置内存锁定后，需要确保操作系统允许 Elasticsearch 进程锁定足够的内存.
[root@es-node ~]# sed -i '/\\[Service\\]/a LimitMEMLOCK=infinity' /usr/lib/systemd/system/elasticsearch.service
# 3. 重新启动 elasticSearch
[root@es-node ~]# systemctl daemon-reload
[root@es-node ~]# systemctl restart elasticsearch
# 9.3 JVM 参数优化
\n
# 9.3.1 基础原则
\n
要估算 JVM 内存配置，主要看两点：
\n\n
经验公式：1GB 内存 可以支持 48GB ~ 96GB 的数据量（通常按 1:48 来算最保险）
\n单个主分片大小最好控制在 30GB~50GB
\n
# 9.3.2 怎么估算内存和分片？
\n
第一步：算出实际需要存储的数据量
\n
实际存储量 = 总数据量 × (副本数 + 1)    // 因为副本也要占空间\n
\n
例如：总数据量 1TB + 副本数据 → 实际存储数据量 2TB
\n
第二步：算每个节点要存多少数据
\n
每节点存储 = 实际数据量 ÷ 节点数    // 再加上 20% 预留空间\n
\n
示例：实际存储量 2TB / 3 节点 + 20% 预留空间 → 每节点存储 850G
\n
第三步：算每个节点需要多少内存
\n
节点内存 ≈ 每节点存储量 ÷ 48（按1:48比例来算）\n
\n
示例：每节点存储量 850G ÷ 48 → 节点内存 17 G
\n
第四步：算分片数量（用于 ES）
\n
主分片数量 = 总数据量 ÷ 30GB（建议一个分片控制在 30GB 左右）\n总分片数 = 主分片数 × (副本数 + 1)\n
\n
示例：主分片数量 ≈ 33 → 总分片数 ≈ 66
\n
# 9.3.3 两个简单例子
\n
示例 1：1TB 数据，3 个节点，1 个副本
\n
    \n
  1. 实际要存：1TB × (1 + 1) = 2 TB
    2. \n
  2. 每节点：2TB ÷ 3 ≈ 700GB → 加 20% ≈ 850GB    // 单节点实际存储
    3. \n
  3. 内存需求：850GB ÷ 48 ≈ 17GB                // 单节点建议内存 17 * 2 ≈ 34G
    4. \n
  4. JVM 配置：每个节点内存 17GB
    5. \n
  5. 分片数量：1TB ÷ 30GB ≈ 33 个主分片
    6. \n
  6. 总分片数 = 33 × 2 = 66 个
    7. \n
  7. 单个索引分片数
    \n a. 每日数据量 ÷ 30G = （总数据量 ÷ 保留天数）÷ 30G
    \nb. 100 ÷ 30G = 3 分片            // 每天 100G 日志
    \n c. 1024 ÷ 30G = 33 分片      // 每天 1024G 日志
    8. \n
\n
示例 2：2TB 数据，3 个节点，1 个副本
\n
    \n
  1. 实际要存：2TB × 2 = 4TB
    2. \n
  2. 每节点：4TB ÷ 3 ≈ 1.4TB → 加 20% ≈ 1.7TB            // 单节点存储
    3. \n
  3. 内存需求：1.7TB ÷ 48 ≈ 35GB → 超过建议上限（31GB）→ ⚠️ 不够用，得加节点！
    4. \n
\n
增加到 4 个节点
\n
    \n
  1. 每节点：4TB ÷ 4 = 1TB → 加 20% ≈ 1.2TB
    2. \n
  2. 内存需求：1.2TB ÷ 48 ≈ 25GB → 合理！
    3. \n
  3. 分片数量：2TB ÷ 30GB = 60 个主分片 → 总分片数 = 60 × 2 = 120 个
    4. \n
\n
结论：用 4 个节点，内存控制在 31GB 以内，刚刚好！
\n
# 9.3.4 生产环境建议
\n\n
✅ 结论
\n\n
\n",
            "tags": [
                "ELK"
            ]
        }
    ]
}