Download PDF
Download page エラー検出.
エラー検出
ビジネス トランザクション エラーを示すように構成されたメソッド、ログメッセージ、HTTP コード、またはリダイレクトページを追加または削除することで、AppDynamics がコードイベントをビジネス トランザクション エラーに関連付ける方法をカスタマイズできます。
アクセス権
エラー検出を構成するには、「Configure Error Detection」権限が必要です。
エラー検出構成
エラー検出構成は、[Error Detection] タブで表示または変更できます。コントローラ UI で、アプリケーションを開き、[Configuration] > [ Instrumentation] > [Error Detection] に移動します。
[Error Detection] タブで、各プログラミング言語またはプラットフォームの構成可能なオプションが表示されます。各言語またはプラットフォームにそれぞれ設定を構成します。一部の設定は、プラットフォームによって異なります。たとえば、カスタムロガーやリダイレクトページを使用するエラー検出は Java と .NET のみで使用できます。[Error Detection] タブで行った構成変更は、選択したアプリケーションのすべてのビジネストランザクションに適用されます。個々のトランザクションに変更を加えることはできません。
トランザクションをエラーとしてマーキングしないようにするには、該当する言語またはプラットフォームごとに Mark Business Transaction as error をオフにします。オフの場合、トランザクションはエラーカウントメトリックに追加されず、エラーが発生している場合でも応答時間などの他のメトリックで考慮されます。
エラー検出の補完
Java および .NET では、AppDynamics が一般的なエラー処理フレームワークのエラーメソッドとみなすメソッドを、カスタムロガーを定義することで独自にカスタム定義するエラーメソッドを使用して補完することができます。アプリケーションがビジネストランザクションでこのメソッドを呼び出すと、AppDynamics はメトリックのためにトランザクションをエラートランザクションとみなします。
カスタムロガー構成では、メソッドに渡される例外またはエラー情報を含むパラメータを指定できます。この情報は AppDynamics のエラーメッセージとして表示されます。AppDynamics はパラメータで toString() を呼び出してメッセージを抽出します。
カスタムロガーを構成するには、次の手順を実行します。
- コントローラ UI の [Error Detection] 構成タブで、エラー構成パネルの [Add Custom Logger Definition] をクリックします。
- カスタムロガー定義の概要名を入力し、設定を使用してカスタムロガーのクラス名とメソッドを特定します。AppDynamics UI を使用してクラスとメソッドを識別する方法の詳細については、「データコレクタ」を参照してください。
- [Method Parameter] フィールドで、メソッドの署名の各パラメータにパラメータ定義を追加します。
メソッドがオーバーロードしている場合は、エラーを検出するオーバーロードしたメソッドの形式ごとにロガー定義を作成してください。カスタムメソッドは、少なくとも1つのパラメータを受け入れる必要があり、そのパラメータはログに記録されたエラーまたは例外情報を伝えるものである必要があります。 - [Exception Parameter] フィールドには、例外オブジェクトが含まれているメソッド署名のパラメータをインデックス番号（0 ベース）で指定します。
インデックスによって識別されるこのパラメータは、配列を含む任意のタイプのオブジェクトにできます。オブジェクトが null でない場合、AppDynamics はこのオブジェクトを文字列に変換します。これによりエラー詳細を生成します。ビジネストランザクションは、null 以外の例外オブジェクトがロガーメソッドに渡された場合にのみエラーと見なされます。
.NETアプリケーションにおける以下のカスタムロガークラスとメソッドについて考えてみましょう。
- 名前空間とクラス = Logging.MyLogger
logger.Error(string message, int param1)logger.Error(string message, int param1, int param2)
エラーメソッドがオーバーロードしていることに注目してください。ログに記録するエラーとして最初のパラメータを使用し、メソッドの 2 番目の形式で記録されたエラーをキャプチャします。次のスクリーンショットは、この設定を示しています。
例外パラメータが 0 に設定されているため、string message メソッドパラメータがエラーメッセージとして識別されます。有効にすると、AppDynamics はカスタムロガーを検出して報告します。
HTTP応答またはリダイレクトページをエラーとして検出
Java、.NET、Node.js、およびPythonでは、HTTP応答コードに基づいてエラーを設定できます。エラーコードがビジネストランザクションの処理の一部として設定されている場合、トランザクションはエラーとしてマークされます。PHP では、PHP エージェント構成設定を使用して 4xx HTTP リターンコードに基づいて、トランザクションをエラーで分類できます。
デフォルトでは、AppDynamicsは400～505のHTTPエラーコードを取得します。HTTP応答コードは、アプリケーションのビジネスレベルで発生するエラーを伝えている場合があります。たとえば、e コマースアプリケーションでは 522 エラーで商品の在庫がないことを示すとします。この場合、エラーをデフォルトのトランザクションエラーインジケータとして含めることができます。
リターンコードを除外するには、カスタムエラーコード範囲を作成し、[Enabled] チェックボックスをオフにしてそのエラーコードを無効にし、エラー検出リストに追加します。これは事実上エラーコードをエラーインジケータとして除外していることになります。
Java および .NET エージェントの場合は、カスタム リダイレクト ターゲット エラー ページをエラーインジケータとして指定できます。リダイレクトページを指定するには、[Add Error Redirect Page] をクリックして構成名とページ（「AcmeErrorPage.jsp」など）の URL と照合する正規表現を追加します。
エラーインジケータとしての例外とログメッセージの無視
トランザクション エラー インジケータとしての特定タイプの例外、ロガー、またはログメッセージは、ご使用の環境でトランザクションエラーとしてカウントする必要があるイベントと見なされない場合があります。これらには、アプリケーション フレームワーク コードまたはユーザログインの失敗により発生した例外が含まれる場合があります。
例外を無視するよう構成すると、エージェントは例外を検出して例外カウントを増やし、UI の例外リストに表示しますが、エラーが発生したビジネストランザクションはモニタリングの観点から言うと「エラートランザクション」とは見なされません。トランザクション スナップショットは、[Summary] または [Error Details] セクションには例外を表示せず、トランザクション インスタンスのユーザエクスペリエンスに例外の影響はありません。
エージェントが無視する例外を構成するには、エラー構成ウィンドウの [Add New Exception to Ignore] ボタンをクリックします。
無視する例外のクラス名と例外メッセージのマッチ条件を入力します。マッチ条件では、例外の特定のメッセージにフィルタが必要ない場合、[Is Not Empty] を選択します。Null をフィルタリングする場合は、[Is Not Empty] を選択し、歯車アイコンを使用して [NOT] を選択します。これは実際には [is empty] をテストします。
[Match Condition for Exception Message] のテキストフィールドに "、<、>、および & を含めることはできません。
以下の例では、ルート例外の exception.getMessage() コールに文字列「format」が含まれている場合のみ、javax.sql.SQLException をラップする java.lang.RuntimeExceptions を無視するようエージェントに指示します。（他の java.lang.Runtime 例外は無視されません）。
例外チェーンにより無視する例外のクラスを定義する場合、一致条件が適用される例外メッセージはチェーンのルート例外に含まれている必要があります。一致条件はネストされた例外には適用されません。
.NETおよびJavaでは、特定のロガーまたはロガーカテゴリーで記録されたエラーを無視するよう指定できます。[Add New Category/Logger to Ignore] をクリックします。
エラー検出に関するヒント（プラットフォーム別）
以下のセクションでは、アプリケーション プラットフォームごとのエラー検出構成およびエラーモニタリングにおいて考慮すべき事項を記述します。
.NETのエラー構成
デフォルトでは、Windows .NET エージェントは NLog および Log4Net を使用してコールをインストゥルメント化できます。また、システムトレースとイベントログから情報を収集することもできます。Linux の 4.5.19 以降のエージェント、および Windows の 21.2.0 以降のエージェントでは、.NET Core で動作するエージェントは、Microsoft.Extensions.Logging.ILogger API を実装するロガーを使用してコールをインストゥルメント化することもできます。他のロガーを使用してコールをインストゥルメント化するには、カスタムロガー定義を追加します。「Configuring a Custom Logger」を参照してください。
ERRORより上位に記録されたメッセージには、CRITICALやFATALなどの重大なレベルが存在します。
システムトレースまたはイベントログエラーがモニタされないようにするには、該当するボックスをオンにして、それらを無効にします。システムトレースエラーは、TraceError を介してリスナー収集にエラーメッセージとして書き込まれたものです。
イベントログエラーは、種類がエラーに設定されている場合にEventLogに書き込まれます。例：
myEventLog.WriteEntry(myMessage, EventLogEntryType.Error, myID);
PHPのエラー構成
PHPエージェントは、PHPレポート機能をインストゥルメント化します。PHPアプリケーションはtrigger_errorを使用し、その機能を通じてエラーを報告することができます。PHP拡張機能とPHP自体もPHP機能を使用してエラーを報告することができます。
デフォルトでは、エージェントは複数のしきい値を使用してPHPエラーをチェックします。
- Errorを選択すると、エージェントはメッセージおよびErrorとマークされた例外のみを報告します。
- Warningを選択すると、エージェントはメッセージおよびError、Warningとマークされた例外のみを報告します。
- Noticeを選択すると、エージェントはメッセージおよびError、Warning、またはNoticeとマークされた例外を報告します。
Node.jsのエラー構成
Node.jsエージェントは、Node.jsアプリケーションまたはNode.js自体により発生した例外を報告します。
「Ignored Exceptions」および「Ignored Messages」リストを使用して、トランザクションがエラーと報告されないように特定の例外やログメッセージを構成することができます。詳細については、「Ignoring Exceptions and Log Messages as Error Indicators」を参照してください。
Pythonに関する備考のエラー構成
デフォルトでは、Python エージェントは未処理の例外、400 番以上の HTTP ステータスコード、および Python ログモジュールが ERROR レベル以上で記録するメッセージについてエラートランザクションを報告します。
記録されたエラーが原因でトランザクションがエラーとして報告されないようにするには、[Mark Business Transaction as error] チェックボックスをオフにします。ログに記録されたメッセージをまったくキャプチャしない場合は、[Detect Errors] チェックボックスをオフにします。
「Ignored Exceptions」および「Ignored Messages」リストを使用して、トランザクションがエラーと報告されないように特定の例外やログメッセージを構成することができます。詳細については、「Ignoring Exceptions and Log Messages as Error Indicators」を参照してください。