做监控这块，绕不开这套组合：Prometheus + Grafana。从最开始服务器上只有一份脚本定时跑df和free，到后来容器化、微服务化之后指标铺天盖地涌过来，我才真正理解为什么 Prometheus 成了云原生监控的事实标准，也为什么大家偏偏选中 Grafana 来做展示层。这篇文章把这套环境从零搭建到告警联动的完整过程写下来，包含我实操下来踩过的坑，适合刚接触监控、准备在公司内网搭一套基础监控体系的运维和开发同学参考。
这套组合能做的事很清楚：Prometheus 负责拉取和存储时序指标，Grafana 负责把指标变成看得懂的图表和看板，再配上 Alertmanager 把异常变成电话、短信、钉钉、企业微信里的告警。整个链路开源、免费、组件少、文档多，二三十台机器的小团队能用，上万节点的集群也能通过联邦、分片和 Thanos 之类的方案撑住，这也是它相比 Zabbix、Open-Falcon 这些老牌监控最大的优势。
1. 监控选型：为什么最终是 Prometheus + Grafana 这套组合
1.1 云原生时代，Pull 模型才是主流
Prometheus 核心的设计思路是 Pull 模型，也就是由 Prometheus server 主动去各个目标机器的 HTTP 接口上抓取指标。刚开始用的时候我跟很多人一样有疑问：Zabbix 那种 Agent 主动上报数据的 Push 模型不是更省事吗？机器只要装个 Agent 就往服务端推数据，服务端不用知道目标在哪里。
实际跑起来才明白 Pull 模型的好处。第一，服务端能准确知道目标是否存活，up == 0这个指标直接就是最天然的存活探针，Push 模型下 Agent 挂了服务端根本不知道。第二， Pull 模型天然适合 Prometheus 配套的服务发现机制，Kubernetes 里 Pod 的 IP 是动态变化的，靠配置文件维护目标列表根本不可行，Prometheus 可以直接从 Kubernetes API 里动态发现 Pod 和 Service，自动开始抓取。第三，抓取频率由服务端统一控制，避免成千上万个 Agent 同时上报把服务端打爆。
这套设计放到今天云原生的场景下依然合理，只要能暴露一个符合 Prometheus 文本格式的 HTTP 接口，就能被纳管进来，新服务接入监控的成本几乎为零。
1.2 时序数据模型与标签设计是灵魂
Prometheus 的数据模型乍一看很简单，一条时序数据由 metric 名称、一组 label 键值对和一个 float 数值组成，比如http_requests_total{method="POST", code="500"} 1024。但恰恰是这套标签机制让它的查询能力远超传统监控。
我在教会团队用 PromQL 时总喜欢用一个比喻：如果把每台机器的 CPU 使用率比作一本书，metric 名称是书名，标签就是目录索引。你要查所有机器的 CPU，直接100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)，一个表达式就能把几十台机器的 CPU 汇总曲线画出来。想在查询结果里按机器、按环境、按业务模块拆分，全凭标签怎么设计。
这也引出一个非常重要的经验：标签命名一开始就要想清楚。我在生产环境吃过亏，一开始没有规范标签，不同 exporter 输出的 label 命名五花八门，有的叫host有的叫node有的叫instance，导致后面的 PromQL 表达式没法复用，看板拆了又拆。建议在团队内约定好统一的标签规范，比如env（环境）、app（应用）、instance（实例地址），所有接入监控的服务都必须遵守，这会让你后续写告警规则和看板的时候省下大量时间。
1.3 Grafana 为什么能脱颖而出
Prometheus 自带的 UI 只适合做简单查询和调试，离“可视化平台”还有不少距离。Grafana 的定位就是纯展示层，它不关心数据从哪来，只要数据源支持，就能画图。一个 Grafana 实例可以同时接 Prometheus、MySQL、Elasticsearch、Loki、Zabbix 等多个数据源，做统一的可视化入口。
Grafana 的社区生态是它最大的护城河。官方和社区贡献了海量现成的 Dashboard 模板，ID 一填、数据源一选，几分钟就能复制一套专业看板。我到现在还记得第一次导入 node_exporter full 模板时的震撼，相当于一个资深团队帮你把几百个常用指标都画好了图，排列、单位、告警阈值全都调好了。这种“站在巨人肩膀上”的快感，是自研监控系统永远给不了的。
2. 二进制部署：Prometheus server 与 Grafana 的落地全过程
2.1 下载与版本选择
部署方式我推荐先用二进制，不急着上容器。二进制部署的整个链路清晰，配置文件、数据目录、进程管理都是显式的，出了问题好排查，对理解 Prometheus 的运行机制更有帮助。等跑熟了再迁移到 Docker 或 Kubernetes 完全来得及。
下载地址就是 Prometheus 官网的 download 页，挑 amd64 的 linux 二进制包就行。版本选择上我的建议是不要追新也不要用太老的，Prometheus 目前 2.x 系列的稳定版本都可用，选最近半年的 release 足够。Grafana 同样从官网下载，选 OSS 版本即可，企业版的一些功能用不到。
cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz tar xvf prometheus-2.53.0.linux-amd64.tar.gz mv prometheus-2.53.0.linux-amd64 prometheusGrafana 用 RPM 包安装更省事，一条命令搞定，自带 systemd 服务文件：
wget https://dl.grafana.com/oss/release/grafana-11.1.0-1.x86_64.rpm yum localinstall -y grafana-11.1.0-1.x86_64.rpm systemctl enable --now grafana-server如果你手头网络环境下载 GitHub 资源很慢，可以去国内的一些镜像站找 tar 包，速度快很多。这是我实际部署时节省时间很重要的一步。
2.2 Prometheus 核心配置与 systemd 管理
Prometheus 的主配置文件叫prometheus.yml，默认自带一份示例配置，定义了抓取自身的 job。这是我搭建时用的最小可用配置：
global: scrape_interval: 15s # 多久抓取一次指标 evaluation_interval: 15s # 多久计算一次告警规则 alerting: alertmanagers: - static_configs: - targets: - localhost:9093 rule_files: - "/etc/prometheus/rules/*.yml" scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "linux-node" static_configs: - targets: ["192.168.1.101:9100"]这里有个新手容易忽略的点：scrape_interval直接决定了数据精度和存储量。15 秒是推荐的默认值，如果你对某些关键业务指标需要更精细的数据，可以单独在 job 里覆盖这个参数，但代价是存储占用上涨。我曾经把一批 job 统一改成 5 秒抓取，一个月后磁盘差点被时序数据塞满，后来用rate()函数时才意识到，15 秒的数据对于绝大多数监控场景完全够用，没必要为了“更精细”盲目提高采集频率。
配置完成后用 systemd 托管：
cat > /etc/systemd/system/prometheus.service <<'EOF' [Unit] Description=Prometheus After=network.target [Service] User=prometheus Group=prometheus ExecStart=/opt/prometheus/prometheus \ --config.file=/opt/prometheus/prometheus.yml \ --storage.tsdb.path=/data/prometheus \ --storage.tsdb.retention.time=30d Restart=on-failure [Install] WantedBy=multi-user.target EOF注意--storage.tsdb.retention.time这个参数，它决定数据保留多久。我之前遇到过一个诡异现象：数据明明还在，但查询时间范围一拉长就提示没有数据，后来才发现是保留时间设置太短，旧的时序数据已经被自动清理掉了。按 30 天来设是比较常规的选择。
2.3 Prometheus 默认端口与首次验证
装好之后 Prometheus 的默认端口是 9090，Grafana 是 3000。启动后访问http://<服务器IP>:9090，你会看到 Prometheus 自带的基础查询界面。在这里可以执行 PromQL 查询，也可以到 Status -> Targets 页面里查看所有抓取目标的状态，是 UP 还是 DOWN，抓取有没有报错。这一步是整个监控体系是否正常工作的第一道检查。
如果 Targets 里某些目标显示 DOWN，不要慌，先看它的“Error”字段给出的提示。常见的无非就是网络不通、端口没开、exporter 没起来、抓取路径不对这么几类。排查顺序从下往上：先 curl 一下目标的 /metrics 接口看看通不通，通了再回 Prometheus 里看配置有没有写错，基本都能快速定位。
3. 数据采集：理解指标抓取链路与关键配置细节
3.1 用 node_exporter 采集主机指标
Prometheus 本身只负责抓取和存储，具体采集什么指标取决于目标机器上跑着什么样的 exporter。对 Linux 主机来说，最常用的就是 node_exporter，它暴露的/metrics接口里有 CPU、内存、磁盘、网络、文件系统等几百个指标。
下载和启动 node_exporter 很简单，运行后默认监听在 9100 端口：
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz cd node_exporter-1.8.2.linux-amd64 nohup ./node_exporter --web.listen-address=:9100 &启动后浏览器直接访问http://<机器IP>:9100/metrics，你会看到类似下面这种格式的输出：
# 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"} 2.467321e+06 node_cpu_seconds_total{cpu="0",mode="system"} 1.234567e+04这种格式就是 Prometheus 规定的文本暴露格式，所有的 exporter 都是遵循这个标准在输出数据。理解了这个，你以后看任何 exporter 的指标都不会发怵，无非就是 HELP 解释指标含义、TYPE 声明指标类型、然后一行行的具体数据。在 9100 端口能 curl 通之后，再去 Prometheus 配置文件里把该机器的 IP 加进 scrape_configs，重启 Prometheus，一个主机的监控就纳管进来了。
3.2 Counter、Gauge、Histogram：指标类型的实际意义
Prometheus 的指标类型里有几个基础概念必须在动手前弄明白：Counter、Gauge、Histogram 和 Summary。我在带新人时发现，90% 的 PromQL 写不出来，都是因为没理解这几种类型的差异。
Counter 是累计计数器，只增不减，比如请求总数http_requests_total、开机时长node_boot_time_seconds。这类指标直接用没有意义，因为它会一直涨，必须配合rate()或increase()来看变化速率。Gauge 是仪表盘式的数值，可增可减，比如当前内存使用量、在线连接数，这类指标直接查询就能反映当前状态。Histogram 和 Summary 用于统计分布，比如请求延迟的百分位数，在监控里常见的histogram_quantile(0.99, ...)就是从 Histogram 计算 P99 延迟。
实际排障时，Counter 配合rate()是最常用的组合，比如排查某个 API 是否出现大量 5xx，就查sum(rate(http_requests_total{code=~"5.."}[5m])) by (service)。这里[5m]的意思是取过去 5 分钟的增量速率，窗口大小选得合适，曲线才会平滑且及时反映波动。
3.3 Prometheus 如何从 otel-collector 收数：两种路径都要懂
这里分享一个最近社区问得很多的问题：Prometheus 如何从 OpenTelemetry Collector 收取数据。很多公司已经在用 OTel 做统一的可观测性数据采集，这时候就得清楚 Collector 跟 Prometheus 之间是怎么衔接的。
第一种路径是把 Prometheus 的数据通过prometheusremotewriteexporter 发给远端 Prometheus，也就是在 OTel Collector 的配置里配置 exporter 为prometheusremotewrite，Prometheus 这边启用--web.enable-remote-write-receiver参数接收。这么做的好处是可以把 OTel 收集到的指标统一汇到 Prometheus 里存储和查询。
第二种路径更常见也更好理解：OTel Collector 可以直接配置一个prometheus receiver，让 Collector 自己主动抓取多个 Prometheus 格式的目标，然后 Collector 再作为 Prometheus 的抓取目标，这样 Prometheus 只需要面对 Collector 这一个目标，也能实现指标中转和合并。这也是 k8s 环境里最常见的部署形态，Collector 以 DaemonSet 方式跑在每台节点上，Prometheus 统一抓 Collector 暴露的/metrics接口。
如果你是在已有的 Prometheus 体系里引入 OTel，我更推荐先把 OTel Collector 当转发层，逐步把应用接入 OTel SDK，而不是推倒重来。
4. Grafana 可视化：从数据源接入到自制监控面板
4.1 添加 Prometheus 数据源
Grafana 装好之后，默认监听在 3000 端口，首次访问会让你设置管理员账号密码。登录后第一步就是添加数据源，路径是 Configuration -> Data Sources -> Add data source，找到 Prometheus 那一项，填上 Prometheus 的地址（比如http://localhost:9090），点击 Save & Test 会提示连接成功。
这里有一个容易忽略的细节：Grafana 和 Prometheus 如果不在同一台机器上，填写的地址一定得是 Grafana 服务器能访问到的地址。我有一次在容器里跑 Grafana，Prometheus 在宿主机上，结果填localhost:9090连不上，因为容器里的 localhost 指向容器自己。改成宿主机的内网 IP 之后问题就解决了。这种网络命名空间的问题在容器化部署里特别容易踩，先确认网络可通再排查配置。
4.2 导入现成 Dashboard 与理解 ID 用法
Grafana 能这么快复制一套专业看板，全靠 Dashboard 市场。在左侧菜单找到 Dashboards -> Import，输入模板 ID 就能加载。监控 Linux 主机最常用的模板 ID 是 1860，对应 node_exporter full 模板，里面包含了几百张图，覆盖 CPU 各核心使用率、内存各区域使用率、磁盘 IO、网络流量、文件系统空间等。除了 1860，还有 8919（Node Exporter for Prometheus Dashboard）和 11074（Linux hosts）等，挑一个你看着顺眼的即可。
导入时需要注意，有的模板会要求你选数据源，选对对应的 Prometheus 数据源就行。导入完成后你大概率会发现有些图是空的，这通常是模板里查询语句用了跟你的环境不匹配的标签导致的，比如模板里用了job="node_exporter"而你的 job 名是job="linux-node"。解决办法不是改模板，而是学会在 Grafana 面板里自己改 PromQL。
4.3 自制一个面板：PromQL 在 Grafana 中的实战
我从不用现成模板一导入就完事，更推荐在它的基础上改，这样你能真正理解每个图背后的查询逻辑。以“CPU 使用率趋势图”为例，在 Dashboard 里新建 Panel，选择 Prometheus 数据源，查询语句写：
100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)这个表达式的思路是：CPU 空闲率取 5 分钟平均，再用 100 减去它就得 CPU 使用率。avg后面不加by，就是把所有 CPU 核心聚合到一起。如果你按核数查看，去掉avg改成sum by (cpu)就能看到每个核的曲线。
Grafana 里还有一个非常值得学的功能：变量（Variables）。你可以定义一个变量叫instance，值来自查询label_values(node_cpu_seconds_total, instance)，这样面板顶部会多一个下拉框，可以切换查看不同机器的 CPU 曲线。这个用法一旦掌握，你的看板就从死板的固定查询变成了交互式工具，团队里的其他同学用起来会非常顺手。
顺带一提，热搜词里有个“grafana sql”，其实说的是 Grafana 还能接 MySQL、PostgreSQL 这类 SQL 数据源，查询时可以直接写 SQL。但注意 Prometheus 是时序数据库，查询语言是 PromQL 不是 SQL，两者的使用场景完全不同，不要试图在 Prometheus 上跑 SQL。Grafana 支持 SQL 数据源的主要意义是把你业务数据库里的指标跟监控指标放到同一张看板上，做全局视野。
4.4 Grafana 图表动态刷新与告警触达
图表的刷新频率在 Dashboard 右上角的 refresh 选项里控制，默认是关闭的，需要手动刷新才能看到最新数据。我建议在内部监控大屏上设为 30 秒或 1 分钟自动刷新，太频繁没有意义且增加 Prometheus 查询压力。另外，每个 Panel 还可以设置阈值线，比如把 CPU 使用率 80% 设为黄色阈值、90% 设为红色阈值，这样告警发生时扫一眼大屏就能直观看到是哪个指标越界了。
5. 告警体系：告警规则、Alertmanager 与通知渠道的联动
5.1 Prometheus 告警规则语法详解
光有图表不叫监控，指标异常时能主动通知到人，这套系统才算闭环。Prometheus 的告警功能分两步：第一步由 Prometheus 根据你配置的告警规则计算是否触发，第二步由 Alertmanager 负责把触发的告警去重、分组、抑制之后发送到各个通知渠道。
告警规则文件放在 Prometheus 的rule_files指向的目录里，格式是 YAML。下面是一组非常基础但完整可用的规则：
groups: - name: host_alerts rules: - alert: InstanceDown expr: up == 0 for: 1m labels: severity: critical annotations: summary: "Instance {{ $labels.instance }} down" description: "{{ $labels.instance }} 已停止被 Prometheus 抓取超过 1 分钟" - alert: HighCPUUsage expr: 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) > 85 for: 5m labels: severity: warning annotations: summary: "{{ $labels.instance }} CPU 使用率过高" description: "实例 {{ $labels.instance }} CPU 使用率超过 85%，持续 5 分钟"这里expr是触发条件，for是持续时间。for参数很多人会忽略它的价值，但它在生产环境中是避免告警风暴的第一道过滤器。想象一下某个服务做发布，瞬间 CPU 拉高一下又回落，如果没有for: 5m，每次波动都会触发告警，值班的人会被垃圾告警淹没。5 分钟持续确认之后再告警，噪音少得多。我落地告警时给团队定了个默认规范：warning 级别至少持续 5 分钟，critical 级别至少持续 1 分钟，需要调整的方案走评审。
5.2 Alertmanager 配置：分组、抑制与路由分发
Alertmanager 的配置文件alertmanager.yml主要包含 route（路由）、receivers（接收者）、inhibit_rules（抑制规则）三大部分。下面是一个可以用起来的配置：
route: group_by: ["alertname", "instance"] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: "default" routes: - matchers: - severity = "critical" receiver: "critical-webhook" receivers: - name: "default" webhook_configs: - url: "http://localhost:8888/prometheus/notice" send_resolved: true - name: "critical-webhook" webhook_configs: - url: "http://localhost:8888/prometheus/critical" send_resolved: true这里有几个参数要做说明。group_by决定哪些告警会被合并成一条通知，比如同一台机器同时出现多个磁盘相关告警，就会合并到一条消息里，避免轰炸式通知。group_wait是组内第一条告警等待多久再发，给后续相关告警时间聚进来。repeat_interval是同样的告警隔多久再发一次，默认 4 小时合理，不会因为一个问题反复打扰。很多团队上来就是默认配置，结果线上一个问题把值班群刷爆，后来限制 repeat_interval 才好起来。
国内团队最常用的通知渠道一般是企业微信 webhook 和钉钉 webhook，也有通过 PrometheusAlert 这类中间件把告警转发到飞书、短信、邮件的。webhook 的优势是接入成本低，Alertmanager 只要配置一个 URL 即可，不需要额外开发。
告警恢复通知也很重要。Alertmanager 里每个 receiver 都可以开启send_resolved: true，告警恢复时会收到一条“恢复”消息。这能让你确认问题已经闭环，不用一直悬着心。很多人配了告警才发现恢复通知没开，结果每次都要手动去 Prometheus 里确认当前是否还在告警，这体验差太多了。
5.3 告警规则自测与常见误报优化
配置完告警规则后，强烈建议在 Prometheus 的 Alerts 页面检查每条规则当前的状态：Inactive（未触发）、Pending（已超过条件还在等for时间）、Firing（已触发并发送通知）。Pending 到 Firing 的转换过程是理解告警系统很有价值的一幕，你可以在页面里看到规则已经满足条件，但还在等待持续时间的确认。
误报是告警系统最大的敌人。我遇到过的误报五花八门，最典型的是磁盘空间告警，明明临时文件清理之后空间已恢复，但因为for时间设置太短，清理动作稍慢就触发了告警。后面对这种临时性指标加了更长的for时间和更宽的阈值，误报率降了一大截。优化告警没有一次性到位的方法，只能靠业务实际情况不断调整阈值，关键是在早期宁可漏报也不误报——误报多了，值班的人会开始无视告警，到真正出事的时候就没人看了。
6. 升级与排错实战：几个高频问题的根因与处理方法
6.1 修复 Grafana 升级后数据源报错
热搜词里有一条非常具体的报错信息：grafana failed to upgrade legacy queries datasource im7_otuvz was not found。这个错误我身边已经有好几个同事遇到过了，几乎都发生在 Grafana 大版本升级之后，尤其从 8.x 升到 9.x、10.x 时高发。
根因是 Grafana 的数据源引用机制在新版本里变严格了。老版本的 Dashboard JSON 里，查询面板直接引用数据源名称，升级后 Grafana 要求通过数据源 UID 来引用，而旧 JSON 里的 uid 字段是空的或变成了类似im7_otuvz这种临时标识，升级程序又找不到对应的新数据源，就会报这个错。
处理办法分两步。第一步，打开报错所在的 Dashboard，进入设置，找到 JSON Model，检查每个 Panel 的 datasource 字段。正常情况下应该是这个结构：
"datasource": { "type": "prometheus", "uid": "你的prometheus数据源uid" }如果看到的是"uid": "im7_otuvz"或者直接是字符串类型的老格式，就需要改成实际存在的 uid。如何找到实际 uid？进到 Connections -> Data sources，点开你的 Prometheus 数据源，看地址栏 URL 里的参数，或者在数据源设置页面里的“UID”字段直接复制。把 JSON Model 里所有错误的 uid 替换成正确的，保存后验证一下。如果 Dashboard 太复杂， JSON 改起来容易出错，更省力的方式是在 Grafana 里新建一个 Dashboard，手动加一次面板并选择正确的数据源，再对比看新旧 JSON 的差异，基本就能定位。
另一个更简单的预防手段：升级 Grafana 大版本前，先导出所有 Dashboard 的 JSON 备份，升级后如果报错，用备份 JSON 里的 uid 批量替换即可。经历过一次你就知道了，版本升级前做备份永远是对的。
6.2 Prometheus 内存与磁盘占用过高
Prometheus 内存长期居高不下是新手最容易忽略的问题，因为它默认就不是省内存的主。内存占用的核心来源是时序数据的 WAL（预写日志）和 Head Block，还在内存里的最近数据快照。如果机器内存只有 2G 还要跑 Prometheus 和 Grafana，我建议先加内存，或者把 Prometheus 的--storage.tsdb.min-block-duration和--storage.tsdb.max-block-duration调大，减少内存里未落盘的块数量。
磁盘占用则主要取决于抓取指标的总量、抓取频率和保留时间。处理方案有几个方向：减少采集频率、缩短保留时间、优化指标标签基数。标签基数过高是时序数据膨胀的元凶，比如请求路径这种高基数标签放进指标里，会产生成千上万条序列，磁盘上很快就会堆出几十 G 的数据。在业务接入监控时就要约束 label 的设计，不要把所有希望都寄托在“反正 Prometheus 能存”。
6.3 容器环境与二进制环境如何做选型
前面的部署讲解我全程用二进制演示，但 Kafka、MySQL 等基础设施如果已经容器化了，在 Kubernetes 里跑 Prometheus 就是最优选择。最成熟的方案是直接装 kube-prometheus-stack，它把 Prometheus、Alertmanager、Grafana、各类 exporter 打包成 Helm chart，一条命令就能拉起一整套监控体系。
但即便在容器化环境，理解二进制部署过程的价值依然存在。Helm chart 只是把配置包装成了模板，排障时你依然需要知道values.yaml里的prometheus.yml配置段对应你手写配置的哪个部分，告警规则的语法更是完全一致。先学会底层原理，再上封装，才是稳妥的学习路径。
6.4 一次完整的告警排查链路复盘
最后用一个我实际排查过的案例收尾，展示告警系统是怎么帮你定位问题的。某天凌晨 2 点，Alertmanager 推送了一条 NodeUnreachable 告警，说某台业务机器已无法抓取。最初大家以为是网络抖动，观察 10 分钟没有恢复，登录那台机器发现 SSH 正常，但curl localhost:9100/metrics没反应。
我的排查顺序是：先看 node_exporter 进程还在不在，发现进程意外退出了。再看 systemd 日志，journalctl -u node_exporter发现缺少权限无法读取某个磁盘的健康信息导致 panic。这个过程，Prometheus 的告警只是起到了“提醒我出事了”的作用，真正的定位靠的还是登录现场排查。但也正是告警让这台机器的问题在第一时间被发现，否则可能要等业务方反馈接口超时才知道机器出了状况。
这类基础组件进程意外退出的问题，根因往往在系统更新、权限变更或磁盘故障上。处理完恢复进程后，我给那台机器的 node_exporter 服务加了开机自启，并设置了简单的进程守护，之后就没再复现过。监控体系的建设从来不是一次部署就结束，而是一轮一轮的完善。
我个人实操下来最大的体会是：监控系统的价值不在于装了多少组件、画了多少图，而在于真的出问题时能不能第一时间发现、能不能快速定位、能不能避免同样的问题再次发生。Prometheus 和 Grafana 提供的是一套高效的工具链，把指标采集、存储、可视化和告警串成一条完整的链路，剩下的要靠运维同学在真实业务场景里慢慢打磨。这套组合你越用越会发现它的设计精髓：每个组件都只做一件事，但做得足够深、足够好，组合在一起就成了云原生时代监控的基座。
