デジカの宮澤です。アドベントカレンダー4日目は、去年も紹介しましたが、ようやく正式にリリースされたので、改めて New Relic Alerts について紹介します。

既存のアラートとの違い

New Relic Alerts は、中央集権型の New Relic のアラート機能です。これまでは製品ごとのアラート設定との違いは以下となります。

１つのUIで全製品のアラートの設定を行える。統一したUIとなった。
設定できるアラート対象が増えた。例えば、APM の場合、エラー率と Apdex しかアラート条件に設定できなかったけど、レスポンスタイムやスループット、カスタムメトリクスなど指定できる項目が増えました。
利用可能な通知チャネルが増えた。slack などがデフォルトで選べるようになりました。
柔軟ならアラート設定が可能に。複数のアラート条件を設定できるので、アラート通知がより適切に送れるようになった。（詳しくは、以下で説明します）

誰が使えるの？

New Relic Alerts は有料プランのユーザー向けサービス。有料プランをお使いの方は、利用している有料プランの製品で、New Relic Alerts を利用できる。

使用方法

New Relic にログイン後、画面の右上に、「Alerts new」というメニューが表示されているので、それをクリックします。既に利用している場合は、Alerts 画面に切り替わります。まだ利用していない方は、最初に以下のような切り替え同意画面が表示されます。

New Relic Alerts とは

New Relic Alerts は、以下の構造でアラートの設定を行います。

アラートポリシー
アラート条件
チャネル(通知先の設定）

アラートポリシーには、複数のアラート条件とチャネルを設定できます。

設定

アラート条件では以下の順で指定します。

アラート対象の製品(APM, Browser, Servers, Mobile, Plugins, Synthetics)
アラート対象のアプリ
閾値の設定(どの項目が、どういう値になったら、アラートを出すのか？)
- 例: 平均レスポンスタイムが、5分以上、2秒を超えていたら

アラート条件では、Criticla と Warning の２つのレベルがあります。違いを簡単にいうと、Criticla の閾値を越えると、チャネルに設定した通知先にアラート通知が飛びます。Warning の閾値を超えても、アラート通知は飛びません。アラート条件の設定では、Criticla は必須で、Warning は任意です。

以下は、手順3の New Relic APM を対象とした場合の閾値の設定画面です。

上記は、レスポンスタイムが3秒以上の状態が、5分以上続いた場合にアラートを通知します。Warning の指定はなし。というアラート条件の定義。

APM の場合に指定できる設定対象は以下となります。(これは製品別などによって異なる)

また、APM の場合、対象として、外部サービス(external service) も指定できるため、利用している外部サービスからのレスポンスが3秒以上応答がないとアラートを通知する。といったこともできます。

インシデント管理としても使える

Warning が通知が飛ばないとしたら、なぜ Warning が必要なのでしょうか？それは、New Relic Alerts がインシデント管理としても使えるからです。

New Relic Alets では、Criticla と Warning の閾値を越えると、violation (違反)が生成され、その管理する入れ物のインシデントが生成されます。これは、New Relic Alerts の Incidents 画面や APM 等のインデックス画面で何かアラート条件に違反していることが分かります。そのため、New Relic はインシデント管理のシステムとしても使えます。

アラートポリシーとは - アラート疲れを軽減するシステム

上記までで、簡単に New Relic Alert の構造を説明しましたが。アラートポリシーとはなんでしょうか？なぜ、複数のアラート条件を設定できる必要があるのでしょうか？　それは、インシデント管理及びアラート通知を効率良く管理するためです。

アラートポリシーがないと、どういうことになるかというと、例えば、レスポンスタイムが2秒を超えたら、アラートを通知する。スループットが、1000 を超えたらアラートを出すという２つのアラート条件を作成していた場合、どちらかの条件に達したら、もう片方の条件に達するという自体が発生した場合、２つアラートが飛ぶことになります。しかし、実際の原因は１つかもしれません。

そこで、アラートポリシーが役に立ちます。アラートポリシーの配下にあるアラート条件は、どれか一つでもアラート条件に違反していたら、その後に別のアラート条件で違反があっても、最初のアラート条件の違反が解消されるまで、追加でアラートを通知しません。

このように、アラートポリシーは、同じ原因によるアラート通知が大量に発生することを防ぎ、効率的にアラートを管理する仕組みとなっています。

健全さを示すヘルスインジゲーター

アラートは、New Relic APM などのサービスマップやインデックス画面で、アプリの健全さを示すことにも使われています。以下のように、Warning に違反すると、黄色、Criticla だと赤になっています。そのため、アラートが適切に設定されていれば、パット見でアプリで何か問題が発生しているかが、簡単に知ることができます。

今後追加予定の機能

NRQL アラート
待望の機能。NRQL を指定して、その結果の値でアラートを通知できる。これが入れば、実質 Insights で管理しているデータはすべてアラート対象にできる。何がいいかというと、弊社の場合は、ソフトウェアDLのECやってたりするので、S3のダウンロード数とかみてたりするけど、それがある一定数いったらアラートを出すとかが簡単にできる。今は、Insihgts API を使って、データとって、別の仕組みでアラート出してたりしてるんだけど、それが必要なくなるので、誰でも、簡単にそういったことができるようになる。これは、たぶん、すごい便利。

ベースラインアラート
これは、今まではアラートの条件の閾値を決め打ちで設定して、それを超えたらアラートでてたんだけど、これは機械学習を使って、過去の履歴からある程度類推してくれるらしい。詳しくは試せてないので分からないけど、これも非常に気になる機能。

アラート条件: Web transactions percentiles の追加
今までは、平均とかだけだったけど、パーセンタイルで指定できるようになる。これも、設定画面みれてないので、どういった指定の仕方かわからなけいど、今までより、外れ値を無視できるようになるのではないかと思っている。

ラベルでのアプリケーション指定
今回紹介したアラートの作成方法だと、アプリごとに指定するので、アプリが増えたときに追加で設定したりする必要があるが、たぶん（正式にはどういう機能かしらないけど）アプリのラベルで指定ができる。つまり、アプリを追加した場合も、ラベルを設定すればアラートの設定をする必要がなくなる。たぶん。

上記は、たぶん、プライベートベータとかだと思うので、いつ正式リリースになってないけど、12月中にリリースされたら、別の日で詳しく書いてみたい。

あわせてよみたい

去年のアドベントカレンダーの記事　New Relic Alert: 柔軟なアラートの設定でインシデントを効率よく管理しようでは、この記事よりもスクショを多用して、アラートの設定やチャネルの設定など詳しく説明しています。

もっと詳しく知りたい方は、ドキュメント(日本語)をご覧ください。

まとめ

既に有料プランをお使いの方は、いますぐ切り替えて使ったほうがいい。また、今後も非常に楽しみな機能が目白押しです。アラートの（いまのところの）最終進化系が、他の日でも触れる AI/機械学習の新プロジェクト Project Seymore だとおもう。これは非常楽しみな機能となっています。

是非、アラートを活用して、顧客が気づく前に対応できる環境を整えてください。