メトリック集計プルーニング：メトリックカーディナリティ管理のための新しいツール

New Relicは、New Relic Oneのディメンションメトリックカーディナリティを管理する新しいツールである、メトリック集計プルーニングのリリースを発表しました。　

この、新しいメトリック集計プルーニング機能により、メトリックデータ上のどの属性が長期的なトレンドと分析に重要で、どの属性が短期のトラブルシューティングに関連しているかをNew Relic Oneに伝えるルールを作成することができます。長時間に渡ってクエリを実行するような場合に、不要な属性を「プルーニング」するようにNew Relic Oneを設定することで、データの有用性を低下させるカーディナリティの制限に達することを回避することができます。

NerdGraphのデータドロップルールデータ管理APIに、メトリック集計プルーニングが新たに追加されました。　　お客様がカーディナリティ制限とデータドロップルールAPIを既に使われていて、すぐにメトリック集計プルーニングを始めたい場合は、ドキュメントをご参照頂くか、新しいメトリック集計プルーニングの使い方をご確認ください。

メトリックカーディナリティをご存じない方のために、カーディナリティとは何か、カーディナリティの制限に達したかどうかを知る方法、そしてこの問題に対する3つの解決策について簡単に説明します。　

メトリックカーディナリティとは何ですか?

メトリクスは、オブザーバビリティプラットフォームにとって重要な要素です。これらは、システムで使用されているCPUの割合のような単一のデータポイントを表すポイントインタイム測定値、または過去1分間にネットワーク上で送信されたバイト数のような集計測定値です。そのため、経時的なトレンドの特定や変化率の観察に適しています。

モニタリングにおいて、カーディナリティとは、メトリックに含める属性について存在するキーの値ペアの一意の組み合わせの数を指しています。例えば、「cpuPercent」と呼ばれるCPUの使用率を表すメトリックがあり、このメトリックは、各システムから報告されるとします。このメトリックにホスト名属性を含めると、メトリックが報告されたシステムを識別できるようになり、「ホスト1」と「ホスト2」という2つのホストが報告されている場合、カーディナリティは低くなります。これは、ホスト名属性が1つだけで、メトリックのユニーク値のホスト1とホスト2が2つあるためです。従って、カーディナリティが2であるということになります。その代わり、ホスト名属性とプロセスID属性を持つ「cpuPercent」というメトリックがあり、システム上の各プロセスについて報告され、数千のシステムがある場合は、高いカーディナリティが存在することになります。これは、数百万通りのプロセスIDとシステムの独自の組み合わせが考えられるからです。

カーディナリティが低い値も（特に）高い値も、「今日の午前9時30分から10時30分の間に504エラーを経験したすべてのユーザーを教えてください」という質問に答えようとするときに重要になります。オブザーバビリティにおける高いカーディナリティのデータの重要性については、この投稿で概説しています。この問題を解決するためには、多くのデータを相関させる必要があります。しかし、膨大なデータで検索に支障が出るようでは困ります。

New Relic Oneにメトリックデータを送信すると、送信した生のデータポイントをすべて保存するだけでなく、それらのメトリックをさまざまな間隔でロールアップと呼ばれる新しいデータポイントに集計します。このため、特に長い時間において、保存効率とクエリの速度が向上します。クエリを迅速に返すために、New Relic Oneはクエリに応じて生のデータポイントまたはロールアップのどちらを使用するかを決定します。

メトリック集計プルーニング時期の見極め方

基盤となるデータプラットフォームのパワーとスケールにより、New Relicは、任意の日に、数百万の独自のメトリックの時系列を持つアカウントのデータを簡単に処理することができます。しかし、すべてのシステムがそうであるように、システムを保護し、すべての人にとってのパフォーマンスを維持するために、いくつかの制限を課さなければなりません。　

カーディナリティが制限に達した場合、New RelicはアカウントにNrIntegrationErrorを報告します。これはNRQLを使用してクエリが実行可能なイベントです。また、New Relic Oneのデータ管理ハブの制限セクションにも表示されます。制限に達すると、New Relicはすべてのデータの処理と保存を続行しますが、その日の残りの時間はロールアップの作成を停止します。この現象が発生したときに1時間以上にわたりクエリを見ていた場合は、データが報告されなくなったと思うかもしれませんが、それはこのような長い時間ウィンドウのクエリに使用されるロールアップが利用できないからです。

心配は無用です：前述の通り、送信された生データはそのまま使うことができます。アクセスするには、より短い時間（1時間以内）でクエリを実行するか、クエリにRAWキーワードを付加して、トラブルシューティングに必要なデータを取り込むことができます。　制限に達することを完全に回避するには、新しいメトリック集計プルーニングを使用することができます。

新しいメトリック集計プルーニングの使い方

メトリック集計プルーニング（DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES）では、メトリックロールアップから除外する1つまたは複数の属性を指定することができます。

メトリック集計プルーニングは、コンテナIDやその他の一意の識別子など、メトリクスに含まれることがあるカーディナリティの高い属性に最適です。これらの高いカーディナリティの属性は、インシデント発生時（狭い時間ウィンドウ）のトラブルシューティングでは重要な詳細を含んでいますが、時間の経過とともにその価値を失い、長期的なトレンドを探る際には適切ではありません。

次のスクリーンショットでは、some.metricという仮定のメトリックに対して、containerId属性のプルーニングを設定する例をご紹介しています。

その他のソリューション

他にも、カーディナリティの制限に達しないようにするための2つの方法があります。

• データを分割して、複数のNew Relicのサブアカウントに送信することができます。
• また、価値の低いメトリクスやその属性を、クライアントサイドで、あるいはNerdGraphで利用可能なデータドロップ機能を使って永久的にドロップすることができます。この方法でドロップしたメトリクスや属性は、一切保存されません。