　New Relic の APM の設定をカスタマイズして、アプリケーションのエラー管理を最適化する方法をご紹介します。

　New Relic の強力なエラー管理機能の中心となるのが Errors Inbox です。Errors Inbox を活用すれば、エラーが自動的にグループ化され、いつ、どのエラーが、何件発生したのか、どの程度のユーザーが影響を受けているのか、エラー発生時のスタックトレースはどうなっているのかなど、エラーに関するあらゆる情報を一元的に管理できます。これは、日々発生するアプリケーションのエラーの海から、本当に対応すべき重要なエラーを見つけ出すための羅針盤のような存在です。

　しかし、アプリケーションのエラーの中には、APM で自動的に収集されないもの、監視不要なもの、あるいは発生が予期されているものも含まれています。これらのエラーを適切に設定しないと、Errors Inbox がノイズで溢れかえったり、重要なエラーを見逃したりする原因になりかねません。だからこそ、管理対象のエラーをどのように収集し、フィルタリングするかを最適化することが、エラートラッキングの効率を大きく左右するのです。

　この記事では、エラーを収集・管理する設定をカスタマイズすることで、エラー管理をより効率的に行うための具体的な方法を、以下の3つのポイントに絞ってご紹介します。

今回のポイント

この記事で紹介しているポイントは、次の 3 つです。

APM で収集されないエラーを収集する方法を知る
try-catch 等でエラーハンドリングを行っている場合に明示的にエラー情報を New Relic へ連携する方法を紹介します。
無視するエラーを管理する方法を知る
開発環境特有のエラーや、既知の無害なエラー、ボットによるアクセスなど、監視が不要なエラーを New Relic が報告しないようにする設定方法です。これにより、Errors Inbox のノイズを減らし、本当に対応すべきエラーに集中できます。
発生が予期されるエラーを管理する方法を知る
ユーザーの入力ミスによるバリデーションエラーや、意図的なリソース NotFound など、発生が想定されているエラーを、New Relic の主要なメトリクス（エラー率や Apdex スコア）に影響を与えずに管理するための設定方法です。これにより、エラーの発生件数を把握しつつも、アプリケーションの健全性指標を正確に保つことができます。

最新のアップデートの詳細はこちら
New Relic アップデート一覧

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！

APM で収集されないエラーを収集する方法

どんな時にエラーが収集されないのか

以下のようなケースでは、APM エージェントは自動的にエラーを収集しません。

サポートされていないフレームワークを使用している場合
　New Relic が公式にサポートされているフレームワークやライブラリを使用している場合、エージェントはエラーを検知できません。

try-catch 等でエラーハンドリングを行い、ステータスコード 200 で応答を返している場合
　アプリケーションのビジネスロジックで例外を捕捉し、ユーザーには正常な応答（例: ステータスコード 200 OK とエラーメッセージ）を返している場合、APM エージェントはそれを「処理されたエラー」として認識しないため、New Relic にはエラーとして報告されません。これは、エージェントが「アプリケーションが意図した通りに動作している」と判断するためです。例えば、ユーザーが存在しない場合に「ユーザーが見つかりません」というメッセージを返し、HTTP ステータスコードを 200 OK にした場合などがこれに該当します。

　このような場合でも、ビジネス上重要なエラーとして記録し、監視したいケースは多く存在します。その場合、エラーハンドリングを行う共通処理の中で、明示的にエラーデータを New Relic にレポートする必要があります。

どのようにしてエラーデータをレポートするのか

　エラーデータを明示的に New Relic にレポートするには、各 APM エージェント固有の API をコールします。これにより、アプリケーションが捕捉したエラーを New Relic のエラーとして記録できます。

　それぞれの API をコールすることで、エラーデータを New Relic に連携できます。

　例えば、PHP のアプリケーションで try-catch のエラーをハンドリングし、New Relic へエラーデータを連携するコードは以下のようになります。

newrelic_notice_error()

try {
    // 例外が発生するアプリケーションの処理
} catch (UserNotFoundException $e) {
    newrelic_notice_error($e);
    // 通常のエラーハンドリング
}

　この例では、UserNotFoundException が発生し try-catch で捕捉されても、newrelic_notice_error($e) を呼び出すことで New Relic にエラーとして記録されます。これにより、アプリケーションの内部で正常に処理されたエラーであっても、その発生状況を New Relic で追跡できるようになります。

　Node.js のサンプルアプリケーションも提供されているためご確認ください。

無視するエラーを管理する方法

　アプリケーション運用において、監視する必要のないエラーや、New Relic のエラーリストにノイズとして表示されるエラーが存在します。例えば、開発環境でのみ発生するテスト用のエラー、特定のサードパーティライブラリが頻繁に出力する無害な警告、あるいはボットによる不正なアクセス試行による 404 エラーなどが挙げられます。

