web3-infra
Blockchain node 運用のための小さな Grafana dashboard
Prometheus と Grafana で、CPU、memory、disk、RPC reachability、sync state、block height、peer count、node filter を見るための公開用メモ。
archive/RPC node が起動した後に必要になるのは、日々見るための視界だ。 log は container が起動したかどうかを見るには十分だが、fleet 全体の状態を見るには向かない。
dashboard で答えたい質問は少ない。
- machine は健康か。
- disk は埋まりつつあるか。
- RPC は到達できるか。
- node は sync 中か。
- node が見ている current height はいくつか。
- network 側の highest height はいくつか。
- peer は何本あるか。
- どの node を見ているか。
最後の点が dashboard の形を決めた。 すべての panel は node name で filter できる必要があった。
用語の説明
| 用語 | 意味 |
|---|---|
| Prometheus | target から metrics を定期的に scrape する time-series database。 |
| Grafana | Prometheus に query を投げ、chart、table、status panel として表示する dashboard UI。 |
| node_exporter | Linux の CPU、memory、disk、filesystem、network metrics を出す Prometheus exporter。 |
| scrape target | Prometheus が定期的に metrics を取りに行く endpoint。 |
| label | metrics series に付く key-value tag。node label があると dashboard filter が作れる。 |
| RPC exporter | node RPC を呼び、その結果を Prometheus metrics として公開する小さな service。 |
Monitoring は二層に分ける
monitor の役割は二つある。 一つ目は host monitoring。 二つ目は chain monitoring。
host monitoring は node_exporter が担当する。
CPU、memory、disk、filesystem、network が取れる。
blockchain client がまだ sync 中でも、RPC に monitor から届かなくても、この層は動いてほしい。
chain monitoring は client metrics と RPC check が担当する。 execution client、consensus client、Substrate 系 node では、native metrics の名前が揃わない。 RPC check を入れると、最低限の状態を同じ形で見られる。
この分離は障害時に効く。 host metrics が正常で RPC だけ落ちているなら、node process、bind address、firewall、proxy、client state を見る。 host metrics も落ちているなら、instance、network、Prometheus target、exporter の方を見る。
見たい metrics
dashboard は次の group で作った。
| Group | Panels |
|---|---|
| Host | CPU usage、memory usage、filesystem usage、disk I/O、network traffic |
| Prometheus | target up、scrape failure、scrape duration |
| RPC | RPC up、current block、highest block、syncing flag、peer count |
| Lag | highest block minus current block |
| Chain-specific | Erigon、Substrate-style、その他 client-native metrics |
RPC layer は小さな exporter で足りる。 EVM 系 node なら、まず次の method を呼ぶ。
eth_blockNumber
eth_syncing
net_peerCount
Substrate 系 node では system RPC、chain RPC、または native metrics を使う。 method 名は違っても、欲しいものは同じだ。 current height、target height、sync state、peer count。
exporter 側の metrics はこのような名前で十分だ。
node_rpc_up
node_rpc_current_block
node_rpc_highest_block
node_rpc_syncing
node_rpc_peer_count
node_rpc_last_success_timestamp
prefix よりも label が大事だ。
少なくとも node、chain、endpoint は付けたい。
Node name を label にする
Grafana の filter は node label に依存する。
この label がないと、panel には instance address と port が並ぶだけになる。
Prometheus target に安定した label を付ける。
labels:
node: astar
chain: astar
role: archive-rpc
Grafana variable は次の query で作れる。
label_values(up, node)
panel 側ではこう使う。
up{node=~"$node"}
または:
node_rpc_current_block{node=~"$node"}
小さな設定だが、dashboard の使いやすさは大きく変わる。
RPC Up の読み方
RPC Up = 0 は、monitor が RPC check を完了できなかったという意味だ。
node が完全に落ちたとは限らない。
よくある見え方は次の通り。
| 状態 | 見る場所 |
|---|---|
| host metrics は up、RPC up は 0 | RPC bind、firewall、proxy、client health、endpoint path |
| host metrics も RPC up も落ちている | instance、network、Prometheus target、exporter |
| RPC up は 1、syncing は 1 | node は生きているが追いついていない |
| RPC up は 1、block lag が増える | sync が遅い、または止まりかけている |
EVM node で RPC を 127.0.0.1 に bind している場合、この違いが出やすい。
service は local で健康でも、monitor から直接届かないことがある。
その場合は local collection path や proxy を明示的に作る。
public RPC listener に変える必要はない。
Template の使い方
最初に公式と community の Grafana dashboard を探した。 参考になったのは次のあたりだった。
- Linux host metrics 用の Node Exporter Full。
- execution client 内部を見る Erigon 系 dashboard。
- peer と block metrics を見る Substrate dashboard。
- client が安定した metrics 名を出している chain-specific dashboard。
ただし、そのまま全部を満たす template はなかった。 client が混在し、RPC の公開形態も違い、node name filter も必要だった。 最終的には host panel は定番を使い、chain status は custom RPC layer で揃えた。
client internals は公式 dashboard が強い。 fleet dashboard には、client をまたいだ共通の見方が必要になる。
Node を置換しない monitoring update
monitoring 追加で node instance を置換しないことも境界にした。 Prometheus config、Grafana provisioning、exporter file を変えるだけなら、monitor host に対する remote command の方が狭く済む。
Terraform は最終的な desired state を持てばよい。 ただ、node が sync 中の時期に、monitoring の小さな変更で無関係な EC2 resource を動かしたくない。
欲しかった dashboard
最初の page は素朴でよい。
| Row | Content |
|---|---|
| Fleet health | node ごとの Prometheus target up と RPC up |
| Sync | syncing flag、current height、highest height、block lag |
| Peers | node ごとの peer count |
| Host pressure | CPU、memory、filesystem、disk read/write、network |
| Detail | 選択した node の client-specific metrics |
見た目より、判断の速さを優先した。 node が遅い時に、CPU、memory、disk、peer、RPC reachability、chain sync のどこを見るべきかを一分以内に絞りたい。