1. 管理者ガイド
  2. Oracle NoSQL Databaseの監視
  3. ソフトウェアの監視
  4. システム・ログ・ファイル監視

システム・ログ・ファイル監視

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

  • レプリケーション・ノード(RN) – APIコールからの読取りおよび書込みリクエストを処理します。特定のシャードのレプリケーション・ノードは、トポロジ・マネージャによって異なるストレージ・ノード(物理サーバー)上にレイアウトされるため、各シャード内のノードのログ・ファイルは複数のマシンに分散されます。

  • ストレージ・ノード・エージェント(SNA) – 各ストレージ・ノード(SN)で実行されているレプリケーション・ノードを管理します。ストレージ・ノード・エージェントは、管理している各レプリケーション・ノードの状態に関する独自のログを保持します。ストレージ・ノード・エージェント・ログは、特定のストレージ・ノードに対するレプリケーション・ノード・アクティビティの高レベルのログと考えることができます。

  • 管理ノード – 管理ノードは、管理コマンドライン・インタフェースからのコマンドの実行を処理します。長時間実行プランも管理ノードからステージングされます。また、管理ノードは、Oracle NoSQLクラスタ内のその他すべてのログの統合ログも保持します。

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

  1. java -Xmx64m -Xms64m -jar kvstore.jar ping -host <any machine in the cluster> -port <the port number used to initialize the KVStore>

  2. 各ストレージ・ノード(snXX)は、ping出力にリストされたホストで実行されているレプリケーション・ノード(rgXX-rnXX)のリストとともに、pingコマンドの出力にリストされます。XXは、NoSQLデータベースによってそのコンポーネントに割り当てられている一意の番号を示します。レプリケーション・ノードの場合、rgはシャード番号を示し、レプリケーション・グループを表し、rnはそのシャード内のレプリケーション・ノード番号を示します。

  3. 管理ノード – 管理サービスを実行しているクラスタ内のノードの識別は、少し困難になります。これらのノードを識別するために、スクリプトにより、クラスタ内のすべてのホストでps axwwを実行し、kvstore.jarおよび-class Adminを検索します。

Oracle NoSQL Databaseでは、クラスタ内のすべてのノードの統合された単一のログが保持され、管理サービスを実行している任意のノードでこのログを検出できます。これを使用して便利かつ簡単にエラーを監視できますが、100%保証されるわけではありません。単一の統合ビューは、ネットワークを介してログ・メッセージを取得することによって集計され、一時的なネットワーク障害、パケットの損失およびネットワークの高使用率が原因で、この統合されたログが最新でなくなったり、ログでエントリが欠落する可能性があります。したがって、クラスタ内の各ホストで各タイプのログ・ファイルを監視するだけでなく、クラスタ内の各ホストを監視することをお薦めします。

一般に、SEVEREレベルのログ・メッセージはすべて潜在的にクリティカルなイベントとみなし、システム管理通知を生成する必要があります。このドキュメントの後半部分の項では、ハードウェア・コンポーネントの障害に特定のSEVERE例外を関連付ける方法について説明します。

Java Management Extensions (JMX)の監視

Oracle NoSQL Databaseは、JMXベースのシステム管理ツールによっても監視されます。JMXベースのツールの場合、Oracle NoSQL MIBは、製品のJARファイルとともにインストールのlibディレクトリにあります。JMXの詳細は、標準化されたインタフェース監視を参照してください。