1. 管理者ガイド
  2. 管理手順
  3. ストアの監視

ストアの監視

ストアのパフォーマンスと可用性に関する情報は、サーバー側とクライアント側の両方の観点から取得できます。

  • Oracle NoSQL Databaseアプリケーションでは、oracle.kv.KVStore.getStats()クラスを使用してパフォーマンス統計を取得できます。これは、Oracle NoSQL Database操作の完全なラウンド・トリップ・パフォーマンスのクライアント側のビューを提供します。

  • Oracle NoSQL Databaseでは、レプリケーション・ノードのパフォーマンス統計が自動的にログ・ファイルに記録され、このログ・ファイルをスプレッドシート・ソフトウェアにインポートして分析できます。統計は、ユーザーが指定した間隔で追跡およびロギングされ、CSVファイルに書き込まれます。該当するファイルはEnvironmentディレクトリ内のje.stat.csvです。ロギングは、Environmentが読取り/書込みモードで開かれたときにEnvironment単位で行われます。

    使用されるローテーション・ログ・ファイルのサイズおよび数は構成パラメータによって制御します(javaロギングに類似 - java.util.logging.FileHandlerを参照)。ローテーション・ファイル・セットの場合、各ファイルが所定のサイズ制限に達すると、ファイルが閉じられ、ローテーションとして新しいファイルが開かれます。順次古くなっていくファイルには、増分的な数値の接尾辞が付いた名前が付けられます。名前の形式はje.stat[version].csvです。

  • Oracle NoSQL Database管理サービスでは、ストアで生成されたステータス情報、アラートおよびパフォーマンス統計コンポーネントを収集して集計します。これは、Oracle NoSQL Databaseサーバーの動作とパフォーマンスの詳細なビューを提供します。

  • 各Oracle NoSQL Databaseストレージ・ノードには、そのノードでサポートされているサービスからのトレース情報の詳細なログが保持されます。管理サービスは、これらのコンポーネント・ログのストア全体の集計ビューを示します。管理サービスを使用できない場合、または各ストレージ・ノードのログを個別に調べた方が便利な場合は、各ストレージ・ノードのログを使用できます。さらに、これらのログ・ファイルを圧縮して、同じディスク領域にさらに多くのロギング出力を格納できます。

  • Oracle NoSQL Databaseでは、Java Management Extensions (JMX)エージェントをオプションで監視に使用できます。JMXのインタフェースでは、ストレージ・ノードをポーリングして、ストレージ・ノードとそこでホストされているレプリケーション・ノードに関する情報を取得できます。JMX監視の詳細は、標準化されたインタフェース監視を参照してください。JMXの安全な使用の詳細は、セキュリティ・ガイドのJMXを安全に使用するためのガイドラインを参照してください。

ストアのステータスは、CLI内から検証することによって監視できます。ストアの検証を参照してください。CLIを使用してイベントを調べることもできます。

イベント

イベントは、システムの状態を知らせる特別なメッセージです。イベントが生成されると、監視システムを介して転送され、表示されます。ストアによってレポートされるイベントは4種類あります。

  1. 状態変化イベントは、サービスの起動または停止時に発行されます。

  2. パフォーマンス・イベントは、様々なサービスのパフォーマンスの統計をレポートします。

  3. ログ・イベントは、様々なシステム・コンポーネントによって生成される、デバッグのトレース情報を示すレコードです。これらのレコードは、標準java.util.loggingパッケージによって生成されます。

  4. プランの変遷イベントは、プランの実行、中断、失敗または取消しの進捗を記録します。

ノート:

  • 一部のイベントはクリティカルとみなされます。これらのイベントは、管理サービスのデータベースに記録され、CLIを使用して取得および表示できます。
  • 標準のjava.util.loggingパッケージによって生成されるログ・イベント・レコードを圧縮できます。詳細は、「ログ・ファイル圧縮」を参照してください

プランの変遷イベントは、Oracle NoSQL Databaseの管理インタフェースから直接表示することはできません。ただし、状態変化イベント、パフォーマンス・イベントおよびログ・イベントは、管理内部のEventRecorder機能を使用して記録されます。クリティカルとみなされるイベントのみが記録され、そのようにみなされる基準は、イベントのタイプによって異なります。次のようなイベントがクリティカルとみなされます。

  • すべての状態変化。
  • SEVEREと分類されたログ・イベント。
  • 特定のしきい値を下回るとしてレポートされたパフォーマンス・イベント。

これらのクリティカルなイベントはすべて、管理CLIのshow eventsおよびshow eventコマンドを使用して表示できます。

