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

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

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

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

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

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

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

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

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

• イベントの頻繁なドレイン

• 未処理イベントのドレイン

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

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

正常性アラートの形式

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

これらの正常性アラートの構造は次のとおりです。

• Frequent drain of <SILO NAME>

• Drain of unprocessed events from <SILO NAME>

次に例を示します。

• Frequent drain of Low Priority Events

• Drain of unprocessed events from Low Priority Events

どのサイロでも、Frequent drain of <SILO NAME> 正常性アラートが生成される可能性があります。ただし、最も一般的に見られるのは、イベントに関連するアラートです。各イベントサイロに渡って、Low Priority Events が多く見られます。これは、これらのタイプのイベントがデバイスによってより頻繁に生成されるためです。

Frequent drain of <SILO NAME> イベントは、これがイベント関連のサイロに関係して観測された場合に重大度が Warning となります。これは、イベントが FMC に送信されるためのキューに置かれるためです。Backups サイロなど、イベントに関連しないサイロの場合、この情報が失われるため、アラートの重大度レベルは Critical です。

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

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

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

• イベントの喪失

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

Frequent drain of <SILO NAME> イベントは、サイロのサイズに対してサイロへの入力が大きすぎるために発生します。この場合、ディスクマネージャは最後の 5 分間に少なくとも 2 回そのファイルをドレイン（消去）します。イベントタイプサイロでは、これは通常そのイベントタイプの過剰なロギングが原因で発生します。

Drain of unprocessed events of <SILO NAME> 正常性アラートの場合、イベント処理パスのボトルネックが原因で発生することもあります。

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

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

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

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

過剰なロギング

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

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

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

• ACP のロギング設定を確認する：アクセス コントロール ポリシー（ACP）のロギング設定を確認します。接続の開始と終了の両方をログに記録する場合は、終了のみをログに記録します。終了のログには、開始が記録されるときに含まれるすべての項目が含まれるため、イベントの量が削減されます。

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

通信のボトルネック：Sftunnel

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

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

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

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

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

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

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

通信のボトルネック：SFDataCorrerator

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

• ドレインの頻度。

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

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

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

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

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

  admin@FMC:~$ sudo stats_unified.pl

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

  root@FMC:~# manage_procs.pl

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

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

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

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

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

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

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

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

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

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

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

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