New Relic ならではの機械学習を活用したエラー分析機能エラープロファイルとは

New Relic Advent Calendar 2017 8日目。New Relic APM のエラー分析の新機能のご紹介。

![スクリーンショット 2017-12-08 22.19.31 (1).png](https://qiita-image-store.s3.amazonaws.com/0/46003/b6506fba-85d3-8d9f-b20e-73440e36ed1d.png)

みんな New Relic APM のエラー分析機能使ってる? いつも皆使っている機能なんだろうかと思ってはいる。うちとかだとエラー管理は別サービスを使っているし。(エラーが発行されたタイミングで Slack に通知してほしかったりするけど、New Relic のエラー管理ではそれはできないので）

なんだけど、今回紹介する新機能の **エラープロファイル** (2017年9月ころリリース)は、New Relic ならではの機能となっている。何がならではかっていると、エラー以外のパフォーマンスやトランザクションデータを持っているってことを活用した機能になっているってとこ。エラー管理に特化したサービスにはそれはできないからね。

どういうものかって言うと、昨今 New Relic が力をいれている機械学習を利用した機能。New Relic が普段から収集している膨大なトランザクションデータ(エラーも含む)を使って、これまでは人が推測していたエラーに共通したパターンを自動的に学習し、提示してくれる。問題特定の最初の調査時間を大幅に削減してくれるかもしれない。

どんなものかはこれから説明していく。その前に現状を説明。

## これまでのエラー分析機能でできたこと

今までの New Relic APM の[エラー分析(Error Analytics)機能](https://newrelic.degica.com/docs/apm/applications-menu/error-analytics/error-analytics-compatibility-requirements)は、 サーバーアプリの未キャッチ例外を New Relic 上でリスト化し、指定した時間帯に発生した例外をエラークラス/メッセージ/トランザクション別などで絞り込んで、エラー分析を効率化してくれる機能がある。もちろん個々のエラーのスタックトレースなどエラー詳細も確認できます。

![screen-error-analytics-3day.png](https://qiita-image-store.s3.amazonaws.com/0/46003/df6f8fa1-b680-1943-e6c1-7b76e4d28841.png)
トランザクション別にエラー回数を表示している例

このように発生した例外を効率良く分析、絞り込める機能があるのが、Error analytics 。これについて知りたい方は、[ここの記事](https://qiita.com/kumatronik/items/72880fac183f432ab333)をご覧ください。

## エラープロファイル機能でできるようになったこと

そこに新たに追加されたのがエラープロファイル(Error profiles)。エラーの原因特定が効率良く行えるようにサポートする機能。ただ、上記と違うのが、最初にも書いたけど、エラーだけでなく正常のリクエストデータも機械学習にかけ、エラーのリクエストと正常のリクエストを比較し、エラーとなる傾向の強いリクエストパターンを提示してくれるということ。

エラーが発生したときに、エラーだけ見ていても、なぜそのエラーがその時に発生したのか分からないことがある。そういった場合、このエラーが発生した状況(同じトランザクションだったり、同じリクエストヘッダーだったり）は、通常のリクエストと違いはないのか？と気になることがある。そこで、エラーにのみ特有のパターンがあれば、通常のリクエストとの違いの部分がエラーの原因や原因の一部なのではないかとあたりがつく。そういう点で、通常のリクエストと比較することは意味のある行為であり、エラーの原因特定までの道のりを短縮してくれるツールとなり得る。

というふうに、通常のリクエストとエラーのリクエストの差(偏差）が大きいものを重要度高として、リスト化してくれる機能がエラープロファイル。

以下のように発生したエラーに対するパターンを提示してくれる。（見ても意味のない項目も結構あるけど)

エラープロファイルは、選択している時間帯(Time Picker)とフィルタリングで絞られたエラーを対象に、通常のリクエストとの差を表示する。

![apm-error-profiles.jpg](https://qiita-image-store.s3.amazonaws.com/0/46003/cab61bad-9e71-a25a-eeab-928c4636f756.jpeg)

この場合、一番上は、`Error Class` が対象となっていることがわかる。その下に `All of these errors have error class "HttpServerError 500"` とメッセージがある。発生した全エラーは 500 エラーだったと言っている。このように、指定している時間帯に発生したエラーで、どういった傾向があるのか簡略化したメッセージで教えてくれる。(ただ、エラークラスとか２番目のエラーメッセージとかは、エラーにしかない項目なので、役に立つ情報かは微妙）

ここで意味が大きいののは、通常のリクエストと共通の属性(トランザクションやリクエストヘッダーなど）だと思う。

![apm-error-profiles-2.jpg](https://qiita-image-store.s3.amazonaws.com/0/46003/2545f954-cd6e-6ad2-03cc-a01b0d162652.jpeg)

また、特にこの機能で価値が大きいのが、カスタム属性を使っている場合なのではないかと個人的には思う。[NRQL のアラート](https://qiita.com/kumatronik/items/21397bce4f2a81486035)でも紹介した[カスタム属性](https://newrelic.degica.com/docs/insights/insights-data-sources/custom-attributes/insights-custom-attributes-apm-agents)とは、New Relic が自動的に収集するデータ以外の任意のデータを収集してくれるようにできるもの。(コードに手をいれる必要があるが)

言語によってAPIが変わるが、Ruby だとこんな感じ。他の言語でも同じ感じ。ここでは、ストアIDという情報を送っている。

```ruby
NewRelic::Agent.add_custom_attributes({ store_id: "xxxx" })
```

このようにストアIDを送っていた場合、このエラープロファイルでもストアIDは監視対象になる。よって、全体のリクエストに対して、特定のストアだけエラーがよく起こるなどが提示されたりする。これによって、そのストアの作りとかデータとかにエラーを誘発する原因があるのでは？と考えるきっかけとなる。これは実際には違うかもしれないが、こういうデータがないと、そもそもそのように思いさえしないので、重要な情報である。

## エラープロファイルの使い方(アクセスの仕方）

ここまででエラープロファイルがどういう機能か分かってもらえたと思う。では、具体的にどうやって使う(アクセスする）かを紹介します。

![test1.gif](https://qiita-image-store.s3.amazonaws.com/0/46003/143db5a9-fbc2-2df0-23f3-d602a977bc42.gif)


1. New Relic APM にアクセス
2. 左メニューの Error analytics をクリック
3. メイン画面中段のタブメニューの Error Profile をクリック
4. 選択している時間帯に発生したエラー、フィルタリングで絞り込んだエラーを対象にエラープロファイルを表示
5. 属性(ポートやトランザクション名、カスタム属性など）別に、エラーの場合の傾向をメッセージで表示
6. 属性欄をクリックすると、エラーの場合と正常の場合の割合を表示


## 参考

この記事を読んでエラープロファイルについて興味を持って頂けたら、以下の記事も参考になるかと思う。

- [ドキュメント:エラープロファイル: 問題の傾向](https://newrelic.degica.com/docs/apm/applications-menu/error-analytics/error-profiles-troubleshoot-trends)
- [翻訳: APM からエラープロファイル機能をリリース](https://newrelic.degica.com/blog/2017-09-04-apm-error-profiles-generally-available)

## まとめ

ということで、今回は最近 New Relic が積極的に取り組んでいる機械学習を取り入れた機能エラープロファイルの紹介でした。