New Relic Advent Calendar 2017 ５日目。

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

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

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

アラート条件の設定手順

その前に簡単に New Relic APM のアラート設定の共通の手順だけざざざっと説明しておく。詳しくはここを参照。

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

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

アラート条件: Web transactions percentiles

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

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

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

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

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

設定方法

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

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

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

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

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

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

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

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

設定方法

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

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

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

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

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

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

参考記事

注

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

まとめ

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