QPS システムの障害発生時に必要なログと情報

概要

このドキュメントでは、Quantum Policy Suite（QPS）システムで障害またはクラッシュが発生した際に必要となる情報を収集する手順を説明します。ハードウェア、ソフトウェア、および仮想マシンの要件が満たされていれば、QPS がクラッシュすることはないはずです。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• QPS リリース 5.5 以降。

注：QPS リリース 5.5 より前の QPS リリースでは、一部のログが表示されません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

情報の収集

QPS システム障害が発生した場合は、次の情報を収集してください。

診断とデバッグ ログ

1. ポリシー/課金ルール機能（PCRF）クライアント仮想マシン（例：pcrfclient01）にログインし、診断情報（例：/opt/broadhop/installer/diag/diagnostics.sh）を収集します。
2. PCRF クライアント仮想マシンにログインし、デバッグ情報を収集します。デバッグ情報には、統合 QNS ログ、svn repo、および QNS 構成の詳細情報が含まれます。統合ログがシステム障害発生時をカバーしていること、logback.xml ファイルでデバッグ レベルが設定されていることを確認してください。 
3. QPS からデバッグ情報の出力を収集します（例：opt/broadhop/installer/diag/zip_debug_info.sh を実行すると、その出力は /var/tmp/debug_info<date>.zip に格納されます）。

QPS ライセンス情報

1. PCRF クライアント仮想マシンにログインし、QPS ライセンス情報を収集します。通常、QPS は特定の機能に対してライセンス供与されており、QPS がサポートする同時セッション数には上限があります。また、QPS には該当する機能のライセンス期限日も設定されています。
2. ディレクトリ/etc/broadhop/license に移動して、ライセンス（.lic）ファイルの出力を収集します（例：cat /etc/broadhop/license/QUANTUM201311210402429360.lic）。

システム統計情報

1. システム統計情報（例：CPU、メモリ、ディスク使用率）を収集します。
2. PCRF クライアント仮想マシンにログインし、出力を収集します。例： /opt/broadhop/control/top_qps.sh
3. 対応する仮想マシン(pcrfclient0x、lb0x、qns0xなど)にログインし、次のシステム統計情報をキャプチャします。

   cat /proc/meminfo > 割り当てメモリ情報
   free -s 60 > 1分ごとのメモリ統計情報
   vmstat 1 > 1 分ごとの CPU ステータス
   ps -aux | head -10 > CPU使用率が最も高い上位10位のプロセス詳細
   swapon -s > swap usage summary per device
   .du -a | sort -n -r | head -n 10 >より多くの空き領域を消費する上位10ファイル/ディレクトリ

4. sessionmgr 仮想マシンにログインし、mongostat および mongotop の出力を収集します。これらの出力は、問題がデータベースに関連しているかどうかをトラブルシューティングするのに役立ちます。

Policy Builder でのスレッド設定

Policy Builder にログインし、[Reference Data] > [System-1] > [Plugin Configurations] > [Threading Configuration] に移動します。 

TPSのスレッド数は40 ～ 50の範囲で、1,000未満です。構成できるスレッドの最大数は50です。スレッド数を増やすと、システムのパフォーマンスに影響します。 

致命的エラー ログ

システム障害が発生すると、QPS は致命的エラー ログを生成します。このログに、致命的なエラーが発生した時点でのプロセスの状態が記録されます。致命的なエラーまたは致命的例外エラーにより、プログラムは中止されます。

致命的エラー ログには、次の情報が記録されます。

• 致命的なエラーを引き起こした動作例外または信号
• バージョンおよび設定情報
• 致命的なエラーを引き起こしたスレッドに関する詳細と、そのスレッドのスタック トレース
• 実行中スレッドとその状態のリスト
• ヒープに関する要約情報
• ロードされたネイティブ ライブラリのリスト
• コマンドライン引数
• 環境変数
• オペレーティング システム（OS）と中央処理装置（CPU）に関する詳細

デフォルトのログファイル名はhs_err_pid<pid>.logの形式に従い、対応するJavaプロセスが開始された作業ディレクトリに生成されます。例：ユーザが QNS プロセスを起動したときの作業ディレクトリ。

作業ディレクトリがわからない場合は、システムで hs_err_pid*.log という名前のファイルを検索し、そのファイルでエラー発生時と一致する時刻を調べてください。

致命的なエラーが発生した場所を特定するには、次の手順に従います。

1. pcrfclient01 仮想マシンにログインします。
2. jvm.conf を開きます（例：vi /etc/broadhop/pcrf/jvm.conf）。
3. オプション-XX:ErrorFile=<directory>/<file-name>%p.logをリストに追加し、指定したディレクトリパスが存在し、そのディレクトリに対する完全な権限がユーザQNSにあることを確認します。例： -X:ErrorFile=/home/qns/fatal_error_error%p.log
4. pcrfclient01:/etc/broadhopのconfファイルとQNSサービスを実行しているVMの/etc/broadhopのconfファイルが同期されていない場合、「syncconfig.sh」コマンドを使用すると、多くの問題が発生する可能性があります。syncconfig.sh は、pcrfclient01:/etc/broadhop 内の設定ファイルを取り、QNS サービスを実行している VM 上の /etc/broadhop 内にある設定ファイルを上書きします。 

   警告：syncconfig.sh コマンドは、pcrfclient01:/etc/broadhop conf ファイルを取り、QNS サービスを実行している仮想マシン（iomgr01、iomgr02、qns01、qns02 など）上の /etc/broadhop 内にあるすべての設定ファイルを上書きします。

5. QNS アプリケーションを再起動して、コマンド restartall.sh を入力します。