　これらの管理不要なエラーを APM エージェントが報告しないように設定することで、Errors Inbox のノイズを減らし、本当に対応すべき重要なエラーに集中できるようになります。これにより、エラートラッキングの効率が大幅に向上し、アラート疲労も軽減されます。

設定の方法は大きく 2 つに分けられます。

エージェント設定（設定ファイルまたは環境変数）
　各アプリケーションサーバー上に配置するエージェントの設定ファイル（例: newrelic.yml, newrelic.ini）や、環境変数で設定します。
UI のサーバーサイドコンフィグレーション
　New Relic の UI 上から APM エージェントの設定を変更できる機能です。これにより、複数のホストやインスタンスにまたがる APM エージェントの設定を一元的に管理し、すべてのエージェントに適用することが可能です。大規模な環境で設定変更をデプロイする手間を省き、迅速に適用したい場合に非常に便利です。

PHP エージェントはサーバーサイドコンフィグレーションに対応していない点に注意してください。

各 APM エージェント毎に無視する設定の項目、設定できる項目が異なります。

Error Class による設定

　特定のエラークラス（例外の型）を無視します。例えば、com.example.IgnorableException というクラスのエラーは無視したい、といった場合に利用します。

Go：なし
Java：error_collector.ignore_classes
.NET：ignoreClasses
Node.js：ignore_classes
PHP：newrelic.error_collector.ignore_exceptions
Python：error_collector.ignore_classes
Ruby：error_collector.ignore_classes

java の APM エージェントで設定する場合は下記のようになります。

java の ignore_classesの設定

error_collector:
  ignore_classes:
    - "com.example.MyException"
    - "com.example.DifferentException"

　この設定により、com.example.MyNoisyException や com.example.ThirdPartyWarning といった特定のエラークラスは New Relic に報告されなくなります。

Error Message による設定

　特定のエラーメッセージ内容を無視します。
　例えば、「The token has expired.」という警告メッセージは無視したいが、同じクラスの他のエラーは収集したい場合に利用します。

Go：なし
Java：error_collector.ignore_classes.message
.NET：ignoreMessages
Node.js：ignore_messages
PHP：なし
Python：なし
Ruby：error_collector.ignore_messages

java の APM エージェントで設定する場合は下記のようになります。

java の ignore_messasesの設定

error_collector:
  ignore_messages:
    com.example.MyException:
      - "Some error message to ignore"
      - "Some other error message to ignore"
    com.example.DifferentException:
      - "Some different error message to ignore"

　この設定では、com.example.MyException の中で "Database connection failed" や "Temporary network issue" というメッセージを含むエラー、または com.example.ExternalApiException の中で "Rate limit exceeded" というメッセージを含むエラーが無視されます。

Status Code による設定

　特定の HTTP ステータスコードをエラーとして扱わないようにします。
　例えば、Web サーバーへの不正なアクセスによる 404 (Not Found) エラーや、一時的なサーバーの過負荷による 503 (Service Unavailable) エラーなど、頻繁に発生し、かつ自動的には対応不要なステータスコードを監視から除外できます。

Go：ErrorCollector.IgnoreStatusCodes
Java：error_collector.ignore_status_codes
.NET：ignoreStatusCodes
Node.js：ignore_status_codes
PHP：なし
Python：error_collector.ignore_status_codes
Ruby：error_collector.ignore_status_codes

java の APM エージェントで設定する場合は下記のようになります。

java の ignore_status_codes の設定

error_collector:
  ignore_status_codes: 404,507-511

　この設定により、HTTP ステータスコードが 404、および 507 から 511 の範囲のエラーは New Relic に報告されなくなります。

Error Level による設定 (PHPのみ)

　PHP エージェントでは、PHP の error_reportingオプションと同様の構文を使用して、特定のエラーレベルを無視できます。例えば、E_WARNING や E_NOTICE など、アプリケーションの動作には直接影響しないがログに出力されるレベルのエラーを無視できます。

Go：なし
Java：なし
.NET：なし
Node.js：なし
PHP：error_collector.ignore_errors
Python：なし
Ruby：なし

PHP の APM エージェントで設定する場合の例:
　newrelic.ini ファイルに以下の設定を追加します。PHP の error_reporting オプションと同様に、定数名（例: E_WARNING, E_ERROR）をビット演算子 (|) で組み合わせて指定できます。

php の error_collector.ignore_errors の設定

newrelic.error_collector.ignore_errors = E_WARNING | E_ERROR

　この設定により、E_WARNING と E_NOTICE レベルのエラーは New Relic に報告されません。必要に応じて、数値を直接指定することも可能です（例: newrelic.error_collector.ignore_errors = 8192 | 1024）。

発生が予期されるエラーを管理する方法

