エラーセンター¶

Guance エラーセンターは、チームがアプリケーションエラーを体系的に追跡・管理するためのフルスタックソリューションです。パフォーマンスモニタリング、ユーザーアクセス、ログからのエラー情報を自動的に集約し、大量の個別エラーを管理可能なタスクに分類し、完全な分析・処理フローを提供します。

コアコンセプト¶

エラー（Error）¶

APM、RUM、ログから識別される異常イベントの単位であり、エラータイプ、エラーメッセージ、エラースタックの3要素で構成されます。

エラー Issue¶

システムはインテリジェントフィンガープリントアルゴリズムを使用して、同じ根本原因を持つ複数のエラーを単一のエラー Issue（問題単位）に集約します。各 Issue は独立したライフサイクルステータスを持ち、「未割り当て（Triage）」から「解決済み（Resolved）」までの標準的なフローに従い、完全な分析コンテキスト（パフォーマンストレース、ユーザーセッション、ソースマッピング、ログメトリクスなど）が関連付けられます。

エラー転送ロジック¶

エラーセンターはインテリジェント集約メカニズムを使用してエラーデータを一元管理します。システムは、一意の識別子（issue_id）を生成できるエラーデータのみを処理します。この識別子は、エラーフィンガープリントとサービスコンテキストの組み合わせにより生成され、同じエラーの継続的な追跡を保証します。

エラー集約メカニズム¶

システムは以下の手順でエラーのインテリジェント集約を実現します：

1. エラーフィンガープリントの生成

a. システムは各エラーに対して一意のフィンガープリント識別子（fingerprint）を生成します：

b. データ完全性の要件：

エラーフィンガープリントの生成はデータの完全性を前提とします。APM、RUM、ログデータに上記のパスのフィールドが含まれている場合にのみ fingerprint が生成されます。フィールドが欠落している場合、そのデータはスキップされます。

c. 正規化処理：

• フィンガープリント計算前に、システムは正規化処理を実行し、エラーメッセージ（error_message）内の可変部分（タイムスタンプ、ユーザーID、UUID など）を自動的に識別してフィルタリングし、同じ論理エラーのフィンガープリントが一致することを保証します。

• スタック情報（error_stack）は最適化処理され、重要なビジネス呼び出し行のみを保持し、フレームワーク内部呼び出しやサードパーティライブラリ呼び出しをフィルタリングします。

• システムはフィールドの完全性を厳密に検証し、必要なフィールドが欠落しているデータは除外されます。

2. エラー問題識別子（Issue ID の生成）

a. エラーフィンガープリントに基づき、システムはエラーが発生したコンテキストを組み合わせて一意の問題識別子（issue_id）を生成し、エラーセンター内でその問題を追跡・管理します。具体的な生成ロジックは以下の通りです：

• APM エラー：service + fingerprint （サービス名 + フィンガープリント）
• RUM エラー：app_name + fingerprint （アプリケーション名 + フィンガープリント）
• ログエラー：service + fingerprint （サービス名 + フィンガープリント）

b. ライフサイクルの開始：

システムが特定のエラー組み合わせに対して新しい issue_id を初めて生成すると、自動的にワークスペースにその問題の初回発生時刻を記録し、その問題のライフサイクル全体にわたるステータス追跡と集約分析を開始します。

3. エラーデータの保存

代表的なユースケース¶

ユースケース1：バックエンドサービスの異常集約¶

ECサイトの注文サービスがセール期間中に数万件の NullPointerException を発生。従来の方法では、異なる注文 ID を含むためアラートが分散されていました。

解決策：

1. APM エラールールを作成し、order-service を監視します。
2. エラーセンターが自動的にフィンガープリントを抽出し、同じコード位置の例外を単一の Issue に集約します。
3. 開発チームは1つの根本原因の問題のみを処理すればよく、修正後に関連するすべてのアラートが消えます。

👆🏻 「アラートストーム」から「正確な特定」へ、処理効率が大幅に向上します。

ユースケース2：フロントエンドエラーのトレーサビリティ¶

ユーザーから、チェックアウトページで断続的に白画面が発生するが再現できないとの報告。従来のログではユーザー側のコンテキストが不足していました。

解決策：

1. RUM エラールールを設定し、Web アプリケーションのエラーを収集します。
2. エラー一覧で RUM とアプリケーションタイプをフィルタリングし、詳細ページに移動します。
3. 「セッションリプレイ」を表示し、ユーザーの操作パス（クーポンをクリック → 解析失敗 → 白画面）を再現します。
4. エラースタックを確認し、SourceMap が自動的にソースコードの42行目の JSON 解析ロジックにマッピングされます。

👆🏻 「再現不可」から「秒単位での特定」へ、ユーザーエクスペリエンス問題の修正サイクルが日単位から時間単位に短縮されます。

ユースケース3：ログ異常の関連分析¶

アプリケーションログに「Connection Timeout」が頻繁に発生するが、ネットワーク問題かダウンストリームサービスの問題か特定できません。

解決策：

1. ログエラールールを作成し、error_type:DBError を含むログを収集します。
2. エラー詳細ページで「関連トレース」を表示し、トレースエラー詳細でタイムアウトが payment-service の呼び出しで発生したことを確認します。
3. 「インフラストラクチャ依存関係」を表示し、データベース接続プールのモニタリングで接続が枯渇していることを確認します。
4. 根本原因の特定：ネットワーク問題ではなく、ダウンストリームの決済サービスのスレッドプール設定が不十分であることが判明。

👆🏻 「表面的な現象」から「根本原因の特定」へ、誤った判断による無駄な最適化を回避できます。

使用を開始する¶

前提条件¶

使用を開始する前に、データが Guance に接続されていることを確認してください：

• APM：サービスが接続され、trace データが報告されていること

• RUM：Web アプリケーションなどに SDK が統合されていること

• ログ：ログがインデックス化され、エラーフィールドが含まれていること

設定を開始する¶

エラーセンターは設定駆動型で動作します。

1. 使用前に、エラー転送ルールを作成し、監視するデータ範囲（特定のログインデックス、APM サービス、RUM アプリケーション）を明確に指定します。
2. 設定完了後、システムは選択されたデータソースで発生したエラーに対してのみ、インテリジェントな分析と集約処理を実行します。エラー一覧で集約されたエラー Issue を表示し、ステータスやソースでフィルタリングして管理できます。
3. さらにエラー詳細を分析し、個別のエラーを深堀りして、トレース、ログ、セッションを関連付けながら根本原因分析を行うこともできます。