web3-infra
给区块链节点做一个够用的 Grafana 监控面板
一份 Prometheus 和 Grafana 监控整理：机器 CPU/内存/磁盘、RPC 可用性、同步状态、当前高度、最新高度、peer 数和节点名称筛选。
archive/RPC 节点启动以后，下一件事是可观测性。 日志能告诉我容器有没有起来，但不适合日常看全局状态。
监控面板需要回答几个很具体的问题：
- 机器是不是健康？
- 磁盘是不是快满？
- RPC 能不能访问？
- 节点还在同步吗？
- 当前节点高度是多少？
- 网络最新高度是多少？
- peer 数够不够？
- 我现在筛选的是哪个节点？
最后一个问题很关键。 所有图表都要能按节点名称筛选。
用语说明
| 用语 | 含义 |
|---|---|
| Prometheus | 按固定周期抓取 metrics 的时序数据库。 |
| Grafana | 查询 Prometheus 并展示图表、表格和状态面板的 dashboard 工具。 |
| node_exporter | Linux 主机 metrics exporter，提供 CPU、内存、磁盘、文件系统、网络等数据。 |
| scrape target | Prometheus 定期访问的 metrics endpoint。 |
| label | metrics 上的键值标签。node 这样的 label 可以让 dashboard 做筛选。 |
| RPC exporter | 调用节点 RPC，并把返回值转成 Prometheus metrics 的小服务。 |
监控分两层
monitor 要做两类事情。 第一类是机器监控。 第二类是链节点监控。
机器监控来自 node_exporter。
它提供 CPU、内存、磁盘、文件系统和网络数据。
即使链客户端还在同步，或者 RPC 暂时不能被 monitor 访问，这一层也应该能看到。
链节点监控来自客户端 metrics 和 RPC 抽样。 execution client、consensus client、Substrate 系节点的原生 metrics 名称不完全一样。 RPC 抽样可以把最常用的状态统一起来，因为 EVM 类节点都能回答一组基础调用。
这个拆分在排障时很有用。 如果机器 metrics 正常，但 RPC down，问题大概率在节点进程、监听地址、防火墙、代理或客户端状态。 如果机器 metrics 也没有，问题就更靠近实例、网络或 Prometheus 抓取本身。
真正需要看的指标
面板按几组来做：
| 分组 | 面板 |
|---|---|
| 机器 | CPU 使用率、内存使用率、文件系统使用率、磁盘 I/O、网络流量 |
| Prometheus | target up、抓取失败、抓取耗时 |
| RPC | RPC up、当前区块、最高区块、syncing、peer count |
| 落后量 | 最高区块减当前区块 |
| 链客户端 | Erigon、Substrate-style 和其他客户端原生 metrics |
RPC 层用一个轻量 exporter 就够了。 它调用这些 RPC：
eth_blockNumber
eth_syncing
net_peerCount
Substrate 类节点则用系统 RPC、链 RPC 或客户端原生 metrics。 RPC 名称不完全一样，但 dashboard 要看的东西一样：当前高度、目标高度、同步状态和 peer。
exporter 可以暴露这类通用指标：
node_rpc_up
node_rpc_current_block
node_rpc_highest_block
node_rpc_syncing
node_rpc_peer_count
node_rpc_last_success_timestamp
指标前缀不是重点。
重点是每条序列至少带上 node、chain、endpoint。
节点名称要做成 label
Grafana 的筛选依赖 node label。
没有这个 label，图表里就只剩一堆实例地址和端口，很难快速判断。
Prometheus target 里可以加稳定标签：
labels:
node: astar
chain: astar
role: archive-rpc
Grafana 变量可以这样取：
label_values(up, node)
图表查询里就可以写：
up{node=~"$node"}
或者：
node_rpc_current_block{node=~"$node"}
这一步很小，但 dashboard 会从“主机列表”变成“可操作的节点视图”。
RPC Up 不是节点生死判断
RPC Up = 0 只表示 monitor 没能完成 RPC 检查。
它不一定代表节点挂了。
常见情况是：
| 现象 | 更可能看的位置 |
|---|---|
| 机器 metrics 正常，RPC up 为 0 | RPC 监听、防火墙、代理、客户端健康、endpoint path |
| 机器 metrics 也没有，RPC up 为 0 | 实例、网络、Prometheus target、exporter |
| RPC up 为 1，syncing 为 1 | 节点活着，但还在追块 |
| RPC up 为 1，block lag 变大 | 同步太慢或卡住 |
任何 EVM 节点如果 RPC 只绑定 127.0.0.1，这一点都会很明显。
服务本机健康，不代表 monitor 能直接访问。
这种场景下应该做受控的本地采集路径或代理，而不是把 RPC 直接暴露到公网。
模板怎么选
我先找了官方和社区的 Grafana dashboard。 有参考价值的主要是：
- Node Exporter Full，用来看 Linux 主机指标。
- Erigon 相关 dashboard，用来看 execution client 内部状态。
- Substrate dashboard，用来看 peer 和 block 指标。
- 各链客户端自己暴露的 Prometheus metrics。
没有一个模板能直接覆盖整个需求。 节点类型混在一起，RPC 行为不同，还要求按节点名称筛选。 最后的做法是：主机层借鉴成熟模板，链状态层用自定义 RPC exporter 统一指标。
这比强行套一个模板更实际。 官方模板适合看单个客户端内部状态，节点 fleet dashboard 需要跨客户端的共同语言。
不替换节点的监控更新
监控变更还有一个边界：不能因为加 dashboard 或改 scrape 配置而替换正在同步的节点。 如果只是更新 monitor 主机上的 Prometheus 配置、Grafana provisioning 或 exporter 文件，用远程命令调整比直接做一次大范围 Terraform apply 更稳。
Terraform 仍然可以保留最终期望状态。 但节点还在同步时，监控改动不应该把无关 EC2 资源带进风险里。
我想要的首页
一个够用的首页很朴素：
| 行 | 内容 |
|---|---|
| Fleet health | 每个节点的 Prometheus target up 和 RPC up |
| Sync | syncing、当前高度、最高高度、block lag |
| Peers | 每个节点的 peer count |
| Host pressure | CPU、内存、文件系统、磁盘读写、网络 |
| Detail | 当前筛选节点的客户端原生指标 |
这个 dashboard 不是为了好看。 它的作用是让人一分钟内判断：慢的是 CPU、内存、磁盘、peer、RPC 访问，还是链同步本身。