　アプリケーションのエラーを New Relic にレポートして管理したいが、同時にアプリケーションのエラー率や Apdex スコアといった主要な健全性メトリクスに悪影響を与えたくない場合があります。このようなケースで役立つのが、「予期されたエラー (Expected Errors)」としてフラグを有効化する設定です。

予期されるエラーの例としては、以下のようなものが挙げられます。

ユーザーの入力ミスによるバリデーションエラー
　例えば、不正な形式のメールアドレスが入力された場合。
意図的なリソース NotFound
　ユーザーが削除したコンテンツや存在しないパスにアクセスした場合の 404 エラーなど。
認証失敗
　不正なログイン試行など、ユーザーが意図的に失敗させた場合。

　これらのエラーは、アプリケーションのビジネスロジックとしては「エラー」として扱われるものの、システム自体が予期せぬ障害に陥っているわけではありません。むしろ、ユーザーの操作の結果として意図的に発生させているものです。

　New Relic では、error.expected という属性があり、デフォルトでは false が設定されています。この設定を有効化すると、該当するエラーには error.expected が true に設定されます。

　この設定の大きな利点は、Errors Inbox の初期表示で error.expected = false でフィルターされているため、本当に対応すべき「予期せぬエラー」に集中できる点です。また、最も重要なのは、error.expected = true とマークされたエラーは、 APM のエラー率や Apdex スコアの計算には含まれない という点です。これにより、アプリケーションの健全性を示す主要なメトリクスを正確に保ちつつ、予期されるエラーの発生状況も監視できます。

Error Class による設定

特定のエラークラスを予期されるエラーとして扱います。

java の APM エージェントで設定する場合は下記のようになります。

java の expected_classesの設定

error_collector:
  expected_classes:
    - "com.example.MyException"
    - "com.example.DifferentException"

これにより、com.example.UserNotFoundException や com.example.InvalidInputException は予期されるエラーとして扱われ、エラー率や Apdex スコアには影響しなくなります。

Error Message による設定

特定のエラーメッセージ内容を予期されるエラーとして扱います。

Go：なし
Java：error_collector.expected_messages
.NET：expectedMessages
Node.js：expected_messages
PHP：なし
Python：なし
Ruby：error_collector.expected_messages

java の APM エージェントで設定する場合は下記のようになります。

java の expected_messagesの設定

error_collector:
  expected_messages:
    com.example.MyException:
      - "Some expected error message"
      - "Some other expected error message"
    com.example.DifferentException:
      - "Some different expected error message"

　この設定では、com.example.InvalidInputException の中で "Invalid email format" や "Password does not meet requirements" というメッセージを含むエラー、または com.example.ResourceNotFoundException の中で "Requested item not found" というメッセージを含むエラーが予期されるエラーとして扱われます。

Status Code による設定

特定の HTTP ステータスコードを予期されるエラーとして扱います。

Go：ExpectStatusCodes
Java：error_collector.expected_status_codes
.NET：expectedStatusCodes
Node.js：expected_status_codes
PHP：なし
Python：error_collector.expected_status_codes
Ruby：error_collector.expected_status_codes

java の APM エージェントで設定する場合は下記のようになります。

java の expected_messagesの設定

error_collector:
  expected_messages:
    com.example.MyException:
      - "Some expected error message"
      - "Some other expected error message"
    com.example.DifferentException:
      - "Some different expected error message"

この設定により、HTTP ステータスコードが 401 (Unauthorized)、403 (Forbidden)、404 (Not Found) のエラーは予期されるエラーとして扱われます。

まとめ

　New Relic の APM を活用したエラー管理は、単にエラーを「見つける」だけでなく、「適切に分類し、対応する」ことで真価を発揮します。この記事では、以下の 3 つの重要なカスタマイズ方法を紹介しました。

◾️APM で収集されないエラーを NoticeError() API で明示的に収集する
　これにより、try-catch で捕捉され、アプリケーションが正常に処理したと判断されるビジネスロジック上の重要なエラーも、New Relic で一元管理できるようになります。

◾️管理不要なエラーを無視する設定を行う
　ノイズとなるエラーを除外することで、Errors Inbox がクリーンに保たれ、本当に対応すべき緊急性の高いエラーに集中できるようになります。

◾️発生が予期されるエラーを error.expected = true としてマークする
　これにより、ユーザーの操作に起因する予期されたエラーを監視しつつも、アプリケーションのエラー率や Apdex スコアといった主要な健全性メトリクスが正確に保たれます。

収集したエラーの確認方法はこちらの記事も参考にしてください。

　New Relic は、アプリケーションのパフォーマンスだけでなく、エラー管理においても強力なツールです。これらのカスタマイズ設定を適切に行うことで、より効率的でストレスの少ないエラー管理を実現し、アプリケーションの品質向上と安定稼働に貢献できるでしょう。

　New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！

New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！