3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2017-12-05

New Relic Advent Calendar 2017 5日目。

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

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

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

アラート条件の設定手順

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

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

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

アラート条件: Web transactions percentiles

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

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

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

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

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

設定方法

スクリーンショット 2017-12-05 23.15.16.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

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

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

静的な設定項目では、どの値を閾値として設定するか悩むことがあるかと思う。特に 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

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

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

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

test2.gif

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

参考記事

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

まとめ

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

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?