# 分散モニタリング クラスタ・グリッド・惑星規模システムのように多数の独立して故障しうるノードから成る分散システムにおいて、各ノードの状態を収集・集約し、システム全体の健全性・性能・容量を把握可能にする仕組みを指す。[[Ganglia]] の設計([[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]])は、この問題を「スケーラビリティ・ロバスト性・拡張性・管理可能性・ポータビリティ・オーバーヘッド」という6つの設計課題として定式化し、クラスタ内は対称的なマルチキャストプロトコルで、クラスタ間は階層的な点対点ツリーで扱うという2層構成で解く(Source: [[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]])。 ## 横断的知見 - **1991年の7層モデルは、2004年のGangliaの2層設計に上位互換的に包含される**: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.7が示す観測(observation)・収集(collection)・分析(analysis)・提示(presentation)・解釈(interpretation)・コンソール(console)・管理(management)の7層モデルに対し、Ganglia の gmond(ノード単位でメトリクスを収集・マルチキャストで告知するデーモン)は観測層と収集層を、gmetad(クラスタ間を階層的に巡回しRRDtoolへ書き込む集約デーモン)は収集層と分析層を、それぞれ1つのプロセスに統合している。Ganglia が「解釈」「コンソール」「管理」に相当する層を持たないのは、1991年モデルがこれらを「通常は人間、またはエキスパートシステム」の仕事と位置づけたことと整合し、Ganglia がクラスタ監視という限定用途(人間の意思決定を前提とする可視化どまり)に特化した結果と解釈できる(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.7, [[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]])。 - **収集の通信方式「告知(advertising)対質問(soliciting)」という1991年の2分類が、Gangliaのクラスタ内/クラスタ間で使い分けられている**: 第7章§7.7.2は、m個のコレクタとn個のオブザーバ間の通信方式として、オブザーバが共有媒体上へデータを送信し全コレクタが受信する「告知」と、コレクタが各オブザーバへ個別にクエリを送る「質問」を対比する。Ganglia のクラスタ内通信(gmond同士のマルチキャストによるlisten/announceプロトコル)はまさに「告知」に、クラスタ間のgmetadによる階層的なポーリング(点対点ツリー)は「質問」に対応する。1991年時点で一般論として提示された2つの通信パターンが、2004年の実システムでは単一のモニタ内でも階層水準(クラスタ内/クラスタ間)に応じて使い分けられていることが確認できる(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.7.2, [[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]])。 - **クロック同期問題への対処は、1991年モデルの「集約区間をスキューより十分大きくする」という原則的な指針から、Gangliaのような実システムでは踏み込んだ議論がされていない**: 第7章§7.7.2はクロックスキューが避けられない前提のもとで「最大スキューより十分大きい区間に集約してから比較せよ」という一般原則を与えるが、Ganglia の設計論文(および本頁の既存知見)はクロック同期そのものを設計課題として明示的に扱っていない。1991年の一般論が指摘した論点が、2004年の実装論文では前提として暗黙化されているか、あるいは見落とされている可能性がある(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.7.2, [[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]])。 ## 未解決の問い - Ganglia のマルチキャストベース listen/announce プロトコルは、クラスタ内ノード数が数千規模になると2次的メッセージ負荷でスケールしなくなることが指摘されている。後継の分散モニタリングシステムはこの限界をどのように解消したか(例: ゴシッププロトコル、階層的集約の粒度変更、DHT ベースの構成)。 - Ganglia はフラットなメトリック名前空間を採用しアクセス制御機構を欠くと自己申告している。より新しいモニタリングシステム(Prometheus、OpenTelemetry 等)は名前空間設計・アクセス制御をどう扱っているか。 - gmetad の RRDtool 書き込みが大きな I/O オーバーヘッドを生み対話型ジョブの性能を劣化させるという知見は、時系列データベースの設計選択(ディスク書き込み方式)がモニタリングシステム全体の性能にどこまで波及するかという一般的な問いにつながる。BTrDB([[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]])のような後継時系列DBとの比較が有用か。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.7.3の「アナライザに何を置き、オブザーバに何を残すか」という4規準(頻度・必要データ量・機能の複雑さ・インスタンス数)は、Ganglia の gmond/gmetad の機能分担(gmondは計数のみ、gmetadが集約・書き込み)とどこまで一致するか。1991年の一般原則がGanglia実装の設計判断を事後的に説明できるかを個別に検証する余地がある。 ## 関連 - source: [[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] - concept: [[モニタの分類と設計トレードオフ]] - entity: [[Ganglia]], [[PlanetLab]], [[Matthew L. Massie]], [[Brent N. Chun]], [[David E. Culler]] ## 出典 - [[@2004__Parallel Computing__The Ganglia Distributed Monitoring System - Design, Implementation, and Experience]] - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]](§7.7 分散システムモニタの7層モデル)