エラーをグルーピングして障害対応の優先順位付けを効率化！

# 概要

　New RelicのErrors inboxは、発生しているエラーの件数や時系列の推移、Stack Traceなどの情報を簡単に確認することが可能です。また、発生したエラーをグループ化して表示してくれるため、対応の優先順位付けが容易になります。

　今回のアップデートでデフォルトでは自動的に分類されるエラーグループをカスタマイズする方法が提供されました。

:::note info
このアップデートの詳細はこちら。
[New Relic アップデート(2023年3月)](https://newrelic.com/jp/blog/nerdlog/new-relic-update-202303 "New Relic アップデート(2023年３月)")
[New Relic アップデート一覧](https://newrelic.com/jp/blog/nerdlog/new-relic-update "New Relic アップデート一覧")
:::

:::note info
[New Relic株式会社のQiita Organization](https://qiita.com/organizations/newrelic)では、新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
:::


# 設定手順

　Rubyアプリケーションを例に紹介します。エラーのグルーピング設定は非常に簡単です。
まずはドキュメントを確認していきましょう。

https://docs.newrelic.com/jp/docs/apm/agents/ruby-agent/api-guides/sending-handled-errors-new-relic/#error-fingerprinting

```ruby:Ruby サンプルコード
proc = proc { |hash| "Access" if hash[:'http.statusCode'] == 401 }
NewRelic::Agent.set_error_group_callback(proc)
```
　コールバック関数を使用して、独自のエラーグループを設定します。コールバック関数はProc型で定義する必要があり、その関数をset_error_group_callbackの引数として渡しています。この処理は、エラーの発生する都度実行するわけではなく、RubyのAPMエージェントが起動する毎に１度だけ実行する必要があります。そのため、初期化のタイミングで実行するのが良いでしょう。

　指定されたグループは、エラーイベントの error.group.name 属性として追加される仕様です。上記の例の場合はステータスコードが401のエラーの場合にエラーグループ名が”Access”となります。

## 実装
　実際にこの関数を使ってみましょう。

```ruby:application.rb
errorcallback_proc = Proc.new do |hash|
  # http.statusCode エラーメッセージの定義
  messages = {
    401 => "Unauthorized: Access is denied due to invalid credentials.",
    404 => "Not Found: The requested resource could not be found.",
    500 => "Internal Server Error: The server encountered an error.",
    503 => "Service Unavailable: The server is currently unable to handle the request."
  }

  # hashからステータスコードを取得して対応するメッセージを返す
  messages[hash[:'http.statusCode']] || "Unknown Error: An unexpected error occurred."
end

NewRelic::Agent.set_error_group_callback(errorcallback_proc)

```
　APMエージェントが起動する毎に１度だけ実行する必要があるため、Ruby on Railsのアプリケーションを実行した際に実行される `application.rb` にコードを追記しました。ステータスコードをキーとして使用し、それぞれにエラーメッセージを設定してエラーグループの名称として使用します。

# 確認
 それでは設定されている内容を確認していきましょう。
 
## エラーグループがカスタマイズされている
　それではエラーが発生した際のエラーグループがカスタマイズされて、Errors（errors inbox）のTriageタブに表示されていることを確認していきましょう。
　New Relic APMの画面でメニューからErrors（errors inbox）を開きます。設定したエラーグループは、Errors inbox の Triage タブで確認できます。
　　![Errors_inbox.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3043202/3853c050-8b0b-6532-96cd-3cd30cfae0d9.png)
　赤枠で囲んだエラーグループがカスタマイズしたエラーです。`Custom error group`というタグがついており、カスタマイズされていないものと区別されています。

# まとめ
　本記事では、発生したエラーのグルーピングをカスタマイズすることで New Relic の Errors inbox でのエラーの分析をより効果的に実施できるようになります。また、下記の記事で紹介している**エラーのユーザーへの影響度合い**の情報と組み合わせることでより詳細なエラーのトリアージが可能です。

https://qiita.com/MarthaS/items/3086b891683fd121b571

　今回はエラーが発生した際のステータスコードをキーにしてグルーピングをカスタマイズしましたが、**エラークラス**や**リクエストURI**をキーすることも可能です。Rubyのカスタムエラークラスやエラーが発生しているリクエストのURIの情報と組み合わせることで優先度の高いエラーを短時間で判断できるようになるでしょう。

# 参考情報
　本記事で紹介したエラーグループのカスタマイズ方法は、言語毎に設定方法が異なります。各言語毎の設定方法は下記のリンクからご確認ください。

### Go言語

https://docs.newrelic.com/docs/apm/agents/go-agent/api-guides/guide-using-go-agent-api/#error-fingerprinting

### Java

https://docs.newrelic.com/docs/apm/agents/java-agent/api-guides/guide-using-java-agent-api/#additional

### Node.js

https://docs.newrelic.com/docs/apm/agents/nodejs-agent/api-guides/nodejs-agent-api/#setErrorGroupCallback

### .Net

https://docs.newrelic.com/docs/apm/agents/net-agent/net-agent-api/seterrorgroupcallback-net-agent-api/

### Python

https://docs.newrelic.com/docs/apm/agents/python-agent/python-agent-api/seterrrorgroupcallback-python-agent-api/

### Ruby

https://docs.newrelic.com/jp/docs/apm/agents/ruby-agent/api-guides/sending-handled-errors-new-relic/#error-fingerprinting

:::note info
このアップデートの詳細はこちら。
[New Relic アップデート(2023年3月)](https://newrelic.com/jp/blog/nerdlog/new-relic-update-202303 "New Relic アップデート(2023年３月)")
[New Relic アップデート一覧](https://newrelic.com/jp/blog/nerdlog/new-relic-update "New Relic アップデート一覧")
:::

:::note info
[New Relic株式会社のQiita Organization](https://qiita.com/organizations/newrelic)では、新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
:::