EL-CL 監控儀表板：Nimbus 研究案例

StereumLabs 與 MigaLabs 合作，主導開發了一套全面的 Grafana 儀表板，旨在監控多個共識層（Consensus）與執行層（Execution）客戶端的指標。目前有超過 70 種客戶端組合（包括超級節點）在持續運行與觀測中，為真實網路環境下的客戶端行為提供了廣泛且具代表性的視角。

理解客戶端指標的含義及其對運行的影響通常具有挑戰性，特別是在區分正常波動與實際故障時。在本文中，我們將探討一個影響 Nimbus 共識客戶端的錯誤如何透過這些儀表板被清晰且快速地識別，藉此說明它們在現實監控場景中的實用價值。

此分析的目的並非針對特定客戶端，而是展示有效的可觀測性工具如何讓異常行為立即顯現。該狀況在幾小時內便恢復正常，且事件的整體影響有限。同時，這也提醒了在以太坊生態系統中保持客戶端多樣性的重要性。

次要發現——在隨後的 Nimbus 版本中無意間丟失的指標支持——是在與 Nimbus 團隊的協作審查會議中浮出水面的，這進一步凸顯了持續可觀測性和跨團隊溝通的價值。

此外，本文還介紹了 Nimbus 普通節點與超級節點之間的對比分析，利用儀表板的並排對比功能來展示 PeerDAS 規範所引入的運行差異。

---

Nimbus 共識客戶端中斷 — 2026 年 2 月 8 日

2026 年 2 月 8 日，UTC 時間 01:00 至 02:00 之間，Nimbus 共識客戶端遇到了一個嚴重的錯誤，導致其在以太坊主網上的參與暫時中斷。

根據官方的事後分析：

「Nimbus 客戶端錯誤地將一個主網區塊判定為無效並導致分叉。Nimbus 實作中的 Merkle 樹雜湊快取損壞導致了此問題，起因是主網上出現的某些 SSZ 列表對象的大小變化繞過了正確的快取失效機制……由於無法在不違反協議的情況下處理被誤判為無效區塊的後續區塊，Nimbus 在重啟節點之前無法繼續跟隨主網的規範鏈（canonical chain）。」

節點層級的可觀測影響

儘管網路參與在幾小時後恢復正常，但對於輸出 Nimbus 指標的監控系統來說，運行影響是立即顯現的。雖然僅憑指標視覺化不足以確定根本原因，但它能快速且明確地指示異常行為正在發生——即使對於缺乏深厚協議專業知識的營運者也是如此。

最顯著的指標之一是「落後槽位（Slots Behind）」指標。在 UTC 約 02:00 時，本範例中受影響的節點（Nimbus/Nethermind）被觀察到落後時鐘槽位 171 個槽位，清楚地表明已失去與規範鏈的同步。

雖然許多專業質押者運行自己的儀表板，但他們無法看到自己未運行的部分。換句話說，他們只能看到自己運行的節點數據，而無法與未運行的其他客戶端進行比較。這是一個關鍵差異。

由於 StereumLabs 運行大量的節點組合，因此可以非常容易地快速驗證其他節點是否也受到影響以及哪些節點受到影響。事實上，總覽同步狀態表儀表板立即揭示了一個清晰的模式：所有運行 Nimbus 共識客戶端的實例都落後於時鐘槽位，而其他「共識-執行」客戶端組合則繼續正常運行。這種並排對比使異常情況一目了然且易於歸因，無需深入檢查日誌或手動進行跨節點關聯。

這一觀察結果進一步得到了其他共識客戶端專用儀表板的證實，這些客戶端的同步、區塊處理和網路指標在同一時間段內保持穩定。

與此同時，區塊處理實際上停止了。新處理區塊的缺失直接反映在區塊導入指標中，從運行角度來看，問題顯而易見。

網路與節點連接性退化

不穩定性也表現在網路層。當客戶端偏離規範鏈時，它會反覆嘗試建立有效的節點連接。這種行為可以透過以下指標清楚地觀察到：

已連接節點（Connected Peers）

頻寬利用率（Bandwidth Utilization）

libp2p 指標

系統級網路使用情況和協議特定指標均表現出異常模式，這與節點無法成功驗證和傳播規範區塊的情況一致。

資料庫活動停滯

資料庫相關指標進一步凸顯了問題。寫入操作和狀態更新顯著下降，反映出客戶端不再成功處理新的規範數據。這提供了額外的確認，證明節點實際上已停滯，而非僅僅經歷短暫的網路延遲。

總體而言，此錯誤造成的中斷非常有限，只需重啟節點即可解決。Nimbus 仍然是該領域最穩健的 CL 客戶端之一，自信標鏈（Beacon chain）啟動以來未發生過重大事故。錯誤修復程式在幾天後發布，此後未再觀察到任何問題。

---

未被察覺的指標支持丟失

異常檢測是這套儀表板的重要用例之一，但並非唯一用例。在與 Nimbus 團隊就儀表板覆蓋範圍和指標暴露進行簡短技術交流時，我們發現了一個影響特定指標的迴歸問題（regression）。

每個客戶端的已連接節點分佈——這是先前版本中可用的指標——已不再被正確輸出。透過版本對比和歷史儀表板數據，這一變化可以追溯到 2025 年底部署的一個版本，表明這可能是該更新週期中無意引入的迴歸。雖然所有以太坊客戶端在發布前都會進行大量測試，但這些測試通常涵蓋複雜問題，如共識、最終性、驗證、性能等，但並不總是涵蓋指標，因為指標對於運行並非關鍵。

