刚安装监控时，我把“软件启动了”和“已经监控到网站”混在一起。后来把每一段链路拆开，才明白 Node Exporter、Prometheus 和 Grafana 各自负责什么。
一次采集发生了什么
Node Exporter 读取 Linux 的 CPU、内存、磁盘和网络状态，在 HTTP /metrics 接口输出指标。Prometheus 按配置主动请求这个接口，保存成带时间戳的数据。Grafana 再向 Prometheus 查询并画图。
这里主要是 Prometheus 来拉取，并非 Node Exporter 主动把所有数据推送过去。Prometheus 也有自己的 /metrics，用来观察自身采集、查询和存储情况，所以它既能采别人，也能采自己。
本站这些组件部署在同一台服务器，内部采集使用回环地址，不需要把管理端口开放到公网。
两个基础任务如何读
下面是配置结构示意，合并进现有文件时不要重复写顶层 scrape_configs：
scrape_configs:
- job_name: node
static_configs:
- targets: ['127.0.0.1:9100']
- job_name: prometheus
static_configs:
- targets: ['127.0.0.1:9090']job_name 是任务标签，targets 是采集端点。默认读取 /metrics。主配置在 /etc/prometheus/prometheus.yml，实际启动参数可用 systemctl cat prometheus 查看。配置只写在某处，却没有被启动参数引用，是排查时很容易漏掉的问题。
从 UP 开始，不要直接看漂亮看板
up{job="node"}返回 1 表示最近一次抓取成功，0 表示抓取失败。完全没有结果还可能是任务不存在、标签写错或时间范围不合适，不能简单当成数值为零。
再查内存：
100 * (1 - node_memory_MemAvailable_bytes{job="node"} / node_memory_MemTotal_bytes{job="node"})MemAvailable 估计还能给程序使用的内存。Linux 会用空闲内存做缓存，所以仅凭 MemFree 小就判断内存耗尽，容易误判。
Node Exporter 不会自动监控所有软件
主机资源正常不代表 MySQL 能连接，也不代表网页返回成功。本站后来分别增加了 MySQL、Nginx 和 Blackbox Exporter，让数据库、Web 连接状态、HTTPS 探测有各自的指标来源。导入仪表盘也不会自动安装这些采集器。
配置变更的检查顺序
promtool check config /etc/prometheus/prometheus.yml
systemctl kill --kill-who=main --signal=HUP prometheus第一条成功后才执行第二条；HUP 请求重新加载配置。随后检查 Targets 和实际查询结果。出现无数据时，依次查 exporter 服务、/metrics 输出、Targets 错误、指标标签，最后检查 Grafana。这样每一步都能回答一个具体问题。
指标缺失需要单独处理
up==0 只覆盖配置中仍存在但抓取失败的目标。目标被误删、标签改名时可能没有对应时间序列，需要按预期目标设计 absent 或其他缺失检查。不要给所有业务套一个通用表达式；先在查询页验证正常值、失败值、无数据三种情况，再为规则编写测试。全机停止时，同机 Prometheus 无法继续通知。
内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。
评论 (0)