システム・ログ・ファイル・モニタリング

Oracle NoSQL Databaseは次のコンポーネントで構成されており、各コンポーネントによってモニタリング可能なログ・ファイルが生成されます。

レプリケーション・ノード(RN) – APIコールからのサービス読取りおよび書込み要求。特定のシャードのレプリケーション・ノードは、トポロジ・マネージャによって別々のストレージ・ノード(物理サーバー)に配置されるため、各シャード内のノードのログ・ファイルは複数のマシンに分散されます。
ストレージ・ノード・エージェント(SNA) – 各ストレージ・ノード(SN)で実行されているレプリケーション・ノードを管理します。ストレージ・ノード・エージェントは、管理対象の各レプリケーション・ノードの状態に関するログを独自に管理します。ストレージ・ノード・エージェント・ログは、特定のストレージ・ノードのレプリケーション・ノード・アクティビティの上位レベル・ログであると考えることができます。
管理ノード – 管理ノードは、管理コマンドライン・インタフェースからのコマンド実行を処理します。長期にわたる計画も管理ノードからステージングされます。管理ノードは、Oracle NoSQLクラスタ内の他のすべてのログの統合ログも管理します。

前述のログ・ファイルはすべて、コンポーネントが実行されているマシンに次のディレクトリ構造KVROOT/kvstore/logで格納されています。次のステップを使用すると、クラスタのコンポーネントを実行しているマシンを調べることができます。

java -Xmx64m -Xms64m -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例外をハードウェア・コンポーネント障害と関連付ける方法を示します。

Java Management Extensions (JMX)モニタリング

Oracle NoSQL Databaseは、JMXベースのシステム・モニタリング・ツールを介してモニタリングすることもできます。JMXベースのツールのために、インストールされたlibディレクトリに、Oracle NoSQLのMIBが製品のJARファイルとともに含まれています。JMXの詳細は、Oracle NoSQL Database管理者ガイドの標準化されたモニタリング・インタフェースを参照してください。