QRadar: リファレンス・セット管理を開くと、ロードに非常に時間がかかり、しばしば Tomcat が再起動する。

Troubleshooting

Problem

QRadar® 7.4.0 から 7.4.3 では、リファレンス・セット管理またはリファレンス・データの管理アプリケーションのロードに長い時間がかかります。このロード中には、最短で 2 分間、最長で 30 分間かかることがあります。また、Tomcat の異常終了を伴う場合もあります。

Symptom

リファレンス・セット管理ウィンドウが開きますが、数分間は空白のままになります。リファレンス・データの管理アプリケーションが開きますが、リファレンス・セットは表示できず、数分間もロード中の表示が表示されます。

Cause

この問題の原因は、既知の不具合である可能性があります: IJ28797: REFERENCE DATA API DATA 'ADDS OR UPDATES' INTO REFERENCE SETS CAN BE SLOW OR TIMEOUT

Environment

IBM QRadar SIEM 7.4.0 から 7.4.2 まで

IBM QRadar SIEM 7.4.3 は影響を受けますが、可能性ははるかに低くなります

Diagnosing The Problem

コンソールで、/var/log/qradar.error というファイルに、以下のような TxSentry プロセスからの警告が含まれている場合があります。

Jan 27 09:29:28 <IP address> [hostcontext.hostcontext] [<GUID>/SequentialEventDispatcher] com.q1labs.hostcontext.tx.TxSentry: [WARN] [NOT:0000004000][<IP address>/- -] [-/- -]Found a process on host <IP address>: tomcat, pid=29335, TX age=657 secs
Jan 27 09:29:28 <IP address> [hostcontext.hostcontext] [<GUID>/SequentialEventDispatcher] com.q1labs.hostcontext.tx.TxSentry: [WARN] [NOT:0000004000][<IP address>/- -] [-/- -] TX on host <IP address>: pid=29335 age=657 IP=127.0.0.1 port=36360 locks=8 query='SELECT a1.key1, a1.key2, a1.data, a1.source, a1.first_seen, a1.last_seen, a1.domain_info FROM ( SELECT rdk.key1, rdk.key2, rde.data, rde.source, rde.first_seen, rde.last_seen, rdk.domain_info FROM reference_data_key rdk, reference_data_element rde WHERE rdk.id = rde.rdk_id AND rdk.rd_id = $1 ORDER BY rde.first_seen, rdk.key1, rdk.key2, rde.data ) AS a1 INNER JOIN ( SELECT DISTINCT rdk.key1 FROM reference_data_key rdk, reference_data_element rde WHERE rdk.id = rde.rdk_id AND rdk.rd_id = $2 ) AS b1 ON b1.key1 = a1.key1 ORDER BY a1.first_seen, a1.key1, a1.key2, a1.data'

または

Jan 27 09:29:28 <IP address> [hostcontext.hostcontext] [<GUID>/SequentialEventDispatcher] com.q1labs.hostcontext.tx.TxSentry: [WARN] [NOT:0000004000][<IP address>/- -] [-/- -] Lock acquired on host <IP address>: rel=reference_data_element age=657 granted=t mode=AccessShareLock query='SELECT a1.key1, a1.key2, a1.data, a1.source, a1.fi'
Jan 27 09:29:28 <IP address> [hostcontext.hostcontext] [<GUID>/SequentialEventDispatcher] com.q1labs.hostcontext.tx.TxSentry: [WARN] [NOT:0000004000][<IP address>/- -] [-/- -] Lock acquired on host <IP address>: rel=reference_data_key_pkey age=657 granted=t mode=AccessShareLock query='SELECT a1.key1, a1.key2, a1.data, a1.source, a1.fi'

Resolving The Problem

この問題は、複数の小さな問題の組み合わせであるため、リファレンス・セットまたは Tomcat のパフォーマンスと安定性を向上させるために役立つ複数の回避策があります。

1. 7.4.3 に更新

この問題は、いずれかのフィックス・パックをインストール済みの QRadar 7.4.3 を使用することで、はるかに少なくなることが確認されています。多くの場合、構成に対する変更をチューニングせずに問題を解決できるため、可能であれば QRadar 7.4.3 に更新することを推奨します。

2. より大きいリファレンス・セットでの存続時間の適用

大きなリファレンス・セットは、この問題の原因になります。可能であれば、より大きなセットのエレメント数を減らすことが推奨されます。これを実現する 1 つの方法は、セットに存続時間 ( TTL ) を設定し、一定期間に使用されなかったエレメントがセットから自動的にクリアされるようにすることです。これは、より長い期間が必要なエレメントもあるため、ユース・ケースによって異なります。