データベース内の失効していないイベントをすべて表示するには、引数を指定せずにCLI show eventsコマンドを使用します。-fromおよび-to引数を使用して、表示されるイベントの範囲を制限できます。-typeまたは-id引数を使用して、それぞれタイプまたはIDでイベントをフィルタできます。

たとえば、これはshow eventsコマンドからの出力の一部です: 

kv-> show events
idarpdfbS STAT 2015-08-13 22:18:39.287 UTC sn1 RUNNING sev1
idarpeg0S STAT 2015-08-13 22:18:40.608 UTC sn2 RUNNING sev1
idarphmuS STAT 2015-08-13 22:18:44.742 UTC rg1-rn1 RUNNING sev1
idarpjLLS STAT 2015-08-13 22:18:47.289 UTC rg1-rn2 RUNNING sev1
idartfcuS STAT 2015-08-13 22:21:48.414 UTC rg1-rn2 UNREACHABLE sev2
                                                   (reported by admin1)

この結果は、4つのサービス状態変化イベント(sev1)とsev2と分類された1つのログ・イベント(UNREACHABLE)を示しています。各行の先頭のタグは、各イベント・レコードの識別子です。特定のイベントの詳細情報を表示するには、idartfcuSなどのイベント・レコード識別子を引数としてshow eventコマンドを使用します。 

kv-> show event -id idartfcuS
idartfcuS STAT 2015-08-13 22:21:48.414 UTC rg1-rn2 UNREACHABLE sev2
  (reported by admin1)

このようにイベント識別子を指定する方法では、完全なスタック・トレースが表示されます。

イベントの合計数が設定された最大数より多いか、イベントが設定された期間より古くなると、イベントはシステムから削除されます。デフォルトのイベント最大数は10,000で、デフォルトの期間は30日です。

Sev1フラグとSev2フラグはどちらも、特定のサービス状態変化イベントに関連付けられます。Sev1フラグは、現在の状態をレポートするものです。Sev2は、次のように状態変化試行で発生したエラーをレポートするものです。

Sev1フラグ Sev2フラグ
STARTING ERROR_RESTARTING
WAITING_FOR_DEPLOY ERROR_NO_RESTART
RUNNING UNREACHABLE
STOPPING  
STOPPED  

ログ・ファイル圧縮

serviceLogFileCompressionストレージ・ノード・パラメータを設定すると、ログ・ファイルを圧縮できます。これにより、同じディスク領域に保存するロギング出力が大幅に増加します。その結果、ログを長期間保持でき、デバッグ目的でログを使用できるようになります。ログ・ファイルは、標準のgzipアルゴリズムで圧縮されます。デフォルトでは、ログ・ファイルの圧縮には、圧縮されていないファイルと比較して約5倍のデータが格納されます。

ログ・ファイル圧縮を有効にする場合は、関連するストレージ・ノード・エージェントを再起動して、新しい設定が新しいファイルに反映されるようにし、既存のファイルを圧縮します。ログ・ファイルのサイズは、定義した制限を一時的に超える場合があります。ストア結合デバッグ・ログ、統計ファイルおよびパフォーマンス・ファイルのローテーションされたコピーが圧縮されます。また、サービス・デバッグ・ログ・ファイルは、すべてのストレージ・ノード、レプリケーション・ノード、管理およびアービタ間で圧縮されます。

ローテーションされた圧縮ログ・ファイルの名前は、.gz接尾辞で変更され、標準ログ・ローテーション番号のかわりに作成時間を使用するようにファイル名が変更されます。

たとえば:

圧縮前のログ・ファイル 圧縮後のログ・ファイル
rg1-rn1_1.log rg1-rn1_20220720-201902.log.gz

ここで、標準のローテーションされたログ・ファイルrg1-rn1_1.logは、圧縮後にrg1-rn1_20220720-201902.log.gzに変更されます。ログ・ファイルの日付部分は、ファイルが2022-07-20 20:19:02 UTCに作成されたことを意味します。

ローテーションされた複数のログ・ファイルが同じ秒内に作成されると、ファイル名の日付部分に一意の接尾辞が追加されます。

例: rg1-rn1_20220720-201902-1.log.gz。

ノート:

  • 標準のログ・ディレクトリでの余分なディスク領域の使用を回避するために、gzcatコマンドを使用すると、圧縮されたファイルを解凍せずに内容を表示できます。zgrepコマンドを使用して、圧縮されたログ・ファイルを検索します。ファイルを別のディレクトリに解凍することもできます。手動で解凍されたファイルは自動的に削除されません。
  • ブートストラップ・デバッグ・ログ・ファイル、GCログ・ファイル、JEデバッグ・ログ・ファイルおよびJE統計ファイルは圧縮されません。