New Relic APM の最新アラート設定の紹介 - パターン認識アラートもあるよ

New Relic Advent Calendar 2017 ５日目。

New Relic APM のアラート設定についての記事。ここ一年でユーザーのアラート設定が楽になったり、New Relic が用意している以外の項目もアラート条件に設定できるようになったので、それらを紹介します。

去年書いた「[新アラートサービス: New Relic Alerts と今後予定されているアラートの新機能について](https://qiita.com/kumatronik/items/df67b28a2064a188d758)」のアップグレード版。去年の記事では、その時点で利用可能であったアラートについての最新情報をお伝えした。読んでいない方は、是非、本記事の前にご覧いただければ、この記事の理解も増すかもしれない。

前回記事で、今後追加される機能として「NRQL アラート」「ベースラインアラート」「アラート条件: Web transactions percentiles の追加」と書いたので、今回はこのうちの「ベースラインアラート」「アラート条件: Web transactions percentiles」を紹介します。

## アラート条件の設定手順

その前に簡単に New Relic APM のアラート設定の共通の手順だけざざざっと説明しておく。詳しくは[ここ](https://qiita.com/kumatronik/items/5dd264df027941f40d79)を参照。

1. New Relic UI にログイン後、画面右上の "Alerts" をクリック
2. トップしたのメニューから、"Alert policies" を選択
3. アラート条件を追加するために、既存のポリシーを選択するか、新しくポリシーを作る (画面右上の "New alert policy" をクリック）
4. 画面右の "Add a condition" をクリック
5. 後はカテゴリ、エンティティ(対象アプリ)、アラート条件を選択、入力する。

説明が簡単な順に説明していく。まずは、パーセンタイルから。

## アラート条件: Web transactions percentiles

アラート条件として、パーセンタイルが使えるようになった。これを使うと、ウェブトランザクションのパフォーマンスの閾値としてパーセンタイルで設定できる。これまでは Apdex やレスポンスタイム、スループットなどを設定項目に指定して、アラート条件を設定できた。パーセンタイルの設定は、平均レスポンスタイムの代わりというか、より細かい設定がしたい場合に便利な設定項目だと思う。

レスポンスタイムの場合は、平均レスポンスタイムが5分間500ms越えてたらアラートを出すみたいな設定だった。これだと、[前日の Apdex の話](https://qiita.com/kumatronik/items/04ebfefe7aa1f39591cc)じゃないけど、 少数の異常に遅いトランザクションによって、他のトランザクションは問題ないのに、アラートが発生する可能性がある。少数が遅くても無視できる場合、これはアラートはあがってほしくないかもしれない。(例えば深夜にこのような状況が発生し、起きて見てみるけど、緊急対応する必要はないかもしれない）。

そういった外れ値を無視というか、考慮して設定できるのがパーセンタイル指定の設定です。

例えば、90パーセンタイルで0.5秒を越えたらアラートを出すとかできる。これは、つまり、全リクエストの9割が0.5秒以内にある状態。この設定方法なら、平均が1秒のアプリで100秒のトランザクション(外れ値）が来て、平均が大きく跳ね上がる場合でも、90パーセンタイルより上なら関係ないので、アラートは発生しない。(外れ値は、もちろん全体のリクエスト数にもよるが、95-99パーセンタイルとかじゃないと引っかからないとは思う）

このように、特にアラート通知となる Critical の設定としては、平均レスポンスタイムを使うより、パーセンタイル指定の方が誤検出が少ないのではないかと思う。


### 設定方法

![スクリーンショット 2017-12-05 23.15.16.png](https://qiita-image-store.s3.amazonaws.com/0/46003/cd833a05-8182-3f77-ac21-acc800dd2a8b.png)


設定方法は、レスポンスタイムと似ている。パーセンタイル(th)を指定し、それがどの時点(秒数）を越えたら、(Warning/Critical の)インシデントを発行するかを設定する。

最初に書いた共通のアラート条件の設定の5の段階から説明していく。

1. カテゴリ: product として、APM を選択する(デフォルト）、type of condition として、"Web transactions percentiles" を選択する。(ここ間違えないように）。"Next, select entities" をクリック。
2. エンティティ: アラート条件を追加するアプリにクリックし、"Next, define threshold" をクリック
3. [ ]th にパーセンタイルを入力、Critical と Warning(任意）に、指定したパーセンタイルにおける秒数を入力。"Create condition" をクリック。(上のスクリーンショットを参考)


## (ダイナミック) ベースラインアラート

次は、ダイナミックベースラインアラート。これは、ダイナミックと言っているので、動的にアラート条件が変わる設定方法。

![スクリーンショット 2017-12-05 22.32.44.png](https://qiita-image-store.s3.amazonaws.com/0/46003/2297cbc7-fa43-686d-ee08-587524b3f3cd.png)

上で説明したパーセンタイルも含め、これまでのレスポンスタイムとかも、設定は静的な値(例えば、0.5秒とか）を指定する設定方法でした。これだと、スループットだと分かりやすいけど、１日のうち、昼と夜でまったくスループットが異なるアプリの場合、スループットをアラートの設定項目にしたい場合に、どちらを基準に設定していいのか、悩むと思う。普通は、ピーク時を想定して設定すると思うけど、そうすると、夜のスループットが昼の半分くらいしか通常ない場合に、昼と同じくらいに跳ね上がったとする、夜のスループットで考えると何かあったと考えられるけど、設定しているのは昼のピーク時なので、アラートの違反には引っかからない。ということで、異常な状態を見逃してしまうということが発生する。

これは、昼と夜とか、平日と土日とか、夏と春とか、そういった周期によって波が異なる場合に、平常時の波から外れた場合に、アラートを出してくれるというのが、ダイナミックベースラインアラート。

静的な設定項目では、どの値を閾値として設定するか悩むことがあるかと思う。特に New Relic APM を導入してすぐの場合。そういった場合は、とりえあずこのダイナミックベースラインアラートを設定するのが、設定し易いし、普段から外れた場合のみアラート通知が来るので、使い易いし、便利だと思う。

### 設定方法

1. カテゴリ: product として、APM を選択する(デフォルト）、type of condition として、"Application metric baseline" を選択する。(ここ間違えないように）。"Next, select entities" をクリック。
2. エンティティ: アラート条件を追加するアプリにクリックし、"Next, define threshold" をクリック
3. 閾値の設定: トップのセレクトボックスから、項目(トランザクションタイム、スループット、DB処理時間、外部呼出し時間など）を選択する。閾値の設定は Critical/Warning それぞれで、スライダーになっている。

まず、右のチャートの読み方を説明する。

![スクリーンショット_2017-12-05_22_43_31.png](https://qiita-image-store.s3.amazonaws.com/0/46003/3799d3fc-87cc-9091-e113-3c75809a5821.png)

まずチャートの上に、期間(ここだと2日）のデータ、今指定している閾値で発生した(したであろう） Critical のインシデント数。その横には、このチャートで確認する時間帯(２日 or 7日)を選択できる。

- 黒い線 (見づらいけど）: ベースライン。過去のデータ(２日間ではなく）からパターン分析した基準線。下のグレー帯域はこれと連動して動く。
- 青い線: 現在の値
- グレーの帯域: 許容範囲
- 赤い縦線: Critical なインシデント発生時点

左のスライダーを動かすと、右のグレーの帯域が増減する。このグレー帯域を越えたら、Critical のインシデントが発生するっていう意味。スライダーを左に動かすと、帯域が狭くなり、ベースラインから外れた場合の許容範囲が狭くなる。つまり、より厳しい閾値（インシデントが多く発生）。右に動かすと、許容範囲が多くなり、ちょっといつもと違う動きをしてもアラートは出さない。この許容範囲をダイナミックベースラインアラートでは設定する。これは、Warning でも同じ。Warningは、黄色の線で、帯域は、Critical よりも薄いグレーで表される。

![test2.gif](https://qiita-image-store.s3.amazonaws.com/0/46003/a26dc984-5288-514d-11d3-a51e379e9f7e.gif)

また、チャート上の期間は、２日(since 2 days ago)と7日(since 7 days ago)を選べるが、これはあくまで下のチャートでどのようにベースラインと現在値がどんな感じかを確認するためのもので、この期間のデータだけをベースラインの生成に使っているわけではない。ベースラインは過去の全データを使って生成されている。(ここら辺のアルゴリズムとかは下の参考記事とかを参照）


### 参考記事

- [ドキュメント:ベースラインアラート条件の作成](https://newrelic.degica.com/docs/alerts/new-relic-alerts/configuring-alert-policies/create-baseline-alert-conditions)
- [翻訳: ダイナミックベースラインアラート公開!](https://newrelic.degica.com/blog/2017-06-28-dynamic-baseline-alerts-ga)

### 注

ダイナミックベースラインアラートは APM Pro ユーザーのみ利用できる。


## まとめ

今回は、より効率良くアラートの設定、管理ができるアラート条件を紹介しました。特にダイナミックベースラインアラートは、非常に使いやすく、便利な設定方法ですので、とりあえず使ってみてください。