概要
稼働中のシステムでエラーが発生した場合にアプリケーションが出力したログを確認するのが一般的です。New Relic でも Logs の機能を使って同じようにログから発生しているエラーを確認することが可能です。
しかし、New Relicには Errors Inbox という強力な機能があり、類似した複数のエラーをまとめて管理することが可能です。Errors Inbox は、エラーの発生件数やステータス（解決、未解決、無視）、対応する担当者のアサイン状況等を確認することが可能です。まとめて管理することでアプリケーション全体のエラーの発生状況が確認できるため、対処の優先順位付けが容易になります。また、調査が必要なエラーを絞り込んでノイズを減らし、対処すべきエラーに集中することが可能です。
今回New Relicに存在していた Errors Inbox と Erros という2つの機能が新しく Errors（errors inbox） という1つの画面に統合されました。これにより、1つの画面上で Triage と Group Errors のタブを切り替えることにアプリケーションで発生したエラーをユーザーへの影響度合いを基準にランキング形式で確認したり、任意の項目でグルーピングしたりすることでエラーの分析ができるようになっています。
このアップデートの詳細はこちら。
New Relic アップデート(2023年4月)
New Relic アップデート一覧
アップデートされたErrorsのメニューは、New Relic Browser、 New Relic APM の2つです。
それでは実際に機能を確認していきましょう。
どこから確認できるの？
New Relic Browser、 New Relic APM のメニューから Erros の画面を開くことができます。
Triageタブでは何が確認できるの？
Triageでは、アプリケーションで発生したエラーをError Groupにグループ化して表示されるのが特徴です。フィンガープリントが同じ場合にグループ化されます。
従来のErrors Inboxの機能を引き継いでいてエラーグループ毎にエラーの状態を設定したり、担当者を割り当てたりすることが可能です。
以下の赤枠内に表示されているのがエラーの影響を受けているユニークユーザー数です。
ユーザー数のカウントには、New RelicのAPMエージェントやBrowserエージェントが持つカスタム属性の機能を活用しています。カスタム属性の項目名に enduser.id、userId、user が設定されている場合にユーザー数としてカウントされます。カスタム属性の設定方法は、公式ドキュメントやこちらのブログを参考にしてください。
また、enduser.idを設定する関数も公開しています。Qiitaの記事で紹介しているのでこちらも参考にして下さい。
Group errorsタブでは何が確認できるの？
Group errorsでは、エラーのイベントが持つ任意の項目でエラーをグループ化して独自の切り口でエラーを分析できることが特徴です。たとえば、セッション毎やトランザクション毎、ユーザー毎のエラー発生件数を把握することが可能です。
Group byでグループ化するキーになる項目を選択することで一覧に表示されているエラーをグループ化することが可能です。最大5つまで選択が可能です。3つまで一覧に列が追加されますが、4つ目以降は３列目にカンマ区切りで表示されます。
Filter byで属性値をキーとした条件を設定することでエラーのフィルタリングが可能です。クリックすると条件に設定が可能な属性の一覧が表示されます。
Group errorsタブで表示されるエラーの詳細画面には設定したフィルタリングやグループ化の条件を反映されています。また、詳細画面のTriageにはTriageタブで表示されているエラーグループを表示しており、Error group nameからTriageタブのエラー詳細画面を開くことが可能です。
まとめ
今回のアップデートによって、Triageを活用してアプリケーション全体のエラーに対して優先順位をつけた対応が可能になり、Group errorsで特定のエラーに焦点を当てた調査が可能になりました。加えて、Group errorsを活用した特定のエラーをスタート地点とした調査で同様のエラーが発生している状況をTriageの情報とシームレスにつながることでアプリケーションに与えている影響をマクロな視点で捉えることを可能にしています。
エラーを調査する際に、ぜひ一度お試しください。
このアップデートの詳細はこちら。
New Relic アップデート(2023年4月)
New Relic アップデート一覧