Oracle NoSQL Databaseは分散システムであるため、複数のソフトウェア・コンポーネントで構成され、それぞれによって公開された一意のメトリックを監視、解釈、活用することにより、NoSQL Databaseクラスタの一般的な状態、パフォーマンスおよび操作性を理解できます。
この項では、Oracle NoSQLソフトウェア・コンポーネントを監視する際のベスト・プラクティスを中心に説明します。Oracle NoSQL Databaseそのものにいくつかのソフトウェア依存関係(Java仮想マシン、オペレーティング・システム、NTPなど)が存在しますが、この項ではNoSQLのコンポーネントのみに注目します。
NoSQL Databaseの状態を監視するための3つの基本的なメカニズムがあります。
システム・ログ・ファイル監視: Oracle NoSQL Databaseは、java.util.loggingパッケージを使用して、すべての追跡、情報、およびエラー・メッセージをストアの各コンポーネントのログ・ファイルに書き込みます。これらのファイルは、主要なシステム管理ソリューションでサポートされている標準的なログ・ファイル・プローブ・メカニズムを使用して解析できます。
システム監視エージェント: Oracle NoSQL Databaseは、SNMPベースの監視ソリューションとの統合のためにMIBを公開し、JMXベースの監視ソリューションとの統合のためにJMX管理Beansを公開します。
アプリケーション監視: NoSQL Databaseの状態を正確に表す指標は、アプリケーション・レベルのメトリックの値です。平均レスポンス時間や90番目のパーセンタイルのレスポンス時間、平均スループットや90番目のパーセンタイルのスループット、NoSQL APIコールから発生した平均タイムアウト例外数といったメトリックはいずれも、NoSQLクラスタ内のコンポーネントに問題がある可能性を示しています。実際に、これらのメトリックのサンプルを取得して平均値からの偏差を調べると、環境で何が問題になっているかを正確に把握できることがあります。
次の各項では、これらの各監視手法について詳しく説明し、それぞれを利用してNoSQL Databaseコンポーネントの障害を検出する方法を示します。
Oracle NoSQL Databaseは次のコンポーネントで構成されており、各コンポーネントによって監視可能なログ・ファイルが生成されます。
レプリケーション・ノード: APIコールからのサービス読取りおよび書込みリクエスト。ある特定のシャードのレプリケーション・ノードは、トポロジ・マネージャによって別々のストレージ・ノード(物理サーバー)に配置されるため、各シャード内のノードのログ・ファイルは複数のマシンに分散されます。
ストレージ・ノード・エージェント: 各ストレージ・ノードで実行されているレプリケーション・ノードを管理します。SNAは、管理対象の各レプリケーション・ノードの状態に関するログを独自に管理します。SNAログは、特定のストレージ・ノードのレプリケーション・ノード・アクティビティの上位レベル・ログと考えることができます。
管理ノード: 管理ノードは、管理コマンドライン・インタフェースからのコマンド実行を処理します。長期にわたる計画も管理ノードからステージングされます。管理ノードは、Oracle NoSQLクラスタ内の他のすべてのログの統合されたログも管理します。
前述のログ・ファイルはすべて、コンポーネントが実行されているマシンに次のディレクトリ構造KVROOT/kvstore/logで格納されています。次の手順を使用すると、クラスタのコンポーネントを実行しているマシンを調べることができます。
java -jar kvstore.jar ping -host <クラスタのマシン> -port <KVStoreの初期化に使用されるポート番号>
各ストレージ・ノード(snXX)およびping出力に表示されたホストで実行されているレプリケーション・ノード(rgXX-rnXX)が、pingコマンドの出力に一覧表示されます。XXは、NoSQL Databaseによってそのコンポーネントに割り当てられた一意の番号を示します。レプリケーション・ノードの場合、rgはシャード番号を示し、レプリケーション・グループを表します。これに対し、rnはそのシャード内のレプリケーション・ノードを示します。
管理ノード: 管理サービスを実行しているクラスタのノードの特定は、少し難しくなります。これらのノードを特定するには、スクリプトによってクラスタ内の各ホストに対してps axwwを実行し、kvstore.jarおよび-class Adminをgrepで検索します。
Oracle NoSQL Databaseは、クラスタの各ノードの単一の統合ログを監視します。これは、管理サービスを実行している任意のノードにあります。このように1箇所でエラーを監視する方法は便利で簡単ですが、100%の保証はありません。単一の統合ビューはネットワーク全体のログ・メッセージを取得することで集約され、一時的なネットワーク障害、パケット・ロスおよびネットワークの高使用率によって、この統合ログは古くなったり、エントリがなくなったりすることがあります。このため、クラスタの各ホストを監視し、さらにクラスタのホストごとに各タイプのログ・ファイルを監視することをお薦めします。
一般に、SEVEREレベルのログ・メッセージはいずれもクリティカル・イベントである可能性があり、システム管理通知を生成する必要があると考えてください。このドキュメントの後半の項では、具体的なSEVERE例外をハードウェア・コンポーネント障害と関連付ける方法を示します。