イベントからメトリクスへの変換 events-to-metrics service が公開されました

イベントからメトリクスへの変換を定義したルールに基づいて実行するevents-to-metrice serviceが公開されました。以前より要望をいただいていた機能でもあるので、この記事にてご紹介したいと思います。New Relicの扱うイベントとメトリクスについて詳細に知りたい方はぜひこちらのブログをご覧ください。

https://blog.newrelic.co.jp/story/metrics-events-logs-and-traces/

このブログにある、イベントとメトリクスの得意なところ、苦手なところを引用してみました。

イベントの得意なところ

• 個別のデータポイントが含まれる
• 様々な質問に答えられる
• 素早く計算できる

イベントの苦手なところ

• イベントデータの保有コストは高い
• イベントデータの収集と送信は帯域を圧迫する
• クエリに時間がかかる

メトリクスの得意なところ

• 保存するデータを少なくできる
• ロールアップ時間を短縮

メトリクスの苦手なところ

• 分析するデータを事前に決める必要がある

この両者の違いが今回リリースする新機能のポイントです。イベントは様々な角度で高速に分析できるため、より近い過去を詳細にもしくはアドホックに分析するのに向いています。このような利用はメトリクスでは難しいでしょう。しかし、データ量が嵩むため、このままデフォルトの保持期間を超えて長期保存しておくとNew Relicでは追加の契約が必要となります。そこで長期で保存するユースケースを考えてみましょう。おそらく遠い過去のデータは詳細にもしくはアドホックに分析することは少なく、あらかじめ決まった視点で傾向を分析することが多いとNew Relicは考えています。

そこで、イベントとして記録しておいたデータを一定のルールに基づいてメトリクスに変換して保存することで、保存に要するデータ量を削減しつつ、長期保存時のユースケースに利用できるようにしたのがevents-to-metrics service(E2M)です。

EventとEvents-to-metricsを比較しました。

Events-to-metricsは次の図のように動作します。

具体例を考えてみましょう。New Relic APM Agentで収集しているhttpResponseCodeと、customerSegmentという名前のカスタム属性を使ってフィルタリングおよびファセットし、APMアプリケーションの平均トランザクション時間をチャートにしたいとしましょう。APMのTransactionイベントを利用してtransaction.responseTimeというメトリックを作成すればよいので、Events-to-metricsで簡単に実行できます。

このようなEvents-to-metricsのルールを作成します。

SELECT summary(duration) FROM Transaction AS ‘transaction.reponseTime’ FACET httpResponseCode, customerSegment

その後、NRQLでこのようなクエリで問い合わせます。

FROM Metric SELECT average(transaction.responseTime) WHERE numeric(httpResponseCode) = 200 TIMESERIES

Events-to-metricsに向いているクエリは次のような種類のクエリです。

• 予め定義されて、よく使うクエリ
• データの集合に対する最低、最大、合計、件数、平均や割合の値
• 大量のデータに対する長期あるいはゆっくりと実行するクエリ
• 高々20程度の既知の属性に対して問い合わせを行うクエリ

有償サブスクリプションをご利用の全てのNew Relicアカウントで、 10万カーディナリティを持った10万 DPM (data points per minute)までEvents-to-metricsを評価のためにご利用いただけます。New Relic にぜひお問い合わせいいただき、弊社エンジニアとより効果的な利用方法についてディスカッションさせてください。