APMやBrowserなどのNew RelicのデータとNRDBは強力で、柔軟な分析を実現できる一方で、データ保持期間がそれ程長くないという特徴があります。そのため、中長期のトレンドを保持しにくいというのは課題でした。そこで今年、それらのイベントデータを集計してメトリックの形に変換し、長期に保持するevent-to-metricsが登場した（「イベントからメトリクスへの変換 events-to-metrics service が公開されました」をご覧ください）というのがこれまでの流れだったのですが、さらに今回、その設定が画面上からできようになりましたので、紹介いたします。
イベントか、それともメトリックか
APMやBrowserなどのNew Relicエージェントの多くは、様々な事象（アクセスの発生やユーザーのアクションなど）をイベントという形で記録し、New Relicに送っています。送られたイベントはクエリされ、APMやBrowserなどの画面上でパフォーマンスデータとして加工・表示されたり、NRQLでクエリされてダッシュボードとして表現されたりします。詳細なイベントデータをそのまま保持し、クエリできる状態にして、柔軟に分析できる。これがNew Relicが持つ強力さの一つでしょう。
ただし、過去全てのデータをクエリできるようにしておくのは、コストの観点から妥当とはいえません。そこで、中長期に渡るトレンドを分析するために、予め集計されたメトリックとして扱うのがよくやられます。集計することでデータ量を削減し、長期間に渡るデータを取り扱い安くするものです。
イベントとメトリック、それぞれの特徴は次のようにまとめられます（以前のブログエントリにも記載していますが、再掲します）。
- 主な使い方
- イベント：トラブル調査: トランザクションイベントを個別に分析して原因調査をする
- メトリック：長期トレンドや異常値の把握: 中長期に渡ってデータセットからKPIを集計し、分析する
- 柔軟性
- イベント：高い。様々なクエリに返答することができ、発行するクエリをあらかじめ定義しておく必要はない。あらゆる粒度で分析できる。
- メトリック：低い。メトリックはあらかじめ定義しておく必要があり、データの粒度は固定的。
- ベストプラクティス
- イベント：データ量が多い場合は短期間の分析に、データ量が少ない場合は中長期の分析も可能
- メトリック：データ量に関わらず、長期間の分析が可能
- データ粒度：
- イベント：最小でミリ秒単位での取り扱いが可能
- メトリック：一定期間（最小は1分単位）で集計される
- データ保持期間
- イベント：標準で8日間（追加可能）
- メトリック：13ヶ月
Metric Aggregatorでメトリックを定義する
New Relicに保存されたイベントからメトリックを集計するには、2つの方法があります。1つ目はNerd Graphと呼ばれる、GraphQLのAPIを使う方法です。これについては以前のブログにもまとまっていますし、慣れた方には直感的に使えるものだと思いますので、ぜひ試してみてください。
もう一つの方法は、Metric Aggregatorと名付けられた、New Relic One Appを使う方法です。New Relic One AppはNew Relic One上で動くブラウザアプリケーションで、New Relicのデータやそれ以外のAPIを組み合わせて様々な情報をいい感じにまとめて、使いやすいUIを提供するものです。今回ご紹介するMetric Aggregatorは、そのNew Relic One Appで作られています。
Metric Aggregatorをセットアップする
初期状態ではMetric Aggregatorは有効になっていないため、有効にする必要があります。この作業にはNew Relic One Appの管理者権限が必要です。
one.newrelic.com を開き、上部にある App メニューからMetric Aggregatorを探してみてください。 中程にあるYour appsの中にあればすでにセットアップされている状態ので、そのままお使いいただけます。下段のNew Relic One catalogにある場合は、セットアップが必要です。メニューに従い、有効化してみてください。
メトリックを定義する
Appメニューから、Metric Aggregatorを開いてください（ユーザー毎に、初めてAppを開くタイミングでAppを有効化するかの確認が必要です。問題なければEnableを押して、Appを有効にしてください）。
すでに定義してあるメトリックルールがある場合、その情報が一覧表示されます。
それでは、Create Rulesからルールを作っていきましょう。
複数アカウントを使いの場合はアカウントを選び、次にベースとなるイベントタイプを選びます。この例では、APMの主なデータが集まっているTransactionイベントを選択しています。New Relicエージェントが計測しているイベントの情報は New Relic APMでレポートされるイベント にまとまっていますので、必要なものを探してみてください。
そして、どのような関数を使うかにあわせて、集計タイプを決めていきます。
- Summary: min, max, count, average … レスポンスタイムやスループットなど
- Distribution: percentile, histogram … レスポンスタイムの分布など
- UniqueCount: ユニークな数を集計、レスポンスコード・URL別のエラー数など
次にメトリックとして集計する値と条件、そしてディメンジョンを選んでいきます。下の例では、Transactionイベントのduration（レスポンスタイム）を値として、末尾に “prod” がついた複数のアプリケーションを条件に、appName（アプリケーション名）、name（トランザクション名）、host（実行されたホスト名）、httpResoponceCode（200, 404, 503など）毎のSummaryを集計するように指定しています。これにより、「httpResponceCodeが200のときのトランザクション名別のスループットと平均レスポンスタイム」のようなクエリの答えが得られるはずです。
注意：traceIdやtimestamp, 場合によってはrequest.uriなどのイベントごとにユニークな（またはユニーク近い）値をディメンジョンとして選ばないように気をつけてください。カーディナリティが急激に増大してしまいます。続くトピック「注意: カーディナリティの爆発を防ぐには」で詳しく補足します。右側でメトリックの指定の健全性がチェックできます。
最後に、メトリック名とルール名をきめていきます。ここは「Use suggested name」をクリックするとおすすめの名前が入力されるので、そのまま使うか、それをベースに分かりやすい名前にしてみましょう。この例では「Transaction.duration.summary.Filtered」がおすすめされたので、「Transaction.duration.summary.Production」に変更してみました。
最後にCreate Ruleすると、New Relic内部での集計が開始されます。データが溜まるまで5分程度待つ必要があるので、ここですこし休憩しましょう。
定義したメトリックをクエリする
休憩は取れましたか？それではいよいよクエリをしていきましょう。メトリック情報はすべて Metric というイベントタイプからクエリできるようになります。
なんと親切なことに、クエリ例がMetric Aggregatorに表示されています。
これをクエリビルダ―にペーストしてみましょう。表示されましたね！
また、今回はいくつかディメンジョンを指定してみましたね。それぞれをfacetで指定したり、where条件で絞り込んだりすることができます。
注意: カーディナリティの爆発を防ぐには
メトリックを扱う上でのリミットの一つに、カーディナリティ（Cardinality）上限があります。これは一言でいうと「組み合わせの複雑さ」です。New Relicではデータ処理上の負荷制御のため、1メトリックあたり100k、アカウント全体で1Mを1日の上限としており、それを超えると翌日までそのメトリックは「ロールアップ対象にならない（つまり、長期保管されない）」という制約があります。
理解しやすくするために、もう少し具体的な例で考えてみましょう。たとえば、「ウェブサーバーのレスポンスに関するSummaryをメトリックにして管理する」という状況を考えてみます。指定したディメンションは、次のような特徴を持つとしてみましょう:
- URL: 50通り
- http response code: 5通り
- company id: 100通り
このとき、カーディナリティは最大で 50 * 5 * 100 = 25,000 となります。実際には、あるURLに対してhttp respunse codeは200 okしかなかったり、あるcompany idに対してすべてのURLが使われるわけではなかったりして、現実的にとり得る組み合わせの数はこれよりも少なくなるのが普通です。気になる場合は、Metric Aggregator上でのカーディナリティ見積もりを見ながら設定してみましょう。
よくあるカーディナリティのトラブルとして、組み合わせの数が爆発してしまうようなディメンションを指定してしまうことがあります。例えば、上の例に加えてaccess tokenをディメンションに追加してみましょう。このトークンは、数分ごとにリフレッシュされるようなものを想像してみてください。このとき、1日で観測されるユニークなaccess tokenは1万通りある、としてみましょう。このときのカーディナリティは最大で 250,000,000 にもなってしまいます。ここにさらに、誰かの間違いでURLにリクエストパラメータの文字列が追加されたら、どうなるでしょうか。ちょっとした設定の変更で爆発しやすいのがカーディナリティの特徴です。
取り扱いに注意が必要ですが、意味がわかれば管理自体はそれほど難しいものではありません。意味あるメトリックを上手に残していきましょう。他にもいくつかのリミット設定がありますので、詳しくはドキュメントをご覧ください。
まとめ
いかがでしたか？
このように、APMなどのデータをメトリックとして長期保管したい場合、難しい操作が不要ですぐにお試しいただけるようになっています。
気になるのお値段の方ですが、今年8月に発表した新価格体型では契約変更なしにお使いいただけますし、メトリックによるデータ取り込み量の増分も適正に管理ができるようになっています。旧価格体型でお使いの方ももちろんご利用いただけます。気になることがありましたら、お気軽にご相談ください。
また、Metric AggregatorのソースコードはOSSライセンスで公開されています。中身の気になる方、なにか気になる動作を見つけた方は、リポジトリもぜひ覗いてみてください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
