New Relic APM を入れたらこれだけはやっておけっていう設定や使い方 

New Relic APM (アプリケーションパフォーマンス監視)を使っているけど、入れただけで、アラートの設定とかしてない人多そうなんで、最低限、これだけは設定しておけっていうことと、お金払ってるなら、使ったほうがいいっていう機能を非常にざっくりと紹介します。New Relic APM は便利なんで、是非、活用できるための一助になればと。

ここでは、かなりざっくとりした説明しかしてないなので、詳しい機能とかは別の記事とか、[ドキュメント[日本語]](https://newrelic.degica.com/docs)を見てください。

## この記事の想定読者

New Relic APM のエージェントをインストールしていて、データ既に見える状態であることを前提に説明します。インストール方法を知りたい方は、[ここ](http://qiita.com/kumatronik/items/a6580d438088730ae055)を見てください。

また、一番オーソドックスな使い方であるトランザクショントレースを使ったパフォーマンス分析については説明しません。それについては、[ここ](http://qiita.com/kumatronik/items/c1ba96d563c0445243a4)をご覧ください。

ここでは、有料プラン(Essentials と PRO)を使っている人向けの説明をしています。(無料版は、あまり設定とかできないので、語れることが少ないので)

## 有料版 (Essentials or PRO) を使っている人向け

なにはなくとも、以下の２つはちゃんと設定すること。

- Apdex の閾値 T
- アラートの設定

特にアラートをちゃんと設定していない人が多い。アラート設定してないと、New Relic 使っている価値がだいぶ減る気がする。New Relic の人も[ここで](https://newrelic.degica.com/blog/2017-06-28-dynamic-baseline-alerts-ga)「New Relic では、アラートを使用していない監視は、実際には監視しているとは言えないと考えています。」って言っている。

### ユーザー満足度の指標である Apdex (アプデックス) とその閾値の設定

[Apdex](https://newrelic.degica.com/blog/2017-02-27-about-apdex-01) ってのは、New Relic が採用している、レスポンスタイムを基準にしたウェブのユーザー満足度を測る指標。Apdex T は、その基準となるレスポンスタイムのこと。この値(閾値)によって、Apdex スコアが計算される。そのため、これを何に設定するかが非常に重要になる。

Apdex T やどういった値を設定すべきかは、「[Apdex T の決め方:決定版](https://newrelic.degica.com/blog/2017-07-06-how-to-choose-apdex-t)」を見てください。ちなみに、傾向としては、EC サイトなんかは、0.1-0.2 くらいに設定しているとこが多いそうです。

#### Apdex T の設定方法

APM の概要(Overview)ページ開いてたら、画面左メニューの一番下の方の「Application」を選択、画面中段の「App server」という項目があるのが、それ。Apdex T フィールドを編集して、保存ボタンを押せば、変更完了。


### アラート (New Relic Alerts) の設定 

New Relic のアラートでは、アラート条件(例えば、レスポンスタイムが xx 秒以上ならアラートを通知などの条件）と、通知方法(メールや、Slack など)の２つを組み合わせて設定します。

アラートの設定方法については、[以前書いたアラートの設定](http://qiita.com/kumatronik/items/5dd264df027941f40d79)をご覧ください。(記事は古いけど、設定方法は今でも変わっていない) 

#### 設定方法

画面右上の「Alerts(New)」を押して、「Alert policies」タブを選択し、ポリシー作って、条件を追加して、チャンネル(通知方法）を追加していく。

#### 備考

アラートは最近(2017年7月現在) [NRQL アラート](https://newrelic.degica.com/blog/2017-05-17-nrql-alerts-generally-available)など New Relic 製品内でもっとも機能追加や改善が行われている製品です。是非、最新機能をチェックし、活用してください。

PRO の人は、是非、**ダイナミックベースラインアラート**を使ってください。(これについては、以下のPROのとこに記述)

### 死活監視は、New Relic Synthetics の Ping を使え

![synthetics_ping_availability.png](https://qiita-image-store.s3.amazonaws.com/0/46003/98d905af-641b-d734-ffc0-82d6de71a3c1.png)


New Relic では、外形監視/死活監視(アプリが生きているか）のチェック方法として、New Relic Synthetics の Ping を使うことを推奨しています。APM にも、Availability monitoring って機能があるけど、そっちはあまり推奨してない。

New Relic Synthetics は外形監視サービスで、いつくか監視方法があって、Ping みたいな単純に生きてるかどうかのチェックから、Selenium を内部で使った画面遷移まで含めた複雑なチェックもできる。Synthetics について気になる方は、[ここ](http://qiita.com/kumatronik/items/c542feac77b08c3ca6460)をご覧ください。

で、Ping (これは、Ping コマンドではなく、HTTP HEAD リクエスト送って、結果をチェックする)は、無料でだれでも使える。(もちろん、APM 無料版の人も)。無料では、50 モニター(50 URL)まで使えるっぽい。

設定は、New Relic の画面だけで済むので、使わない手はないって感じです。設定方法は、[ここ](http://qiita.com/kumatronik/items/c542feac77b08c3ca646)をご覧ください。

また、チェックに失敗した場合にアラートを飛ばすには、アラート画面で設定が必要ですので、それもお忘れなく。

### パフォーマンスは、平均だけじゃなく、パーセンタイルやヒストグラムもチェックすべし

APM の概要ページの中心に、現在のレスポンスタイムを時系列で表示しているけど、実はこれ、別の形式でも見ることができます。それが、パーセンタイルとヒストグラムの２つ。

平均レスポンスタイムが遅くなったときに、それが、少数のトランザクションが極端に遅くなったのか？それとも、全体的に遅くなっているのか、平均だけでは判断できません。そこで、ヒストグラムやパーセンタイルも同時に確認することで、トランザクションのばらつきを確認できます。

![2016-10-13_apm_histgram.png](https://qiita-image-store.s3.amazonaws.com/0/46003/04a7f964-e30e-c2c7-91cd-c66190e7a614.png)

上図: ヒストグラム。指定期間の全トランザクションをヒストグラムに表します。

![HistPercImage2-1024x429.jpe](https://qiita-image-store.s3.amazonaws.com/0/46003/38a77340-b723-2b1a-32b7-969931ff9132.jpeg)

上図: パーセンタイル。平均(Average)、50パーセンタイル(Median)、95パーセンタイル、99パーセンタイルが表示されます。



#### パーセンタイルとヒストグラムを表示手順

パーセンタイルとヒストグラムの表示に切り替えるには、レスポンスタイムチャートのタイトルである "Web transactions time" をクリックすると、以下のポップアップが表示されます。

![2016-10-13_chart_icons.png](https://qiita-image-store.s3.amazonaws.com/0/46003/6b643645-e249-a06e-dd4b-c16980630bcd.png)

真中のアイコンを選択すると、ヒストグラム。右アイコンを選択するとパーセンタイル形式でチャートが表示されます。（また、Non-web はウェブ以外の処理のパフォーマンス計測データがある際に選択できます。例えば、バックグラウンド処理など）


ヒストグラムとパーセンタイルについては、[ここ](https://newrelic.degica.com/blog/2016-10-13-histograms-percentiles-new-relic-style)をご覧ください。


## PRO を使っている人向け

PRO 使っている人は、以下の３つの機能は是非、使ってください。問題が発生したときの問題の切り替えがスムーズに行くと思う。

1. デプロイ履歴
2. サービスマップ
3. キートランザクション

### 1: デプロイ履歴 (Deployments)

これは、デプロイメントマーカーというものを使うと、デプロイ前後のパフォーマンスが分かりやすく表示されるっていう機能。地味に便利だし、導入もそこまでの手間ではないので、使ったほうがいいよ。

![qiita_deployemnts_detail.png](https://qiita-image-store.s3.amazonaws.com/0/46003/1326888a-8fb4-4f0b-4b79-686ee56311e3.png)

デプロイ履歴画面の表示は、画面右の Events の Deployments がそれ。

利用方法は、[ここ](http://qiita.com/kumatronik/items/f93023d30a093c285933)を見てください。アプリのデプロイスクリプトに、New Relic の API コールを１行追加するだけで、OK です。

デプロイ履歴のもう一ついいところは、以下のようにデプロイマーカーが、APM の概要ページにも表示されるという所。なんとなく概要ページを見ていても、いつデプロイされたか、その後のパフォーマンスへの影響がどうだったかを確認できるってところがいい点。

![qiita_deployment_overview.png](https://qiita-image-store.s3.amazonaws.com/0/46003/898a6d54-c2b6-99ef-749e-6be9b526f078.png)

### 2: サービスマップ (Service Map)

![qiita_service_map.png](https://qiita-image-store.s3.amazonaws.com/0/46003/b39faee1-3271-e1ff-fab2-07bbd65c572f.png)

サービスマップは、１つの New Relic アカウントで複数アプリを管理している場合は、どのアプリがどのアプリを呼んでいるとか、アプリの現在の健康状態やパフォーマンスの概要(レスポンスタイムやスループット等)を１つのビューで分かるってもの。障害が起きたときに、それが実際はどのサービスに問題があるのかが把握しやすい。これは、設定とか特にないので、是非、使ってください。

サービスマップについては、[ここ](http://qiita.com/kumatronik/items/ddfb3b262315de94e43b)を見てください。

## 3: キートランザクション (Key transaction)

キートランザクションは、特定のトランザクション専用の監視ができる（概要ページのレイアウトでそのトランザクションだけのページができる)。

![qiita_keytransaction_overview.png](https://qiita-image-store.s3.amazonaws.com/0/46003/15c84bf1-6a41-d98a-ac28-d6b1a84c9287.png)

これのいいところは、上で説明した Apdex T とかアラートの設定が専用で行えるってこと。どういうことかと言うと、例えば、検索処理のトランザクションがあったとして、サービス全体では、レスポンスタイムのアラート条件の閾値を0.5秒とかでいいけど、検索処理は、0.1秒とかで監視したいって場合があるとする。その場合、検索処理をキートランザクションに指定すると、検索処理専用のアラートの設定を行うことができる。(アラートの設定に、"Key transaction metric" っていう選択肢があるので、それを使って設定する)

キートランザクションの設定や使い方は、[ここ](http://qiita.com/kumatronik/items/6cf0b6e8588aaad197cc)を参照。

また、もう一つ、[X-Ray](https://newrelic.degica.com/docs/apm/transactions/x-ray-sessions/x-ray-sessions-traces-thread-profiles-key-transactions) っていうスレッドプロファイラー機能が使える。でもこれは、使用している言語によって使えたり、使えなかったりする。現在は、Java、Ruby、Python のアプリなら使える。これを使うと、トランザクショントレースよりも細かい粒度でパフォーマンスを測定できるので、トランザクショントレースではいまいち、どこが遅いのか具体的に分からないって人は、使ってみるといいと思う。

### アラートにダイナミックベースラインアラートを使うべし

PRO を使っている人は、PRO ユーザーのみ利用できるダイナミックベースラインアラートっていう機能があるので、それを使えばいいと思う。(2017年6月にリリースしたばっかの新機能)。

![define-thresholds-example-2.png](https://qiita-image-store.s3.amazonaws.com/0/46003/1acf316f-6977-b6b4-dd89-095616a9d665.png)


これは、機械学習使って、過去データからパターンを認識し、パターンから外れたらアラート出すっていうもの。簡単に設定できるので、とりあえず使っておけばいいと思う。詳しい内容や使い方は、[ここ](https://newrelic.degica.com/blog/2017-06-28-dynamic-baseline-alerts-ga)を見てください。

--- 

以上、非常にざっくりですが、とりあえず入れてみたけど、いまいち使い方がわからんって人の参考になればと思います。

もっと突っ込んだ使い方をしたいって方は、別記事に書く予定ですのでそちらも合わせてご覧いただければと思います。そっちでは、デフォルト以外のデータ収集する方法や、トランザクショントレースの粒度では大きすぎるので、もっと細かい単位でパフォーマンス計測表示する方法を書く予定です。また、インフラも合わせて監視したいとか応用編的な使い方を紹介します。