這一發現進一步說明了持續、跨版本可觀測性的價值：除了檢測運行事故外，全面的儀表板還有助於發現可能被忽視的細微指標層級不一致。

---

Nimbus 普通節點與超級節點的對比

Stereumlabs 儀表板提供了普通節點和超級節點的並排對比功能，使營運者能夠觀察並量化這兩種配置之間的運行差異。

Nimbus 中普通節點與超級節點的區別源於 PeerDAS 規範（作為 Fusaka 升級 EIP-7594 的一部分引入）。核心架構差異在於每個節點在點對點網路中託管和傳播的 blob 數據列（column）數量：普通節點訂閱隨機分配的 8 個列子網（column subnets）子集，而超級節點則訂閱所有 128 個列子網，託管完整的數據集。

鑑於超級節點管理的數據量大幅增加，最顯著且最直接的可觀測差異體現在一般網路頻寬消耗上。這在儀表板的頂層網路 I/O 面板中清晰可見。

libp2p 頻寬指標進一步證實了這一點，反映了節點在 gossip 層的參與情況。

超級節點的入站和出站吞吐量均顯著升高，峰值出現在槽位邊界附近，此時正在接收並重新傳播列數據。雖然直覺上可能認為超級節點的頻寬大約是普通節點的 16 倍（因為它訂閱了全部 128 個列子網，而普通節點僅訂閱 8 個），但實際觀察到的倍數明顯較低。這是因為很大一部分頻寬被固定的網路開銷（節點管理、證明、區塊傳播）所消耗，無論子網訂閱數量如何，這些開銷都保持不變；此外，GossipSub 網狀拓撲限制了節點接收任何給定列的對等節點數量。理論上的 16 倍比例僅在頻寬純粹是列數據量的函數且無固定開銷的情況下才成立，但在真實的 p2p 網路中並非如此。

在撰寫本文時的 7 天觀察窗口內，超級節點與普通節點的平均入站和出站頻寬差異約為 40%。

| Mb/s | 普通 最小值 | 普通 最大值 | 普通 平均值 | 超級節點 最小值 | 超級節點 最大值 | 超級節點 平均值 | 差異 最小值 | 差異 最大值 | 差異 平均值 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| 接收 | 5.7 | 10.1 | 7.65 | 10.8 | 81.4 | 18.9 | 52.78% | 12.41% | 40.48% |
| 發送 | 5.52 | 9.33 | 7.21 | 11.1 | 48.2 | 16.7 | 49.73% | 19.36% | 43.17% |

由於在所有 128 個列子網中執行了更多的 KZG 單元驗證和 gossip 處理操作，預計超級節點的 CPU 利用率會高於普通節點。即便如此，單憑此指標並不能作為區分這兩種配置的可靠依據。

普通節點：

超級節點：

在撰寫本文時的 7 天觀察窗口內，對於此特定的 Nimbus/Nethermind 組合，超級節點與普通節點之間平均 CPU 利用率的絕對差異小於 1 個百分點（1.92% 對比 2.74%）。雖然約 70% 的相對增幅看起來很顯著，但應結合極低的絕對值來看待——從 1.92% 增加到 2.74% 在運行上仍然是可以忽略不計的。超級節點上略高的 CPU 利用率是真實存在的，但在實踐中不應引起擔憂。

| | 普通節點 | 超級節點 | 差異 |
| :--- | :--- | :--- | :--- |
| 非空閒 CPU | 1.92% | 2.74% | 70.07% |

增加的列託管直接轉化為共識層更高的磁碟寫入吞吐量和更大的整體存儲消耗。超級節點在託管期內保留所有列的數據，而普通節點的磁碟佔用空間按比例較小，反映出其僅託管分配的子集。

超級節點參與更廣泛的子網，需要與更多樣化且數量更多的節點互動，因此與普通節點相比，其連接的節點數量更高。在 7 天的觀察窗口內，普通節點的連接節點數在 23 到 90 之間，平均值為 35；而超級節點在 50 到 161 之間，平均值為 112 個連接節點。

超級節點訂閱所有 128 個列子網，導致活躍的 gossip 主題訂閱數量顯著增加。僅參與 8 個分配子網的普通節點，在 gossip 訂閱指標中顯示的值會大幅降低。

---

結論

此次事件展示了全面可觀測性對於共識客戶端的運行價值。雖然儀表板不能取代正式的調試或事後分析，但它們為客戶端健康狀況和網路參與提供了即時、可操作的可視化資訊。

所呈現的事件可以透過多個獨立的指標維度清楚地檢測到——同步延遲、區塊處理、節點連接性、網路利用率和資料庫活動。這種多層次的可觀測性使營運者能夠快速識別異常、評估嚴重程度，並在幾分鐘而非幾小時內採取糾正措施。

此外，在 2025 年底發布的版本後發現缺失的連接節點分佈指標，進一步說明了長期指標追蹤的另一個關鍵好處。跨版本的持續監控不僅有助於檢測運行故障，還能揭示迴歸問題、指標不一致以及可觀測性本身無意中的變化。如果沒有結構化的儀表板和歷史對比，這些問題很容易被忽視。

簡而言之，設計良好且持續維護的儀表板不僅僅是視覺化層。它們構成了以太坊生態系統中必不可少的運行介面——使驗證團隊、基礎設施營運者和研究人員能夠檢測事故、驗證修復、比較客戶端行為並持續提高可靠性。