このセクションでは、ESAを使用するときに発生する可能性がある一般的な問題について説明し、その問題に対する一般的な解決策を提案します。
ESAサービスのトラブルシューティング
| NetWitness Suiteダッシュボードで、ESAサービスがオフラインであることを示す赤で表示されます。 ［構成］＞［ESAルール］ビューで、次のメッセージが表示されます。「サービスがオフラインであるか、アクセスできません」というメッセージが表示されます。 | 複数 | ESAサービスがオフラインである場合、考えられる理由は多数あります。ただし、一般的なのは、作成したルールがメモリを使いすぎていて、ESAサービスで障害が発生するという問題です。この問題のトラブルシューティングについては、「メモリが原因でESAサービスがオフラインになった場合のトラブルシューティング手順」を参照してください。 他の一般的な原因として、ファイアウォールによってESAとNetWitness Suiteの間の接続がブロックされている、ESAサービス マシンがダウンしているなどがあります。 |
| | | ESAサービスを開始するには、次の手順を実行します。 ［管理］＞［サービス］で、ESAサービスの［アクション］アイコン を選択し、［開始］を選択します。 ESAサービスの停止と再開が繰り返される場合は、カスタマー サポートに連絡してください。 |
| 最近のアップグレードの後、NetWitness Suiteダッシュボードで、ESAサービスがオフラインであることを示す赤で表示されます。 ［構成］＞［ESAルール］ビューで、次のメッセージが表示されます。「サービスがオフラインであるか、アクセスできません」というメッセージが表示されます。 | 構成の問題 | システムが最近アップグレードされている場合は、構成エラーが発生した可能性があります。［管理］＞［サービス］で、ESAサービスを選択し、［サービスの編集］をクリックします。［サービスの編集］フィールドで、［接続のテスト］をクリックします。接続できない場合は、構成エラーが発生している可能性があります。構成エラーを修正した後、再度試してください。 |
| ESAの処理速度が遅いように見えます。 | 構成の問題 | バッファ（デフォルト値は10,485,760バイト）を変更するか、TCPの設定をTCPNoDelayに変更し、TCP ACKの受信遅延を回避し、パフォーマンスを向上させることができます。これらの設定（readBufferSizeおよびTcpNoDelay）は、
エクスプローラで/Workflow/Source/nextgenAggregationに移動して変更できます。 |
ESAのRSA Liveルールのトラブルシューティング
| RSA Liveから一連のルールをインポートした後、ESAサービスがクラッシュします。なぜですか？ | RSA Liveルールのパラメータを、実際の環境に合わせて構成していない可能性があります。 | RSA Liveの各ルールの説明には、構成が必要なパラメータや、実際の環境で満足すべき前提条件が記載されています。この説明を確認し、ルールが実際の環境に適しているかどうかを確認してください。 ルールを安全かつ確実に導入するには、新しいルールを評価版ルールとして構成し、実際の環境でテストします。評価版ルールは、新しいルールをテストするための保護対策です。 詳細については、「評価版ルールとしてのルールの導入」を参照してください。 |
| RSA Liveからルールのグループをインポートし、ルールはエラーなしで導入されましたが、後で無効になります。 | すべてのRSA Liveルールが、どの環境にも適しているわけではありません。ESAに正しいメタを指定していないため、ルールを実行できない可能性があります。 | ［構成］＞［ESAルール］＞［サービス］＞［導入されたルールの統計］に移動して無効になったルールを確認できます。 ルールが無効になっている場合、ルールの横に緑のアイコンは表示されません。 ルールが正しく導入されたのに、無効になっている場合は、ルールに関連する例外が発生していないかをログでチェックします。特に、メタがないためにルールが無効になっていないかを確認します。これを確認するには、［管理］＞［サービス］に移動し、ESAサービスを選択してから、 ＞［表示］＞［ログ］を選択します。 次に、以下のようなメッセージを検索します。 "Property named ‘<meta_name>' is not valid in any stream" たとえば、次のようなメッセージです。 Failed to validate filter expression '(medium=1 and streams=2 or medium=3...(238 chars)': Property named 'tcp_flags_seen' is not valid in any stream 同様のメッセージが見つかった場合は、Log DecoderまたはConcentratorにカスタム メタ キーを追加する必要がある場合があります。これを行うには、「DecoderおよびLog Decoder構成ガイド」の「カスタムFeedを使用したカスタム メタ キーの作成」の手順に従います。 |
導入のトラブルシューティング
| ルールを作成し、構文も確認しました。ルールに問題はないように見えます。このルールを導入しようとすると、エラーが発生しました。なぜですか？ | 正しいメタを指定していないため、ルールを導入できない可能性があります。 | メタ キー参照を確認してください。正しいメタを指定していないため、ルールを導入できない可能性があります。 |
ルールのトラブルシューティング
| カスタム ルールを作成しましたが（ルール ビルダまたは詳細EPLを使用）、アラートが生成されません。なぜですか？ | 接続に問題がある可能性があります。 | ［構成］＞［ESAルール］＞［サービス］タブで、「検出レート」統計を確認します。 検出レートがゼロの場合、ESAサービスはConcentratorからデータを受信していません。Concentratorの接続を検証してください。［管理］＞［サービス］に移動し、ESAを選択して［表示］＞［構成］を選択します。Concentratorが有効になっていることを確認します。Concentratorをダブルクリックし、［接続のテスト］をクリックします。 検出レートがゼロでない場合は、ルールで使用されているメタ キー名とタイプが、イベントに存在するメタ キーと一致していない可能性があります。ルールで使用されているメタ キーの名前とタイプが有効かどうかを確認してください。これを行うには、［構成］＞［ESAルール］＞［設定］タブでメタ キーの名前を検索します（メタ キー参照の検索）。 |
| | ルールに問題がある可能性があります。 | 特定のルールが実行されない場合は、［構成］＞［ESAルール］＞［サービス］に移動して、ルールが無効になっていないかどうかを確認します。［導入されたルールの統計］セクションで、無効になっているルールには、（緑の有効ボタンではなく）白いボタンが表示されます。 ［一致イベント数］フィールドも確認できます。［構成］＞［ESAルール］＞［サービス］に移動します。一致したイベントの数を［一致イベント数］列で確認します。 一致したイベントがない場合は、ルールのロジックにエラーがないかどうかを確認します。たとえば、構文の大文字と小文字の区別に関するエラーや、タイム ウィンドウに関するエラーを確認します。それでもアラートが生成されない場合は、ルールのロジックを簡略化し、より簡単なルールでアラートが生成されるかどうかを確認します。 |
メモリが原因でESAサービスがオフラインになった場合のトラブルシューティング手順
ステップ1. ホストが稼働中かどうかの検証
トラブルシューティングの最初のステップとして、ホストが稼働していることを確認します。これを実行するには、［管理］＞［ホスト］に移動します。ホストがダウンしている場合、システム パラメータは表示されず（ただし、ホスト情報の更新が遅れている可能性があります）、［サービス］列は赤で表示されます。また、［更新］フィールドにはエラー メッセージが表示されます。
ホストがダウンしている場合は、NetWitness Suite管理者に連絡して再起動してください。それ以外の場合は、ステップ2に進みます。
ステップ2. ヘルスモニタで詳細な統計情報を表示
ESAサービスがダウンしていることを確認したら、ヘルスモニタに移動して、潜在的な問題が発生している場所を確認します。最もよくあるのは、ESAサービスがメモリ閾値を超えたことにより停止する、または障害が発生するという問題です。
-
［管理］＞［ヘルスモニタ］＞［アラーム］に移動して、ESAによってアラームがトリガーされていないかどうかを確認します。次のアラームを探してください。
- ESA Overall Memory Utilization > 85%
- ESA Overall Memory Utilization > 95%
- ESA Service Stopped
-
［管理］＞［ヘルスモニタ］＞［システム統計ブラウザ］に移動して、各ルールのパフォーマンスのメモリ メトリックを確認します。メトリックを表示するには、フィルタに次の情報を入力します。
| <your host> | Event Stream Analysis | esa-metrics |
各ルールのメモリが［値］列に表示されます。値はバイト単位で表示されます。［履歴チャート］列には、メモリ使用量の履歴が表示されます。
-
［管理］＞［ヘルスモニタ］＞［システム統計ブラウザ］に移動して、ESAのパフォーマンスの詳細を確認します。ホストを選択し、次のフィルタを指定して、次の統計情報を表示します。
| <your host> | ホスト | SystemInfo | CPU Utilization | 1.08% |
| <your host> | ホスト | SystemInfo | Memory Utilization | 45.43% |
| <your host> | ホスト | SystemInfo | Used Memory | 7.08 GB |
| <your host> | ホスト | SystemInfo | Total Memory | 15.58 GB |
| <your host> | ホスト | SystemInfo | Uptime | 77758、1週間、2日... |
| <your host> | Event Stream Analysis | ProcessInfo | Memory Utilization | 7.07 GB |
| <your host> | Event Stream Analysis | ProcessInfo | CPU Utilization | 0.2% |
| <your host> | Event Stream Analysis | JVM.Memory | all | Committed Heap Memory Usage 8.0 GB |
| <your host> | Event Stream Analysis | ESA-Metrics | Total ESA Memory Usage % | 4.64% |
メモリまたはCPUの利用率に問題がある場合は、ステップ3に進みます。
ステップ3. ESAサービスの開始
- ［管理］＞［サービス］で、ESAサービスのアクション アイコンを選択し、［開始］を選択します。
- ESAサービスに戻って、どのルールによってメモリの問題が発生しているかのトラブルシューティングを行います。
ESAサービスの停止と再開が繰り返される場合は、カスタマー サポートに連絡してください。
シャットダウンすることなくESAサービスを開始できた場合は、ステップ4に進みます。
ステップ4. アラートとイベントのボリュームの確認
ESAサービスがシャットダウンすることなく再開できたら、ルールの統計情報を調べて、どのルールがリソースを過剰に使用しているかを確認します。ルールによって生成されるアラートが多すぎる、またはルールと一致するイベントが多すぎることが原因で、ESAサービスに障害が発生する場合もあります。ESAサービスのシャットダウンの原因がメモリ使用量にあると判断した場合は、この両方の問題を調べます。
アラート サマリの表示
アラートの量が多すぎるとシステムに負荷がかかり、システムがダウンしたり、再起動したりすることがあります。 アラート サマリを表示するには、［対応］＞［アラート］に移動します。左側の［フィルタ］パネルの［アラート名］セクションで、ルールのアラート名を選択します。その名前のアラートの数が［アラート］リスト結果の下部に表示されます。特定のルールについてアラート数が極端に多い場合は、そのルールを無効にし、より効率的なルールになるよう記述を変更する必要があります。
フィルタをクリアするには、［フィルタのリセット］をクリックします。
一致イベント数の表示
ルールと一致するイベント数が多すぎるために、メモリを使い果たしてしまうことがあります。これは、通常、ルールのイベント ウィンドウが長く、アラートをトリガーしないイベントが大量に蓄積される場合に発生します。 これらは、アラートがトリガーされるのをルールが待っている間に各イベントがメモリに格納されるため問題になります。この問題を確認するには、［構成］＞［ESAルール］＞［サービス］に移動します。［一致イベント数］列で一致するイベントの数を確認できます。特定のルールについて一致イベント数が極端に多い場合は、ルールをさらに詳しく調査して、そのルールを効率化できるかどうかを確認します。
ステップ5. 問題の原因になっているルールの無効化および修正
変更が必要なルールを特定したら、そのルールを無効にして、大量のアラートやイベントを生成しないよう記述を変更します。より効率的なルールを記述するポイントについては、「ベスト プラクティス」を参照してください。
ルールの無効化
- ルールを無効にするには、［構成］＞［ESAルール］＞［サービス］に移動し、［導入されたルールの統計］フィールドで無効にするルールのチェックボックスを選択します。
- ［無効化］を選択して、ルールを無効にします。
ルールの編集
- ルールを修正するには、［構成］＞［ESAルール］＞［ルール］＞［ルール ライブラリ］に移動します。編集するルールを選択し、［アクション］アイコンをクリックします。
- ［編集］を選択します。
- ルールを編集して効率的なルールに変更します。ルールを作成する手順については、「ルール ライブラリへのルールの追加」を参照してください。
- 納得できるルールになったら、それを評価版ルールとして保存し、メモリの問題が発生してもESAサービスのパフォーマンスに影響を及ぼさないようにします。それには、「評価版ルールの使用」のステップを実行します。
ルールの有効化
- ルールを有効にするには、［構成］＞［ESAルール］＞［サービス］に移動し、［導入されたルールの統計］フィールドで、有効にするルールを選択します。
- ［有効化］を選択して、ルールを有効にします。
（オプション）ESAログ ファイルで詳細を確認
サービスがダウンしていること、およびシステム ダウンの潜在的な原因を検証したら、サービスの停止と再開が繰り返されるかどうかを確認します。 それには、ESAログに移動します。［管理］＞［サービス］ビューで、ESAサービスを選択し、［
］＞［表示］＞［ログ］を選択します。
NetWitness SuiteインタフェースからESAログにアクセスできない場合は、システムにSSH接続し、opt/rsa/esa/logs/esa.logを参照します。
on Apr 18, 2018
］＞［表示］＞［ログ］を選択します。