管理者として QRadar にログインします。
管理タブをクリックします。
リファレンス・セット管理をクリックします。
大きなリファレンス・セット ( 100,000 エレメントより大きい ) を確認します。
これらのセットに TTL セットがない場合は、必要に応じて日数を設定することを検討してください。デフォルトの設定では、TTL を使用せず、代わりに「永久に存続」がチェックされています。
設定すると、TTL はバックグラウンドで古いエレメントの削除を開始し、システム・パフォーマンスは徐々に改善されるはずです。

3. 残りの大きなリファレンス・セットについては、Tomcat のメモリー・オーバーライドを適用してください。

TTL を設定しても状況が改善されない場合、または特定のユースケースで不可能な場合、残りの大きなセットにはより大きなキャッシュのオーバーライドを割り当てて、パフォーマンスの改善を支援することができます。これは、Tomcat の起動時にリファレンス・セットに多くのメモリーを割り当て、ディスクからの読み取りと書き込みにかかる時間を短縮することで機能します。

管理者として SSH を使用して QRadar コンソールに接続します。
次のコマンドを使用して、Reference Data Spillover Threshold 値を検索します: grep "ReferenceData.spillover.threshold" /opt/qradar/conf/spillovercache.properties
次のコマンドを使用して、最も大きく、最も可能性の高い原因セットを検出します: psql -Uqradar -c "select id,name,time_to_live,current_count from reference_data order by current_count desc limit 20;"
これにより、エレメントによって上位 20 セットの ID 、名前、TTL 値、エレメント数が返されます。非常に大きなエレメント数を持つセットの名前と ID 、カウントに注意してください。通常、Reference Data Spillover Threshold 値の 10 倍のものはチューニングの良い候補となります。
任意のテキスト・エディターを使用して、ファイル /opt/qradar/conf/spillovercache.properties を開きます。
Reference Data Spillover Threshold を大幅に超えるリファレンス・セットに対して、次のフォーマットでオーバーライドを追加します: RefData_<ID goes here>.spillover.threshold=<Count, rounded up>

例えば、上記のMillionsSet リファレンス・セットの場合、ファイルに次の行を追加します:
RefData_30_domain_2147483647.spillover.threshold=400000
これは、すべてのセットに対して実行する必要はありませんが、Reference Data Spillover Threshold を最も超えるセットに対して実行する必要があります。Reference Data Spillover Threshold 値を下回るものは無視されます。
いくつかのオーバーライドが適用されたら、次を使用して、Tomcat を再起動します。
systemctl restart tomcat
パフォーマンスまたは安定性が向上しているかどうかを確認してください。

4. トランザクション監視機能タイムアウトの設定の増加

Tomcat が不安定な場合の一時的な回避策として、管理者は QRadar のトランザクション監視機能タイムアウトの設定を増加して、より多くの時間を確保することができます。

管理者として QRadar にログインします。
管理タブに移動します。
システム設定をクリックします。
拡張の選択
トランザクション監視機能の設定で、トランザクションの最大時間制限を最大値 30 分に増やします。
次の都合の良いときにすべての構成のデプロイを実行してください。

上記の手順で問題が解決しない場合は、IBM サポートに Case をオープンして報告することを強く推奨します。Case をオープンするには、次のリンクをクリックしてください: Case をオープン

解決を早めるために、以下の情報をケースに提供することを推奨します:

1. QRadar のログ・ファイル。QRadar のログ・ファイルの収集に関する情報は、ここで確認できます。

2. threadTop、pg_stat 及び qlocks.out 。これを収集するには、コンソールから次のコマンドを実行します:

mkdir -r /store/ibmsupport/refdump; for i in {1..40}; do (date; /opt/qradar/support/threadTop.sh -p 7779 --full)>> /store/ibmsupport/refdump/tomcat.out; (date; psql -U qradar -c "select * from q_locks" )>> /store/ibmsupport/refdump/qlocks.out; (date; psql -U qradar -c "select * from pg_stat_activity where state='active'")>> /store/ibmsupport/refdump/pg_stat.out; sleep 5 ; done

このコマンドの実行には 5 分ほどかかり、/store/ibmsupport/refdump/ に次の 3 つのファイルが生成されます。
tomcat.out 、qlocks.out 及び pg_stat.out

これらを新しいケースに提供してください。

Related Information

QRadar: Reference Set Management takes a very long time load when opened, often…

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":"7.4.0;7.4.1;7.4.2;7.4.3"}]

Tips