Errors Inboxは、アプリケーションのエラーを効率的に見つけて、トリアージ、そして修正するのにとっても便利なツールです。最大限活用するために変更での影響を確認するだけでなく、「このバージョンで直るよ！」というフラグを上手に使って、変更追跡（Change Tracking）とエラー修正を連携しましょう！
エラー修正フラグとは
APMのErrorsには、グルーピング化されたエラーがどういった状況かを示すステータスフラグ(erros.group.metadata.state)があります。
そして、Change Trackingへのアップデートにより、マーカーにアプリケーションバージョンを合わせてデータとして持つことができるようになりました。
以前はUnresolved（未解決）、Resolved（解決済み）、Ignore（無視する）の3種類となっていました。Errorsにおいてもそのバージョン情報をもとにしていただく、2つのステータスが2024年7月に追加されました。
Resolve in next version
現在実行されているアプリケーションバージョンが更新されると、このエラーは修正されたとみなされます。バージョン情報が更新されない限り、ステータスの挙動はIgnoreと同じとなり、バージョン情報が更新されたあと、同様のエラーが発生した場合にそれはUnresolvedとして扱われます。
Resolve in specific version
現在実行されているアプリケーションバージョンが特定の値の更新された場合に、このエラーは修正されたとみなされます。現在動作しているアプリケーションバージョンのほか、任意の値を指定することができます。
各ステータスの流れは、アップデートでもお知らせいたしましたが、解決状態までにワンクッション増える形となります。
エラー詳細とChange Trackingの活用
Change Tracking機能は以前お知らせした通り実際のデプロイを記録し、変更前後でのパフォーマンス変化を見ていただくなどと言った活用が可能です。同様にErrorに関する指標としても機能し、例えばとあるエラーグループのエラー発生において、バージョンごとでどういった内容になっているかをあわせて確認していただけます。
さらにSee all related deploymentsをクリックすると、Change Trackingのイベント前後でのエラー状況などの変化を数値として確認できます。
まとめ
Change Trackingで記録されたイベントは各機能への情報連携に置いて非常に強力なものとなります。パフォーマンス観測だけではなく、エラーの状況やその変化量なども合わせて見ていただくことで、エラーが何によって引き起こされているのかの把握に繋がります。また、発生したエラーが治るバージョンをあわせて確認できることで、修正作業の見える化やコミュニケーションがスムーズになります。ぜひ活用してみてください。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
