はじめに
初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回は、Ethereumクライアントが使用しているメトリクスを標準化し、異なるクライアントを使用するノードクラスターの監視を容易にする提案をしているEIP2159についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
Ethereumクライアントでは、自身の動作やパフォーマンスを監視し、ブロックチェーンに問題があるなどのエラーが発生した時にアラートを出せるように、Prometheusという監視・警告システムが広く使用されています。
Prometheusは、様々なデータを収集し、それを基に監視ダッシュボードを作成したり、問題があるときに通知を送ったりすることができます。
EthereumクライアントがPrometheusと互換性のある形式で公開するメトリクス（監視対象の数値データ）には、クライアントごとの特有なものが多いですが、すべてのクライアントに共通するメトリクスもあります。
例えば、ブロックチェーンの進行状況やエラーの発生状況などがそれに該当します。
これら共通のメトリクスについて、名称や形式を標準化することで、オペレーター（監視システムを管理する人）は複数のクライアントを一つのダッシュボードやアラート設定で監視できるようになります。
これにより、さまざまなEthereumクライアントの状態を効率的に把握し、問題が生じた際に迅速に対応することが可能になります。
EthereumクライアントがPrometheusというツールを使って、自分たちの動作状況を定期的にチェックし、何か問題があればすぐに知らせてくれるようにするための「共通言語」を作ることで、複数のクライアントを一箇所で管理しやすくする取り組みです。
動機
Ethereumノードを運用する時、異なる種類のクライアント（Ethereumを動かすためのソフトウェア）を使ってノードのクラスター（複数のノードの集まり）を構成することがあります。
各クライアントは、ノードの動作状況や性能などに関する情報（メトリクス）を提供しますが、現在はこれらのメトリクスに対して共通の名称や定義が存在しません。
そのため、クライアント開発者は自分たちでメトリクスの名前や意味を決める必要があります。
このような状況では、異なるクライアントを使っているノードが混在するクラスターを監視するのが難しくなります。
なぜなら、各クライアントが提供するメトリクスの名前や形式が異なるため、これらを一元的に監視するダッシュボードやアラート設定を作成することが複雑になるからです。
もしメトリクスの名称や意味について共通の基準が確立されていれば、異なるクライアントを使用しているノードでも、同じダッシュボードやアラート設定を用いて効率的に監視することができるようになります。
これにより、ノードオペレーター（ノードを管理する人）は、異なるクライアントを使ったクラスター全体の状態を簡単に把握し、問題が発生した際には迅速に対応できるようになります。
メトリクスの名称や意味を統一することで、異なるソフトウェアを使ったノードの集まりも、一つの管理画面から簡単に見ることができるようになるということです。
仕様
以下の表では、Prometheusを介してメトリクスを公開するEthereumクライアントによって収集可能なメトリクスを定義しています。
クライアントはこれらのメトリクスに加えて追加のメトリクスを公開することがありますが、ethereum_プレフィックスはこれらの標準メトリクスにのみ使用されるべきです。
| 名前 | メトリクスタイプ | 定義 | JSON-RPC相当 |
|---|---|---|---|
ethereum_blockchain_height |
Gauge | 正規チェーンの現在の高さ | eth_blockNumber |
ethereum_best_known_block_number |
Gauge | 利用可能な最高ブロックの推定値 |
highestBlock of eth_syncing or eth_blockNumber if not syncing |
ethereum_peer_count |
Gauge | 接続されているピアの現在の数 | net_peerCount |
ethereum_peer_limit |
Gauge | このノードが接続を許可するピアの最大数 | No equivalent |
メトリクスタイプの「Gauge」は、一定時間内に増減する可能性のある値を示します。
例えば、ブロックチェーンの高さや接続されているピアの数などです。
-
ethereum_blockchain_heightは、正規（一番信頼されている）ブロックチェーンの現在のブロック高さを示します。 -
ethereum_best_known_block_numberは、ネットワーク上で利用可能な最高ブロックの番号を推定したものです。- ノードが同期中でない場合は、現在のチェーン高さが使用されます。
-
ethereum_peer_countは、現在接続されているピア（他のノード）の数を表します。 -
ethereum_peer_limitは、ノードが接続を許可するピアの最大数を示しますが、これに対応するJSON-RPCメソッドはありません。
これらのメトリクスにより、Ethereumクライアントの運用状態を効率的に監視し、パフォーマンスの問題やネットワークの異常を迅速に検出することが可能になります。
補足
定義されたメトリクスは、Ethereumクライアントの具体的な実装に依存しないものですが、複数のEthereumノードを監視するための概要ダッシュボードを作成するのに十分な情報を提供します。
これにより、異なるクライアントを使用しているノード群も、一つのダッシュボードで効率的に監視することが可能になります。
同様に、ビーコンチェーンのクライアントメトリクスについても、より指示的な仕様が存在しますが、メトリクスの公開方法についての具体的な詳細は省略されています。
これは、既存の実装間での差異が存在し、この部分を標準化することが大きな利点をもたらさないためです。
つまり、メトリクスの名前や意味に関する共通の基準を設けることによって、異なる実装やクライアント間でも一貫した監視が可能になりますが、メトリクスの公開方法については、各クライアントの実装による違いを受け入れる形になっています。
これにより、オペレーターは異なるEthereumノードやビーコンチェーンクライアントを一元的に監視できるようになり、ネットワーク全体の健全性をより効果的に把握できるようになります。
互換性
ここで言及されているのは、Ethereumクライアントによるメトリクスの標準化に関する変更が、Ethereumの合意形成（コンセンサス）プロセスには影響を与えないという点です。
つまり、この変更はEthereumネットワークがどのように動作するかには直接関係なく、監視やアラートシステムの改善に関するものです。
既に異なる名前を使用してこれらのメトリクスを公開しているクライアントがあるかもしれません。
新しい命名規則に変更することで、既存のアラートやダッシュボードが機能しなくなる可能性があります。
このような非互換性を避けたいクライアントは、古い名前と新しい名前の両方でメトリクスを公開することで対応できます。
また、これらの名前を使用して異なる意味を持つメトリクスを公開しているクライアントもあるかもしれません。
この場合、後方互換性を保持することはできません。
つまり、新しい標準に従ってメトリクスの名前を変更すると、以前とは異なる意味を持つメトリクスが同じ名前で公開されることになり、混乱を招く可能性があります。
総じて、この変更はEthereumクライアントの監視やアラート機能の向上を目指すものであり、Ethereumの核心部分には影響を与えないものの、実装にあたっては既存のシステムとの互換性に注意が必要ということになります。
引用
Adrian Sutton (@ajsutton), "EIP-2159: Common Prometheus Metrics Names for Clients," Ethereum Improvement Proposals, no. 2159, July 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2159.
最後に
今回は「Ethereumクライアントが使用しているメトリクスを標準化し、異なるクライアントを使用するノードクラスターの監視を容易にする提案をしているEIP2159」についてまとめてきました！
いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！