New Relicを使うかどうかは Event データを使うかどうかで判断するのが良い(と思っている)
オブザーバビリティツールを選ぶときにコストであったり機能であったりを比較すると思うのですがその中で New Relic を評価する場合私はそれらの項目以外に New Relic の Event データを活用するのかどうかで判断するのがいいと考えているのでその紹介しようと思います。
あくまで個人の意見の一つにはなるので正解ではありませんが参考までに御覧ください。
New Relic 自体の紹介や機能についてはあまり触れない予定です。
またトレースデータは役割が分散トレースのためとしっかりしているのでメトリクスとログに着目して触れる予定です。
Event データとは？
世の中のオブザーバビリティにおけるテレメトリーシグナルと言えば Metrics, Logs, Traces, かなと思いますが New Relic それに Events(以降 イベント と表現) というシグナルを加えて MELT と言われる４つのデータを扱っています。
イベントと言われるとモニタリング的に考えると単純に発生したことを記録するようなもの、例えばサーバーが更新されたなどをイメージされるかもしれません。
New Relic におけるイベントとはあるデータタイプ、例えば APM からはリクエストがあった場合に Transaction というイベントデータを生成しますがそのデータには単にリクエストがあったことではなく様々な属性情報が同時に付与されて記録されます。
試しに New Relic の Transaction データをクエリしてみましょう。
様々な属性の key value のセットが記録されています。
この情報の中には応答時間やヘッダー情報、ホストの情報などが含まれています。
一見するとただのログのように感じるかもしれませんがデータベースへのコールしたカウントや応答時間も含まれておりパフォーマンス情報として多くの記録をしています。
Transaction にどのような情報が含まれるかは data dictionary をご覧ください。
イベントがどのようなものをかというのを端的に表現すると その時にあった複合的な情報をわかりやすく構造化しているデータ だと考えています。
では次にこのイベントデータの何がいいのかについて紹介します。
何が良いのか？
イベントデータを一見して見てみるとログのようなメトリクス情報のようなものとして考えることもできます。例えばログでいうとエラーレベルなどは同じようにログに出力ができるかと思いますしメトリクスで言えば応答時間などはメトリクスで記録されます。
それぞれはログは出力情報として詳細な情報が出力されていますしメトリクスは統計情報として有益な情報が記録されます。ではなぜ Event があるのか、それはメトリクスとログのそれぞれの情報を補完してくれる立ち位置にあると考えています。
分析の粒度を柔軟に変えやすい
先ほどログは詳細な、メトリクスは統計情報として優秀だという話をしましたがログはログを出力させるための設定やアプリケーションの場合はログの出力するためにソースコード上への実装が必要になります。
メトリクスの場合は統計情報になるので例えば１分間単位でレポートされるメトリクスの場合、それらの中身でどのようなことが起きていたのかを知る術はメトリクスからはありません。そのようなことを知りたい場合、ログから調査するかアプリケーションであればトレース情報から分析が必要になります。
イベントデータは単一のイベント情報の中にパフォーマンス情報を使った時系列の分析や
エラーの情報なども分析ができます
このようにして分析の幅を自由にできるのがイベントデータの特徴になります。
またイベントデータは単一のイベントに対しての情報になるのでメトリクスでは見れないような一件一件の情報を分析することも可能です。
でもそれはログでもできることでは？と思った方もいるかも知れませんので２つ目の良いポイントを紹介します。
エージェントがデータを自動で生成してくれる
これはイベントデータが優れていることではなく New Relic の APM を始めとしたエージェントと言われるものが自動的にイベントデータを作成してくれることにメリットがあります。
例えばログの場合はアプリケーションコードにログを出力するための実装をする必要があります。
しかしイベントデータは New Relic のエージェントを導入することによって自動的に生成してくれるという実装になっているため追加の計測のための実装などが極力必要でなくなるというメリットがあります。
計測や計測のための実装に工数を割いてしまうのは本末転倒なことになってしまうこともあるのでこれらの点は大きなメリットとして理解しておくと良いと考えています。
もちろんカスタムでこのようなイベントを作成することも可能です。
利用ユーザーの個別分析のしやすさ
イベントデータはカスタムで user_id などのパラメーターを入れることによって個別のユーザー分析などができるようになっています。
同様のことをカスタムメトリクスでも可能ですがカーディナリティが増えすぎてデータ量が膨大になってしまいデータ量だけで大変なことになるケースは多々あります。イベントデータは件数によるサンプリングをしておりイベントデータの数を意識すればある程度のデータ量調整が可能なのでデータ量による破産などは起こりにくいような設計にはなっていることも魅力です。
例: APM の Transaction データは1分間に収集できる上限が定められています。
当然ログでも同様のことは可能ですが応答時間の属性などがあるデータにユーザーIDが紐づいて分析できるのは個人的にはとても魅力に感じています。
イベントデータの弱点
イベントデータは利点が多いのですが弱点もあります。
それはサンプリングの上限があるのでそれを超えたものに関しては収集されない点にあります。
オブザーバビリティの世界ではサンプリングはある意味常識的な部分もあるのである程度考慮されている部分もありますが少なからず取りこぼしされるような可能性はあります。
またある程度長期的な分析においてはイベントデータはデータの保持期間がメトリクスより短いためメトリクスでないと出来ない部分もあります。
まとめ
簡単に説明しましたが私としてはイベントデータを利用しないのであれば New Relic のメリットが無くなってしまうのでメトリクスやログの SaaS プラットフォームとして採用しようと思っているのであれば一度立ち戻ってみるのも一つだと考えています。
New Relic の MELT は非常に便利でそれを NRQL で利用できることが非常に大きな特徴になっていますので是非その観点での選定をご検討ください。
New Relic にはどのようなデータを扱っているのかがドキュメントに載っていますのでこちらも併せて見てもらうと理解が深まるかもしれません。
Discussion