メモリ使用率ヘルスモジュールは、アプライアンス上のメモリ使用率をモジュールに設定された制限と比較し、使用率がそのレベルを超えるとアラートを出します。このモジュールは、管理対象デバイスおよび Management Center 自体のデータをモニターします。

メモリー使用率の 2 つの設定可能なしきい値である「クリティカル」と「警告」は、使用されるメモリのパーセンテージとして設定できます。これらのしきい値を超えると、指定された重大度レベルでヘルスアラームが生成されます。ただし、ヘルスアラームシステムはこれらのしきい値を正確に計算しません。

高メモリデバイスでは、低メモリフットプリントデバイスよりも、特定のプロセスがシステムメモリ全体の大きな割合を使用することが予想されます。この設計では、物理メモリをできるだけ多く使用し、補助的なプロセス用に小さい値のメモリを解放します。

たとえば、32 GB のメモリを搭載したデバイスと 4 GB のメモリを搭載したデバイスを比較します。補助的なプロセスのために解放される 5 % のメモリは、32 GB のメモリを搭載したデバイスでは 1.6 GB、4 GB のメモリを搭載したデバイスでは 200 MB であり、前者の方がはるかに大きな値になります。

特定のプロセスによるシステムメモリの使用率が高いことを考慮して、Management Center は、合計物理メモリと合計スワップメモリの両方を含めて合計メモリを計算します。そのため、ユーザーが設定するしきい値入力に対して適用されるメモリしきい値により、イベントの「値」列が、超過しきい値を特定するために入力された値と一致しないようなヘルスイベントが発生する可能性があります。

バージョン 7.4.1 以降、メモリ使用率正常性モジュールは、使用可能な空きメモリ、使用可能なスワップメモリ、およびバッファキャッシュを考慮してメモリ使用率を計算します。メモリ使用率正常性アラートの早すぎる生成を回避するために、警告およびクリティカルアラームのしきい値である 88% と 90% を超えないようにすることをお勧めします。

次の表は、搭載するシステムメモリに応じた、ユーザー入力のしきい値と適用されるしきい値の例を示しています。

（注）	この表の値は一例です。この情報を使用して、ここに示されている搭載 RAM と一致しないデバイスのしきい値を推定することができます。また、より正確なしきい値の計算について Cisco TAC に問い合わせることもできます。

注意	Management Center がクリティカルシステムメモリ状態に達すると、システムは、メモリ使用量の多いプロセスを終了したり、高いメモリ使用率が続く場合には Management Center を再起動する可能性があります。

Disk Usage 正常性モジュールは、管理対象デバイスのハードドライブとマルウェア ストレージ パック上のディスク使用率をモジュールに設定された制限と比較し、その使用率がモジュールに設定されたパーセンテージを超えた時点でアラートを出します。また、モジュールしきい値に基づいて、システムが監視対象のディスク使用カテゴリ内のファイルを過剰に削除する場合、または、これらのカテゴリを除くディスク使用率が過剰なレベルに達した場合にもアラートを出します。

このトピックでは、Disk Usage 正常性モジュールによって生成される未処理イベントのドレイン正常性アラートの症状とトラブルシューティングのガイドラインについて説明します。

ディスクマネージャのプロセスは、デバイスのディスク使用率を管理します。ディスクマネージャによってモニターされる各タイプのファイルには、サイロが割り当てられます。システムで使用可能なディスク容量に基づいて、ディスクマネージャは各サイロの最高水準点（High Water Mark、HWM）と最低水準点（Low Water Mark 、LWM）を計算します。

システムの各部分のディスク使用率の詳細情報（サイロ、LWM、HWM など）を表示するには、show disk-manager コマンドを使用します。

正常性アラートの形式

Management Center の正常性モニタープロセスが実行されると（5 分ごとに 1 回、または手動実行がトリガーされると）、ディスク使用状況モジュールは diskmanager.log ファイルを調べ、該当する条件が満たされると、正常性アラートがトリガーされます。

重要	イベントサイロのみが Drain of unprocessed events from <SILO NAME> 正常性アラートを生成します。このアラートの重大度レベルは常に [重大（Critical）] です。

アラート以外のその他の症状には、次のものがあります。

• Management Center ユーザーインターフェイスの速度低下

• イベントの喪失

一般的なトラブルシューティング シナリオ

Drain of unprocessed events of <SILO NAME> 正常性アラートは、イベント処理パスのボトルネックが原因で発生します。

これらのディスク使用率アラートに関して、次の 3 つのボトルネックが存在する可能性があります。

• 過剰なロギング：Threat Defense の EventHandler プロセスがオーバーサブスクライブされています（Snort の書き込みよりも読み取りが遅い）。

• Sftunnel ボトルネック：イベント用インターフェイスが不安定またはオーバーサブスクライブ状態です。

• SFDataCorrerator のボトルネック：Management Center と管理対象デバイス間のデータ伝送チャネルがオーバーサブスクライブ状態です。

