NetWitness Platformでパーサーがスタックしているため、Health & WellnessでDecoder Capture Rate Zeroが発生した際の分析について

Issue

• Decoder Capture Rate Zeroアラームが、Health & Wellnessでトリガーされます。
• Decoder Packet Capture Pool DepletedアラームがHealth & Wellnessでトリガーされます。
• Decoder Dropping >xx% of PacketsアラームがHealth & Wellnessでトリガーされます。
• Decoder packet capture rateがDecoderサービスを再起動するまでゼロになります。
• Decoderサービスを再起動しても同じ問題が再び発生します。 (これは受信トラフィックとパーサーによって異なるため、数日ごとに発生することも、1 日に数回発生することもあります。)

Cause

DecoderのParse threadでセッションがスタックしたため、Decoderで使用可能なすべてのmemory pagesがAssemblerとParse Threadに割り当てられたことが起因しています。

Capture threadに使用可能なメモリがないため、新しく取り込まれたパケットをキャプチャすることができません。

Workaround

セッションがParse Threadでスタックしていることを確認する方法

この問題を解決するには、statdbまたはstatHistで以下にリストされている統計値を確認する必要があります。 また、正常ステータスと問題ステータスの両方のパターンを理解する必要があります。 これは、各顧客の環境、受信トラフィック量、ロードされているParserによって異なります。 時間をかけて、正常ステータスのstatdbを確認し、問題ステータスに関する統計を比較してください。

正常ステータスのパターン

• /decoder/stats/pool.packet.capture： ほとんどの場合、これが最大のプールです。 (/decoder/config/pool.packet.pages の約 60 ～ 90% を占めます。Decoderの負荷によって異なります)
• /decoder/stats/pool.packet.assembler：  非常に低い数値
• /decoder/stats/assembler.packet.pages：  これはDecoderで2番目に大きいプールです。（Decoderの負荷によって異なりますが、/decoder/config/pool.packet.pages の10 ～ 40% を占めます。/decoder/config/assembler.pool.ratio に基づいて、デフォルトでは /decoder/config/pool.packet.pages の最大70%を占める可能性があります。）
• /decoder/parsers/stats/queue.sessions.total：  Parsingが完了したらセッションを保存するためにAssembler Threadに返す必要があるため、継続的に 0 になります。

問題ステータスのパターン

(以降、各パラメータ値のフルパスは使用しません)

• セッションがParse Threadでスタックしている場合、queue.sessions.total が 0 にならなくなり始めます。例）継続的に 0 より大きい値になります。
• assembler.packet.pages が、pool.packet.pages の 70% まで増加し始めます。
• assembler.packet.pages が最大値までに達すると、pool.packet.assembler が pool.packet.pages の残りの 30% まで増加し始めます。
• pool.packet.assembler が最大値までに達すると、pool.packet.capture は 0 になります。（pool.packet.pages は共有プールであり、pool.packet.assembler と assembler.packet.pages の両方が pool.packet.pages のほとんどを占有するため、pool.packet.capture に使用できるページがありません。）
• pool.packet.capture が 0 であるため、capture.rate は 0 になります。通常セッションがスタックされてから 10 分以上はかかりません。

 
この現象は、statdb および statHist の出力で確認できます。
                                                                                           

スタックされた問題を解決するために問題のあるParserを特定する方法

• この問題が発生した場合は、DecoderのCore Dumpを取得する必要があります。開発チームからのCore Dump分析により、問題のあるParserを特定できる可能性があります。 ただし、Core Dumpファイルサイズは 一般的に二桁GBであるため、ファイルを転送するのはかなり難しい場合があります。
• Core Dumpの転送が許可されていない場合は最近変更または追加されたParserをリストアップします。 また、一つずつ削除し、Decoderを数日間実行して不正なParserを特定します。
• 事象がNetwitness Live Parserにて稀に発生することがあります。 ただし、ほとんどの場合顧客のCustom Parsersで発生します。
• 開発チームにはCore Dumpを収集するためのgencore.shがあります。 以下の参考リンクをご参照してください。

statdbの収集、調査方法

収集

• Decoderの /var/netwitness/decoder/statdb にあるDecoder statdbファイルを転送するようお客様に依頼します。
• オープンされたDBファイルは問題なくクエリできるため、クローズされたDBファイルを取得するためにDecoderサービスを停止する必要はありません。

調査

• statdbファイルの準備ができたら、検証環境Decoderの /var/netwitness/decoder/statdb にコピーし、Decoderサービスを再起動します。
• statHistを実行するか、http://decoderIP:50104/sdk/app/stats、 http://decoderIP:50104/sdk/app/packetdrops にアクセスできます。

statHistの収集方法

• Decoderのexploreページ /sys/statHist をご参照ください。 NWConsole または Decoder REST Web ページ （http://decoderIP:50104/sys） からアクセスできます。

Resolution

この問題を解決するには、Decoderでセッションがスタックされた原因となっている問題のあるParserをUnloadまたは削除してから、Decoderサービスを再起動する必要があります。

Notes

ベースとなる英語KBは「Decoder Capture Rate Zero on Health & Wellness due to parser stuck in RSA NetWitness Platform  」となりますので、ご参考ください。

Product Details

Netwitness Product Set: NetWitness Platform
Netwitness Product/Service Type: Packet Decoder, Health & Wellness
Netwitness Version/Condition: 10.6.x, 10.5.x, 11.0,11.1,11.2
Platform: CentOS
O/S Version: EL6, EL7

Approval Reviewer Queue

Technical approval queue