6: 基礎編 2: アプリ監視でやっておくべき３つの設定 - New Relic を使ったアプリケーションのパフォーマンス監視入門

New Relic Advent Calendar 19日目。基礎編の2回目。

前回は New Relic アカウントの作成からファーストビューの概要ページの内容まで紹介しました。本日は、導入後行っておくべき3つの設定を紹介します。

最初にやっておくべき設定

基本 APM エージェントを入れてデータが送信されてくれば、現状は見える。ただ現状がわかるだけ。これをもっと効果的に分析したり、パフォーマンス異常に気づけるようにするには、少々設定が必要。（それでも、New Relic UI 上でポチポチするだけだけど）

データを計測を開始したら最低限やっておくべきことは以下の3つ。

1. Apdex の閾値の設定
2. アラートの設定
3. 死活監視

特にアラートの設定は結構やっていない人が多い気がする。アラートを適切に設定していない監視は、監視とはいえない。と New Relic の人も言っているので、監視は重要です。

ただ、両方ともある程度のデータが必要になるので、New Relic を導入してから最低1日から2日に以下の設定を行ってください。

1: Apdex の閾値 T の設定

前回さらっと説明しましたが Apdex はウェブアプリのユーザー満足度の指標です。閾値を元にレスポンスを Satisfied/Tolerating/Frustraed の３つに分け、一定期間に収集したレスポンスをその３つのどれかに分類し、その数を元にスコア(0-1)を計算します。計算式などは後述のリンク先をご覧ください。

よって、閾値の値によって、同じレスポンスタイムのレスポンスが来ていてもスコアは変わってきます。閾値を適切な値に設定しておくことが、効率良くユーザー満足度を計測、監視する秘訣です。

では、閾値に何を設定するかというと、**過去24時間のリクエストの 90 パーセンタイルのレスポンスタイム(秒)**です。New Relic では、Apdex スコアが 0.95 となるのが良いとしています。そのスコアとなる閾値が、過去24時間のリクエストの 90 パーセンタイルのレスポンスタイム(秒)なのです。(統計的にそうらしい。詳しく知りたい方は、これも後述のリンクを参照)

New Relic Insights で 過去24時間のリクエストの 90 パーセンタイルのレスポンスタイム(秒) を求める。

