4:理論編 4: 補助製品とNew Relic アカウントの紹介 - New Relic を使ったアプリケーションのパフォーマンス監視入門

New Relic Advent Calendar 2017 17日目。

New Relic を使ったアプリケーションのパフォーマンス監視入門 理論編: 4日目。理論編の最終日です。(４日もやると思ってなかった）

1. 理論編 1: アプリケーションパフォーマンス監視とは
2. 理論編2: New Relic とは
3. 理論編3: 監視製品の紹介

理論編 その4 : 補助製品とNew Relic アカウントの紹介

前回は、New Relic が提供してる5つの監視製品を紹介しました。ここでは、補助製品である New Relic Insights、New Relic Alerts、そして、New Relic アカウントの設定などについて紹介します。

New Relic Insights

New Relic Insights はダッシュボードサービスです。前回紹介した監視製品が収集したデータをデータソースとして、利用できます。これを使うことで、各製品ページでは確認できないより細かいレベルのでのデータ分析や、製品やアカウントをまたがってパフォーマンスデータを一覧できるダッシュボードを作成できます。

Insights を使って、マネージャーが見るダッシュボード、アプリチームが見るダッシュボード、インフラが見るダッシュボードなど用途別にダッシュボードを作成できます。これによって、各製品ではニーズに会わなかった層の人にもパフォーマンスを確認してもらいやすくなります。

また、複数サービスを運用している場合は、サービスA、サービスB、サービスC のレスポンスタイムを並べたり、APM、Infrastructure、Browser のパフォーマンスを並べたりとサービス全体を俯瞰したダッシュボードなども簡単に作成できます。

ダッシュボードの作成方法

ダッシュボードに、ウィジェット(一つひとつのチャート）を追加する方法いくつかあります。

• NRQL を書く
• 各製品画面のチャートを追加
• Data Explore を使って追加
• 既存のウィジェットやダッシュボードをコピー

NRQL を使ってデータの問い合わせとダッシュボードへの追加

コアなやり方は、NRQL (New Relic Query Language) という SQL ライクなクエリ言語を使って、データを抽出し、それをダッシュボードに追加する方法です。

過去１時間のアプリAのトランザクション数を知りたい場合の NRQL は以下のようになります。(NRQL では時間指定をしない場合、直近1時間が指定されたことになる)

Select count(*) from Transaction where appName = 'A'

以下は、NRQL を書いて、ダッシュボードにその結果のウイジェットを追加していく例。こんな感じで、バシバシ必要なウィジェットを追加していく。ちなみに、例で使っている Facet は SQL の Group By だと思ってもらえれば。

NRQL で使える構文とか関数とかいろいろあるので、以下のリソースを確認して是非活用してください。Insights はユーザーの利用次第でかなり幅が広がりまるサービスとなっています。また、以下でほんと軽く紹介するけど NRQL を利用した NRQL アラートというアラート設定もあります。

• New Relic Insights: NRQL をいろいろ試しみよう（基本編）
• ドキュメント: NRQL について

各製品のチャートをダッシュボードに追加

各製品のチャートにカーソルを乗っけると、右したに "Add to an Insights dashboard" というリンクが表示されます。これをクリックすると、ポップアップが表示され、ダッシュボードに追加できます。

APM 概要ページの平均レスポンスタイムのチャートをダッシュボードに追加している例。

Data Explore からダッシュボードに追加

NRQL が苦手な方向けに、New Relic Insights には、Data Explore というメニュー(Insights 画面の左メニューの上から２つ目）があります。これは、ポチポチするだけで、自動的に NRQL を作ってくれるので、作りたいウィジェットができたらそれをダッシュボードに追加するだけです。これには、Events と Metrics という２つのメニュータブがあります。Events は、NRQL で扱える１つのイベント（APMなら１トランザクション)。Metrics は、集計データです。なので、こちらは NRQL では作成できません。この画面からポチポチして作成するだけです。ちなみに、上の各製品のチャートデータもメトリクスのデータで作成されています。

イベントとメトリクスについて知りたい方は、こちらを参照。

また、Insights で見えるデータ期間は、PRO を契約している製品であれば過去8日分となります。この期間を伸ばしたい場合は、Insights に別途課金することで好きなだけ伸ばすことができます。

イベントデータの種類を知りたい場合

先ほど、APM は Transaction にイベントデータがあるといいましたが、どの製品でどのデータ・ソースが使えるか知りたいと思います。その場合は、Insights default data from other New Relic productsをご覧ください。また、各データソースで利用可能な属性(カラム)についてもこのページからの遷移して見ることができます。(英語ですが、見ればなんとなくわかると思います)

カスタム属性を追加してアプリ固有のデータ項目で情報の分析もできる

APM などの製品ではデフォルトで様々なパフォーマンスデータを収集します。そのデータを Insights でも利用できます。そこに加えて、APM 等ではカスタム属性という任意のデータを収集対象に追加する機能があります。これは、アプリのコード上に API を追加する必要があります。

PHP アプリでカスタム属性を追加する場合

newrelic_add_custom_parameter ('userID', $userId)

例えば、マルチチャネルの EC サイトなら ストアIDをカスタム属性として追加しておくと、店舗ごとのパフォーマンス用のダッシュボードなどが作れたりします。このようにアプリ固有のデータ項目を軸に様々な分析が行えます。

カスタムイベントで新たなデータソースの追加

また、Insights にはカスタムイベントという機能があります。上のカスタム属性は、既存のデータ・ソース(APM なら Transaction)にカラムを追加するという間隔でデータを付加できます。一方、カスタムイベントは、データ・ソースを追加します。何が嬉しいかというと、New Relic のエージェント以外の場所からもデータを送信できるのです。これによって様々なデータを New Relic 上で管理、分析できるようになります。

ただ一点注意点として、現時点でカスタムイベントは、リアルタイムのデータ送信しかできません。つまり、過去データのインポートとかそういうのができません。

カスタムイベントについてはこちらを参照。

注: これは、Insights に課金することで利用できる機能です。

New Relic Alerts

New Relic では、アラートの集中管理方式を採用しています。つまり、各製品ごとにアラートの設定があるのではなく、この Alerts という製品で各製品のアラートの設定や発生しているインシデントの管理を行います。ただ、例外として、New Relic Infrastructure だけは、Infrastructure の UI から設定が行えます。

New Relic Alerts にアクセスするには、画面右上の方の、Alets New という箇所をクリックします。

Alerts は、製品に関係なく以下の要素で構成されています。

• インシデント(Incidents)ページ: アラート条件に違反(violation)し、発したインシデントを確認できます。現在、何か問題が起きているのか知ることができます。
• イベント(Events)ページ: アラート条件に違反したものの一覧を確認できます。
• アラートポリシー(Alerts policies)ページ: アラート条件などを設定するページ
• 通知チャネル(Notification channels)ページ: アラートの通知先(メールや Slack 等)の設定を行うページ

注: インシデントと違反の違いはちょっとわかるづらいのですが、簡単にいうと、アラート条件を違反すると、違反(violation)イベントが作成されます。しかし、それがインシデントになるかは、アラート条件のアラートポリシーによります。

アラート設定

アラートを設定する際は、アラートポリシーというのをまず作ります。その中に、複数のアラート条件、通知チャネルを設定します。

主なアラートの設定方法

1. 通知チャネルページで、アラートで使う通知チャネルを設定
2. アラートポリシーページで、アラートポリシーを作成。必要に応じて、ポリシーの設定を変更(後述)
3. 2で作成したアラートポリシーにアラート条件を作成 (複数可)
4. 2で作成したアラートポリシーに、そのアラート設定で使う通知チャネルを設定
5. 必要な分だけ、2-4を繰り返す。

アラート条件の設定

上記のステップ３で行うアラート設定で設定できる項目は、製品ごとに異なります。APM なら、平均レスポンスタイムやスループット、パーセンタイルなどあります。また、ベースラインアラートという機械学習を利用したアラート設定では、過去のパターンから逸脱した場合、自動的に判断してアラートを飛ばしてくれる便利機能もあります。

アラート条件は以下の３つのステップで行います。

1. 製品と条件タイプの選択
   

2. 対象エンティティ(アプリなど）を選択。
   

3. 監視対象項目と閾値の設定
   

アラートポリシーの変更

わざわざアラートポリシーを作成するには、意味があります。それは、アラート疲れを起こしにくくするためです。アラート疲れとは、アラート条件を必要な分だけバシバシ追加したせいで、アラートが飛びまくって、受信者が大量にアラートを受けて、疲弊していくことです。これによって、疲弊が続くと、重要なアラートを見逃す可能性が高くなり、障害対応に遅れるといった弊害まででてきます。よって、必要な数のアラートを必要な人に通知できる必要があります。それをサポートするのが、アラートポリシーとその設定です。

アラートポリシーは以下の３つの設定があります。どれを選ぶかで、アラート条件に違反した際にインシデントが発生(したり、実際にアラートが飛んだり）するかが代わります。

• By Policy (デフォルト) : ポリシー単位。ポリシーに存在するアラート条件にひっかかったらインシデントを作成。そのインシデントが解決(引っかかった条件の閾値以下となる)されるまで、別のアラート条件にひっかかってもインシデントは発生しない。
• By Condition: 条件単位。ポリシーに存在するアラート条件にひっかかったらインシデントを作成。そのインシデントが解決されない内に、別のアラート条件にひっかかってもインシデントは発生する。しかし、現在、アラート条件にひっかかっているエンティティと別のエンティティでも、インシデントは発生しない。
• By condition and entity: 条件かつエンティティ単位。ポリシーに存在するアラート条件にひっかかったらインシデントを作成。そのインシデントが解決されない内に、別のアラート条件にひっかかってもインシデントは発生する。現在、アラート条件にひっかかっているエンティティと別のエンティティでも、インシデントは発生する。

アラートポリシーは、アラートポリシー画面右上のギアアイコンの "Incident preference: By xxx" が現在設定されているポリシーとなります。ここをクリックすると、上のポップアップが表示され、設定変更ができます。

アラートはかなり奥が深いので、詳しく知りたい方は以下を参考にしてください。

• New Relic Alert: 柔軟なアラートの設定でインシデントを効率よく管理しよう
• ドキュメント:ベースラインアラート条件の作成
• New Relic APM の最新アラート設定の紹介 - パターン認識アラートもあるよ

また、New Relic Alerts には NRQL アラートという非常に強力なアラート設定もありますので、そちらも是非チェックしてください。

New Relic アカウント

New Relic はアカウント単位(基本１社１アカウントを推奨）でアプリやサーバーなどを管理していきます。そこに、ユーザーを紐付けていきます。New Relic アカウントを作成したユーザーがオーナーとなり、UI 上からプランの変更が行えます。オーナーは１アカウント１ユーザーです。

New Relic のアカウント設定画面へのアクセス手順は以下の通りです。(以下の説明では、この画面いることを前提とします）

1. New Relic にログイン後、画面右上のアカウント名をクリック
2. Account settings をクリック

権限

ユーザーごとの権限は、オーナー(Owner)、管理者(Admin)、ユーザー(User)、制限付きユーザー(Restricted)があります。設定系の変更やアラート条件の作成などは、オーナーか管理者しかできません。ユーザーとロールについて詳しく知りたい方は、こちらのドキュメントをご覧ください。

また、最近より細かいロールの管理(Add-on role)が行えるようになりました。製品ごとに、設定変更や設定の削除などが行えるかといったロールをユーザーに付与できるようになりました。これによって、ユーザー権限でもある製品の設定は変更できるといった設定が行えるようになりました。Add-on role について知りたい方は、こちらのドキュメント[英語]をご覧ください。

ユーザーの追加や権限の変更

ユーザー管理やロール管理の画面へのアクセス方法は、以下の通りです。

1. 画面左メニューの Users and roles をクリック
2. ユーザー一覧が表示される。権限一覧を見たい場合は、左メニューの Roles を選択。

使用量の確認方法

New Relic のアカウント画面から、現在どれくらい APM のホスト数や CU 数を利用しているか確認できます。ここをみて、契約数以内になるようにマネージメントしてください。

アクセスするには、画面左メニューの Usage をクリックします。現時点は、APM、Browser、Mobile、Infrastructure の利用料を確認できます。日毎、月毎で確認できる他、サブアカウントを利用している場合は、すべてを合算した利用数も確認できます。

現在契約しているプランの確認

現在の製品ごとの利用プランは、アカウント画面の右上の Subscription に書いてあります。

わかりづらいですが、一番上の Web は APM のことです。トライアル中のものは、Pro Trial と書かれます。

プランを変更したい場合は、上記の変更した製品のリンクをクリックするか、担当の New Relic スタッフと連絡を取ってください。

サブアカウント

PRO プランを契約している場合は、サブアカウントを作れます。New Relic では部署ごとに New Relic アカウントを分けたい場合は、サブアカウントを利用して、部署ごとにサブアカウントを作ることを推奨しています。サブアカウントは、基本独立したアカウントなので、他のアカウントのユーザーは、別のアカウントにはアクセスできません。親アカウントのユーザーは、すべてのサブアカウントにアクセスできます。

APM のサービス連携機能のサービスマップなどでは、連携しているアプリがサブアカウントで分かれていた場合は、シームレスにアクセスはできません。

また、上で紹介した New Relic Insights では、アカウントをまたがってデータにアクセスできるため、全サブアカウントのアプリの平均レスポンスタイムを表示するダッシュボードなど作れたりします。

その他

その他、API を利用する場合のキーの作成やシングルサインオンの設定などができます。

まとめ

以上、New Relic サービスについて２回に渡り説明しました。どんな製品があり、どんなことができるのか分かって頂けたでしょうか？ 次回は、実際に New Relic 製品を使って(主に APM)、どのようにアプリケーションのパフォーマンス監視を行っていけばいいかを説明していきます。