はじめに
Backtrace では、類似性に応じてクラッシュとエラーを自動的にグループ化します。このグループ化により、ユーザー、収益、その他の重要な要素に最も大きな影響を及ぼしているバグは何であるかを効果的に判別できます。このガイドでは、重複排除機能の利点とその内部の詳細について簡単に説明します。
アプリケーションによっては、クラッシュレポートの数が 1 日に数件の場合もあれば、数千に及ぶ場合もあります。トリアージと優先順位付けは、どのユーザーがクラッシュの影響を受けているか、およびそこから派生する可能性がある結果を判別することに依存します。Backtrace では、重複排除と分類を通じてこれらの両方の問題を解決します。
Backtrace では、（ステートマシンをベースにビルドされた）ヒューリスティックアルゴリズムを使用してクラッシュを自動的にグループ化し、同一のクラッシュが 1 つにまとめられるようにします。デフォルトでは、このグループ化により、影響を受けているホストやユーザーの数を判別できるようになります。属性を活用することで、アプリケーションの負荷、影響を受けているバージョンの数などによってトリアージするために、他のメタデータを設定できます。
重複排除メカニズム自体が、トリアージの目的でエンジニアが細かく調査する必要があるバグの範囲を大幅に狭めます。以下に、オペレーティングシステムのカーネルからリアルタイムサーバーまで、実際に稼働しているワークロードからの例をいくつか紹介します。「クラッシュ数（Crashes）」列はクラッシュの生の数値データを表し、「重複排除されたクラッシュ数（Deduplicated Crashes）」列は Backtrace で重複排除されたクラッシュの数を表します。
重複排除はトリアージの 1 つの側面にすぎません。メモリ破損バグやセキュリティホールが存在する場合、ある 1 つのバグは最終的に大規模な DoS（Denial of Service）として顕在化する時限爆弾である可能性があります。Backtrace では、クラッシュのメモリと実行可能コードを分析して、障害を分類します。分類子の詳細については、こちらで確認してください。
重複排除
他のシステムは、障害の一意性を判別するために、単純なコールスタックベースのグループ化アルゴリズムに依存しています。これらのシステムは、処理のきめが細かすぎるか、粗すぎるかのどちらかです。重複排除のきめが細かすぎる場合は、大勢のユーザーに影響を与える同じバグが、小規模なユーザー群に影響を与える多数の一意のバグとして顕在化する可能性があります。重複排除のきめが粗すぎる場合は、バグの影響が膨張し、優先順位付けが正しくなくなってしまいます。
Backtrace の重複排除アルゴリズムの中核を成すのは、プリティプリントと署名生成の両方の目的のために、入力コールスタックを変換することを可能にする、ドメイン固有の言語によって駆動するステートマシンです。これらのコールスタックはそれぞれ異なり、1 つは人間が読みやすいように最適化されており、もう 1 つはグループ化の目的で最適化されています。Enterprise をご利用のお客様は、利用しているアプリケーション用にこれらのルールセットを変更できます。その他の点では、追加設定なしで使用できるグループ化機能をさらに向上させるためのそれらのルールの頻繁な更新のメリットを、クラウド版と Enterprise をご利用のお客様が両方とも享受できます。
機能
Backtrace では、コールスタックのどの部分を使用し、どの部分を無視する必要があるか、および特定のフレーム（行番号、共有ライブラリなど）で使用される情報のレベルなどをインテリジェントに判別するために、動的なシステムが使用されます。
- ライブラリ、プラットフォーム、エラー処理機能、その他のボイラープレートは無視されるか、署名生成を省略します。これにより、クラッシュと関連しないランタイムの非決定性の影響を受けることなく、同じバグが根本原因によって 1 つにグループ化されます。
- コンパイラーによって生成された名前は正規化されます。これにより、同じバグがコンパイル全体で 1 つにグループ化されます。
- プラットフォーム機能で動的ディスパッチの対象となる関数は正規化されます。これにより、さまざまなプロセッサー機能が存在する場合でも、バグが正確にグループ化されます。
- イベントディスパッチャーは正規化されます。これにより、イベントベースのシステムや高度な C++ 機能が活用されているシステムが、クラッシュに関連するコールスタックの非決定性の部分に従って、正確にグループ化されます。
- プラットフォームの特殊化。Backtrace には、コールスタックの関連する部分のみが使用されるように、C++、C、Linux、Windows、macOS および広く普及しているアプリケーションフレームワーク用の高度なルールセットが含まれています。
- コールバックベースのシステム用のオブジェクトバイパス。Backtrace では、コールバックベースのインターフェースを検出し、コールバックの実行につながるボイラープレートを適宜無視することができます。
- このメカニズムはカスタマイズ性が非常に高く、さまざまなことを表現できるため、新しいアプリケーションフレームワークにとっては少数のシンプルなルールがあれば十分です。
Backtrace と従来型の重複排除の比較
最初のアプリケーションフレーム別にグループ化
一部のシステムは、最初のアプリケーションフレームに従ってグループ化されます。これは、内部アプリケーションのエラー処理、外部ライブラリの障害など、さまざまな理由ですぐに崩れ始めてしまいます。どちらかと言えば、そのようなシステムは処理のきめが粗すぎて有用ではありません。ユーザーは区別できません。
program.exe と呼ばれるプログラムを例に挙げてみましょう。クラッシュが発生しているスレッドのコールスタックは abort→application_abort →a →b であり、ここで application_abort は最初のアプリケーションフレームです。競合するシステムは、application_abort でグループ化されます。この関数は、アプリケーションの処理が明示的に中断されるほぼすべてのケースで呼び出され、まったく効果のない重複排除につながります。
このメカニズムは、エラー処理関数だけでなく、一般的に使用されるあらゆる関数でうまく機能しなくなります。たとえば、一般的に呼び出されるユーティリティ関数の失敗につながるバグが発生したとします。これらのシステムでは、呼び出し元ではなくユーティリティ関数別にこれらの障害をグループ化します。
大事なことを言い忘れていましたが、これらのメカニズムによって、非決定性のバグに対してコールスタック分析を実行する機能が無効になります。同じバグに対して何百もの異なるコールスタックが存在する場合があります。Backtrace では、スタックの関連する部分が保持されることで、問題のあるコールスタックに対して高度な統計分析と可視化を実行できます。
Backtrace では、このような状況を回避するために、使用するフレームをインテリジェントに決定します。
コールスタック別にグループ化
その対極にあるのが、純粋なコールスタックベースのグループ化です。このメカニズムは処理のきめが細かくなりすぎて、障害の集約が不正確になる傾向にあります。最新のアプリケーションは、その周囲のプラットフォームライブラリとアプリケーションコードの両方に、高度な非決定性が存在します。イベントベースのシステムでは、同じ関数がイベントループプロセッサーによってさまざまな方法で呼び出される可能性があります。ハング状態がある場合は、さまざまな場所にそのハングが現れる可能性があります。
一部のシステムは、アプリケーションフレームのみを考慮するなどの制限を通じて、これを改善しようとします。結局は障害を集約する目的で重要なアプリケーションライブラリが完全に無視されることになるため、これもうまく機能しなくなります。
Backtrace では、このような状況を回避するために、使用するフレームをインテリジェントに決定します。
エラーの種類や例外メッセージ別にグループ化
一部のシステムは、単純にエラー状態の種類や例外メッセージによってグループ化します。言うまでもなく、これでは現実に発生する障害の大多数にとって不十分です。例外メッセージは、「ユーザーのアクションを実行できませんでした」と同じくらい一般的である可能性があります。グループ化が粗すぎるため、これらのシステムではトリアージや優先順位付けは効果的ではありません。
署名リスト
他のシステムでは、重複排除のために、包含または除外対象の関数の巨大なリストに対してコールスタックベースのグループ化を使用することで、この問題に対処します。残念ながら、これらのシステムには、コンパイラーによって生成された名前、非決定性のコールバックインターフェースなどを処理するのに十分な柔軟性が備わっていません。Backtrace には、頻繁なメンテナンスが必要とされる巨大なリストに頼ることなく、ユースケースの大多数に適合する少数のシンプルなルールを設定できる、柔軟性が備わっています。
ルールを改善するタイミング
システムには、イベントディスパッチスレッドがある高度なマルチスレッドサーバー（スレッド数 5 万超）、Firefox や Chrome などの複雑なデスクトップアプリケーションなど、実際にある複雑なアプリケーションから発生した何十万ものクラッシュから外挿された、汎用のルールが備わっています。新しい顧客がオンボードされるたびに、Backtrace のエンジニアは中核の重複排除アルゴリズムとその周囲のルールセットを継続的に改善するために、障害に対して匿名の統計分析を実行します。
さらに詳しい情報が必要な場合
この機能の詳細については、support@backtrace.io までお気軽にお問い合わせください。