Troubleshooting
Problem
QRadar では、未加工のイベントが取り込まれてから、ecs-ec サービスによって解析 ( 正規化 ) されます。ecs-ec サービスでは、イベント・パーサー・スレッドがペイロードから情報を取得し、それぞれの DSM からカスタム・イベント・プロパティとパターンを使用してレコードを作成します。もしこれらのパーサー・スレッドが負担になり、新しいイベントがシステムに到着すると同時に処理できなくなった場合、ecs-ec サービスはパーサー・スレッドをバイパスして、いくつかのイベントを「直接ストレージに」ルーティングします。このメカニズムは可能な限りリアルタイムに近い処理を維持するように設計されていますが、解析されていないイベントも相関や検索機能に影響を与えるため、パフォーマンスの問題に迅速に対処することが重要です。
Symptom
パフォーマンス低下を確認する最も一般的な方法は、システム通知で確認することです。ベル・アイコンに、イベント・パイプラインでパフォーマンスの低下が検出されたこと (Performance degradation has been detected in the event pipeline )を示す通知が表示されます。 通知の上にカーソルを移動すると、どのシステムでストレージへのルーティングの動作が発生しているかがペイロードで特定されます。
今回は、DSM フィルタでのストレージへのルーティングに注目します。このペイロードの例では、DSM フィルターとデバイス解析の両方について言及しています。
[[type=com.eventgnosis.system.ThreadedEventProcessor][parent=:ecs-ec/EC/Parsing/DSM_Normalize]] com.ibm.si.ec.filters.normalize.DSMFilter: [WARN] [NOT:0080004101][-/- -]Device Parsing has sent a total of 18167670 event(s) directly to storage. 593 event(s) have been sent in the last 60 seconds. Queue is at 88 percent capacity.
Cause
デバイス構文解析時のストレージへのルーティングは、ecs-ec サービス内のイベント・パーサー・スレッドが受信 EPS レートに追いつけない場合や、解析構成が非効率的である場合に発生します。
また、アプライアンスが処理できる定格以上のEPSを送信された場合にも、パフォーマンスの低下が発生することがあります。 次の技術情報には、ハードウェア機能を確認する手順が記載されています。
Diagnosing The Problem
デバイスの構文解析時にどのホストがパフォーマンス低下を起こしているかを追跡するには、以下のようにします。
- ベル・アイコンでベルを選択します。
- イベント・パイプラインでパフォーマンスの低下が検出されたこと (Performance degradation has been detected in the event pipeline ) を選択します。
- 次に、最も多くのパフォーマンス低下通知を生成しているアプライアンスを特定するために、ソース IP で検索をグループ化するか、以下の AQL 検索を使用します。
Select sourceip as 'IP', COUNT(*) from events where qid='38750088' and utf8(payload) ILIKE '%DSMFilter%' GROUP BY IP last 24 HOURS;
多くの場合、「イベント・パイプラインでパフォーマンスの低下が検出されました。 高負荷の DSM または DSM 拡張が検出されました。 ( Performance degradation has been detected in the event pipeline. Expensive DSM or DSM Extensions were found ) 」という 2 番目の通知があります。
[Timer-36] com.ibm.si.ec.filters.normalize.DSMFilter: [WARN] [-/- -]Expensive Log Source or Log Source Extensions Based On Average Throughput in the last 60 seconds (most to least expensive) - Linux OS=60.0eps
この通知は、Linux DSM が現在 60 EPS を解析していることを示しています。 5000 EPS 未満の EPS 値は調査する価値があります。 この通知は、ペイロード構造に問題がないことを確認するためにイベント・ペイロードを検査する必要があることを意味します。 ペイロード構造に問題があると、イベント・パーサー・スレッドが遅くなり、ストレージへのルーティングが発生します。
これらのイベントを見つけるには、以下のようにします。
- Log Source Management アプリケーションに移動し、「ターゲット・イベント・コレクター」の下にあるイベント・コレクターの ID をメモします。
- 次に、ログ・アクティビティーで、「イベント・コレクター ID ( Event Collector ID ) 」及び「カテゴリー ( Category ) : 不明 ( Unknown )> 保管 ( Stored ) 」、「パフォーマンスを改善するために保管された ( stored for performance ) : False 」のフィルターを追加します。ログ・ソース・タイプでグループ化します。 これらの結果は、DSM が解析できず、デバイス解析のパフォーマンス問題を引き起こすすべてのイベントを表示します。
- 検索結果から、ログ・ソース、イベント名、またはカテゴリーで条件を絞り込むことができます。
- 絞り込まれたら、DSM エディターで返されるイベントのいくつかを開くことができます。検索結果でいくつかのイベントを強調表示します。
- アクション・メニューで、「DSM エディター」を選択します。
- DSM エディターにイベント・ペイロードがロードされたら、解析済みフィールドを確認します。 少なくともイベント ID とカテゴリーが解析されない場合は、ペイロードの自動検出が誤っているか、ログ・ソース構成に問題がある可能性があります。
Resolving The Problem
即時の問題を解決するには、「 Diagnosing The Problem 」の手順で特定されたログ・ソースを無効にします。
ログ・ソースが無効な場合、イベントは SIM 汎用ログ・ソースに、そこではほとんど、あるいはまったく解析が行われません。イベントを SIM 汎用ログ・ソースに送信すると、ユーザーが構文解析の問題を永続的に修正している間に、イベント構文解析のパフォーマンスが向上します。
ログ・ソースが無効な場合、イベントは SIM 汎用ログ・ソースに、そこではほとんど、あるいはまったく解析が行われません。イベントを SIM 汎用ログ・ソースに送信すると、ユーザーが構文解析の問題を永続的に修正している間に、イベント構文解析のパフォーマンスが向上します。
注 : ログ・ソースを削除するのではなく、無効化にしてください。自動検出が有効な場合、削除されたログ・ソースは自動的に再作成されることがあります。
次のステップ :
- DSM ガイドを確認し、ログ・ソースが正しく設定されていることを確認してください。
- 適切な DSM がインストールされていることを確認します。
バージョンを確認するには、以下のようにします。- 「管理」>「自動更新」>「履歴の表示」を参照します。
- そこでログ・ソース・タイプを確認します。
- DSM のバージョンを IBM Fix Central と照合し、最新の DSM がインストールされていることを確認します。
Related Information
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtiAAA","label":"Performance"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
24 February 2023
UID
ibm16953395