過剰なロギング

このタイプの正常性アラートの最も一般的な原因の 1 つは、過剰な入力です。show disk-manager コマンドから収集された最低水準点（LWM）と最高水準点（HWM）の差は、該当サイロが LWM（新たにドレインされた状態）から HWM 値に移行するまでに使用できる容量を示しています。未処理のイベントのドレインがある場合は、ロギング設定を確認してください。

• ダブルロギングを確認する：Management Center でコリレータ perfstats を調査すると、ダブルロギングのシナリオを特定できます。

  admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now

• ACP のロギング設定を確認する：アクセス コントロール ポリシー（ACP）のロギング設定を確認します。ロギング設定に接続の「開始」と「終了」の両方が含まれている場合は、イベントの数を減らすために、終了のみをログに記録するように設定を変更します。

  接続のロギングのベスト プラクティスに記載されているベストプラクティスに従っていることを確認します。

通信のボトルネック：Sftunnel

Sftunnel は、Management Center と管理対象デバイス間の暗号化通信を担当します。イベントはトンネルを介して Management Center に送信されます。管理対象デバイスと Management Center 間の通信チャネル（sftunnel）の接続性の問題や不安定性は、次の原因が考えられます。

• Sftunnel がダウンしているか、不安定（フラッピングしている）。

  Management Center と管理対象デバイスが、TCP ポート 8305 の管理インターフェイス間で到達可能であることを確認します。

  sftunnel プロセスは安定している必要があり、予期せず再起動することがあってはいけません。これを検証するには、/var/log/message ファイルを確認し、文字列 sftunneld を含むメッセージを検索します。

• Sftunnel がオーバーサブスクライブされている。

  正常性モニターからのトレンドデータを確認し、Management Center の管理インターフェイスのオーバーサブスクリプションの兆候を探します。この徴候には、管理トラフィックのスパイクや一定したオーバーサブスクリプションなどがあります。

  イベントのセカンダリ管理インターフェイスとして使用します。このインターフェイスを使用するには、Threat Defense CLI で configure network management-interface コマンドを使用して、IP アドレスなどのパラメータを設定する必要があります。

通信のボトルネック：SFDataCorrerator

SFDataCorrerator は、Management Center と管理対象デバイス間のデータ伝送を管理します。 Management Center では、システムによって作成されたバイナリファイルを分析して、イベント、接続データ、およびネットワークマップを生成します。最初のステップでは、diskmanager.log ファイルを調べて、次のような重要な情報を収集します。

• ドレインの頻度。

• 未処理イベントを含むファイルがドレインされた数。

• 未処理イベントによるドレインの発生。

ディスクマネージャプロセスが実行されるたびに、各サイロのエントリが独自のログファイルに生成されます。エントリは、[/ngfw]/var/log/diskmanager.log 下に存在します。diskmanager.log（CSV形式）から収集された情報は、原因の検索を絞り込むために使用できます。

その他のトラブルシューティング手順：

• コマンド stats_unified.pl は、Management Center に送信する必要があるデータが管理対象デバイスにあるかどうかを判断するのに役立ちます。この状態は、管理対象デバイスと Management Center で接続の問題が生じた場合に発生する可能性があります。管理対象デバイスは、ログデータをハードドライブに保存します。

  admin@FMC:~$ sudo stats_unified.pl

• manage_proc.pl コマンドは、Management Center 側のコリレータを再設定できます。

  root@FMC:~# manage_procs.pl

Cisco Technical Assistance Center（TAC）に問い合わせる前に

Cisco TACに連絡する前に、次の項目を収集することを強く推奨します。

• 表示される正常性アラートのスクリーンショット。

• Management Center から生成されたトラブルシュートファイル。

• 影響を受ける管理対象デバイスから生成されたトラブルシュートファイル。

  問題が最初に検出された日時。

• ポリシーに最近加えられた変更に関する情報（該当する場合）。

  通信のボトルネック：SFDataCorreratorで説明されている stats_unified.pl コマンドの出力。

アプライアンスで問題が発生したときに、問題の診断に役立つように、サポートからトラブルシューティング ファイルを提供するように依頼されることがあります。システムは、特定の機能分野を対象とした情報を含むトラブルシューティング ファイルと、高度なトラブルシューティング ファイル（このファイルはサポートと連携して取得します）を生成することができます。次の表に示すオプションのいずれかを選択して、特定の機能のトラブルシューティング ファイルの内容をカスタマイズできます。

一部のオプションは報告対象のデータの点で重複していますが、トラブルシューティング ファイルには、オプションの選択に関係なく冗長コピーは含まれません。

内部電源障害（ハードウェア障害、電源サージなど）や外部電源の障害（コードが外れている）によって、グレースフルでないシャットダウンまたは再起動が発生することがあります。これによってデータが破損することがあります。

機能固有のトラブルシューティングのヒントやテクニックについては、次の表を参照してください。