では、90パーセンタイルのレスポンスタイムは、どうやって求めるのでしょうか？ ここで出てくるが、New Relic Insights です。前回紹介したように、New Relic Insights は、各製品が収集したデータを一括して利用できる製品です。New Relic Insights は、アラートと同じで、有料版の製品またはトライアル利用中に利用できる製品です。(トライアル中だと思うので）これを使って、求めていきます。

1. 画面トップメニューから、New Relic Insights をクリック。
2. 真中に、"NRQL > SELET" と表示される。
   
3. そこに次の NRQL をコピーする。
   SELECT percentile(duration, 90) FROM Transaction SINCE 24 hours ago
   複数のアプリを New Relic 上で管理している場合は、アプリ名を指定する。(xxxxをアプリ名に置き換える。補完がでるのですぐにわかるとは思う)
   SELECT percentile(duration, 90) FROM Transaction WHERE appName = 'xxxx' SINCE 24 hours ago
4. エンターか "Run" ボタンを押すと結果がでるので、それをメモしたり、コピーしておく。(これが Apdex T に設定すべき値)
   
5. APM に戻り、左メニューの一番下のほうの、SETTING にある Application メニューをクリックする。
6. 画面真中くらいの App Server の下の Apdex T (デフォルトが0.5秒)欄を3でメモした秒数に置き換える。
   
7. "Save application settings" をクリックする。

以上

上記でリンクを参照って書いた部分や New Relic の考えるユーザー満足度について知りたい方は、「Apdex って何？スコアの意味は？閾値やアラートに何を設定するべき？全部答えます。」をご覧ください。

2: アラートの設定

デフォルトではアラートは設定されていない。自分で必要なアラートを設定する必要がある。New Relic の場合、アラートの設定は、New Relic Alerts という製品を使う。(有料版製品orトライアルユーザーのみ利用可能)

New Relic Alerts の基礎は理論編で説明したので、詳しくはそちらを参照。簡単な手順だけ説明していく。

1. New Relic Alerts は、画面右上の "Alerts new" というメニューを押す。
2. まずは、通知チャネルの設定から: 画面トップの製品メニューの下のサブメニューにある "Notification channels" を押す。
3. 画面右上の "New notification channel" をクリックし、"Select a channel type" をクリックし、利用する通知チャネルの設定を行う。通知チャネルの詳しい設定方法はこちらを参照。
4. 次は、アラート条件を追加していく。アラート条件はアラートポリシーに含めるので、まずはアラートポリシーを作成する。"Notification channels" メニュー左の "Alert polices" をクリック。
5. 画面右上の "New alert policy" をクリック。画面中央に表示されている "Create a condition" をクリック。
6. APM に関しては大きく２つの設定方法がある。静的な閾値とダイナミックベースライン。初心者はとりあえずダイナミックベースラインを設定するのがお手軽なので、ダイナミックベースラインを設定していく。
7. (デフォルトで APM が選択されているので、そこはそのままにしておいて) "Select a type of condition" から一番最後の "Application metric baseline" を選択し、"Next, select entities" を押す。
8. アラート条件を設定する対象アプリにチェックし、"Next,define thresholds" を押す。
9. デフォルトがトランザクションタイムの異常パターン検知の設定となっている。これは、過去のデータパターン(ベースライン)から急激に外れる処理時間となったときに、それをアラートとして通知してくれる。とりあえずそのままの設定(応じて動かしてもいいけど）で、"Create condition" を押す。これでアラート条件の設定は終わり。ベースラインについて具体的にどういうものか知りたい方は、「New Relic APM の最新アラート設定の紹介 - パターン認識アラートもあるよ」をご覧ください。
   
10. 次に Apdex を対象にアラート条件も設定していく。以下の画面が表示されていると思うので、画面右の "Add a condition" をクリック。
    
11. "Next, select entities" を押す。 (Product はデフォルトの APM のままで、Condition Type もデフォルトの Application metric のままでよい)
12. アラート条件を設定する対象アプリにチェックし、"Next,define thresholds" を押す。
13. (対象はデフォルトの Apdex のままで、) Critial に 0.70 を入力する。
14. その下の Warning (黄色の三角)の "Add a warning threshold" をクリックする。
15. Warning の閾値の 0.85 を入力する。
16. "Create condition" をクリックする。これでアラート条件の設定は終わり。
17. このままだとアラート条件に違反しても3で追加した通知チャネルに通知が飛ばないので、通知チャネルをアラートポリシーに追加する。
18. 画面上の方の "1 Notification channel" タブをクリックし、右の "Add notification channels" をクリックする。
19. 3で追加した通知チャネルを選択する。

２つのアラート条件と設定した数の通知チャネルが設定されたアラートポリシーができた。

以上で最低限の設定は終わり。

上記の手順をスクリーンショット付きで知りたい方はこの記事をご覧ください。

ちなみに、閾値の設定で、Critical と Warning を設定したが、Critical は致命的な状態で、すぐに通知が欲しい状態を指す。よって、Critial に設定した閾値を越えると設定した通知チャネルを通じて、通知が飛ぶ。一方、Warning は警告で、緊急ではない状態。なので、Warning に設定した閾値を越えても通知は飛ばない。New Relic UI 内でのみ警告が出ているかわかる。

赤は Critical、黄色は Warning。色でわかる健康状態

Critical は赤、Warning は黄色。これはチャートやアプリケーション一覧での状態を表している。

以下は APM のアプリケーション一覧である。パット見でどのアプリで Critical がでており、Warning が出ているかわかる。また、画面右のアクティビティ一覧では具体的に違反内容がわかる。

また、概要ページ等でも違反が発生している時間帯は、チャートの背景色が赤や黄色になる。アプリ名のところでもわかる。

このようにアラートを設定しておくと、異常な状態なときに各所で知ることができる。そのため、迅速に異常に気付くことができるので、アラート設定は重要。

3: 死活監視は、New Relic Synthetics で

最後にやっておくべきことは死活監視です。アプリが動いていることを監視します。また、それによって稼働率(Availability)も知ることができます。New Relic では、死活監視の仕組みとして、New Reilc Synthetics があります。５つの監視製品のところで説明しましたが、Synthetics は4つの監視手段を提供しています。この内の Ping は無料で使えます。詳細なパフォーマンスは分かりませんが、ここでの目的である死活監視と稼働率の計測は行なえます。

では設定していきます。

1. 画面トップから Synthetics をクリックします。
2. 画面右の "Add new" をクリックします。
3. (モニタータイプはデフォルトの Ping のままで、)　"2. Enter the details" に、モニター名(なんでもいい）、監視対象のサイトの URL を入力します。(3つ目はオプションなので空でいいです）
4. "3. Select monitoring locations" から世界中にある New Relic の環境からリクエストを送る地域を選択します。日本向けのサービスを展開しているなら、"Tokyo, JP" にだけチェックすれば良し。
5. "4. Set the schedule" はリクエストの送信頻度を決めます。1 hr(時間)とかで良いと思う。
6. "Get notified" は監視に失敗したときに、エラーを通知するメールアドレスです。任意ですが、とりあえず設定しておきましょう。
7. "Create my monitor" を押します。

以上で死活監視の設定ができました。これでアプリが反応していないときは、メール通知が来るようになりました。

スクリーンショット付きで手順を確認したい方は、「New Relic Synthetics: 無料のPingモニターでサイトの稼働状況をらくらくチェック」をご覧ください。

まとめ

以上で、アプリケーションのパフォーマンス監視で最低限やっておくべきことは終わりです。最低限なので、特にアラート設定は、自社の組織に合わせて、うまく設定して、効率良い品質管理を行ってください。

次回は、実際に New Relic APM を使ってパフォーマンス分析する方法について紹介します。