高カーディナリティメトリクスの理解と照会

高いカーディナリティがどのように機能するかを理解することは、データの制限に達するまでの時間に影響を与えるため、重要です。

カーディナリティとは何か、なぜそれが重要なのか？

カーディナリティ（Cardinality）とは、一般的に集合の要素数と定義される。次元メトリクスの場合、問題となる集合は、あるメトリクスについて1日の間に観測された属性のユニークなマップの集合です。New Relic でメトリックのカーディナリティを問い合わせるには、以下の NRQL フォーマットを使用します。

FROM Metric SELECT cardinality(metric.name) SINCE today RAW

たとえば、メトリック memory.heap のカーディナリティを照会し、このメトリックに対する一意のキーと値のペアがいくつ存在するかを調べるには、次のクエリを実行します。

FROM Metric SELECT cardinality(memory.heap) SINCE today RAW

カーディナリティとは何かという基本的なことは簡単ですが、カーディナリティの高さに対処し管理する方法を学ぶのは少し複雑になります。

カーディナリティの制限と強制

New Relic では、メトリックのカーディナリティの制限をメトリックごとのレベルとアカウントレベルの両方で実施しています。カーディナリティの評価は、UTC の 1 日 (00:00:00 UTC から 23:59:59 UTC) をかけて行われます。

データの制限と関連するポリシーについては、 New Relic data usage limits and policies をご覧ください。

カーディナリティと次元測定法

あるメトリックのカーディナリティとは、1日の間にそのメトリックについて観測された属性のユニークなマップの集合の大きさである。そのマップのキーや値が時間の経過とともに変化すれば、そのメトリックの新たなカーディナリティが追加される。例を見てみましょう。

4つのホストからなるネットワークで、それぞれのホスト上で2つのコンテナが稼働しており、各コンテナが定期的にゲージメトリック memory.heap を、ホスト名とコンテナIDを属性として追加して報告しているとします。

Metric APIに送信すると、これらのメトリクスの1つは以下のようになります。

"metrics":[
  { 
    "name":"memory.heap", 
    "type":"gauge", 
    "value":5514, 
    "timestamp":1234567890,
    "attributes":{
      "host":"W",
      "container":"1"
    }
  }
]

これは、 ホスト および コンテナ の一意のマッピングがいくつ可能かを示すためです。このメトリックの新しい測定値が、以前に報告されたものと同一の属性で測定された場合、新しいカーディナリティはカウントされません。

カーディナリティの影響

上記のように、キーや値に変更があれば、新しいカーディナリティを表すことになりますが、それらの変更が全体のカーディナリティにどのような影響を与えるかを予測するのは、少し難しいことです。メトリックのカーディナリティは、可能性のある各キーに対するすべての可能性のある値の数の積であると仮定したくなるが、あるキーの値が他のキーの値に依存したり決定したりすることが多いため、実際にはほとんどない。

前述の例では、 コンテナ の値が 1 であった場合、 ホスト の値は W に固定され、これらのコンテナ ID はグローバルに一意であると仮定します。つまり、4 つのホストに 8 つのコンテナがあるとはいえ、カーディナリティは 8 であり、4 * 8 = 32 ではありません。なぜなら、単純乗算法でカウントされるほとんどの組み合わせは不可能であり、したがってそのメトリックのカーディナリティには寄与しないからです。例えば、 host = 'X', container = 1 のような組み合わせはあり得ません。

これは、属性マップにキーを追加しても、必ずしも全体のカーディナリティが増加するわけではないことも意味します。新しいキーの値が既存のキーの値によって一意に決まる場合は、長期的には新たなカーディナリティは増えません。例えば、例のマップに リージョン のようなものを追加した場合、 コンテナ の値も特定のリージョンの値に固定されている可能性が高く、そのためカーディナリティを8に保つことができます。

ここでの重要な注意点は、 region を追加しても今後のカーディナリティは増加しないが、最初に追加されたときには新しいカーディナリティが発生するということである。これは、キーを追加することで、その属性マップがそれまでの属性マップとは異なるものになり、その日のカーディナリティの合計が一時的に増加するためです。

ワークフローの例とサンプル

カーディナリティの上限に達した場合、状況を改善するために使用できるオプションがいくつかあります。しかし、そうしたくない場合は、どのディメンションがカーディナリティに最も貢献しているかを調べ、価値を提供していないディメンションを削除することを検討するのが良い方法です。これにより、ストレージと帯域幅のコストを削減し、制限値を上げる必要がなくなる可能性があります。

カーディナリティ・コントリビューターの検索：メトリクス

特定のメトリックのカーディナリティを取得する方法を思い出してください。

FROM Metric SELECT cardinality(memory.heap) SINCE today RAW

アカウントの合計カーディナリティについては、同じ基本的なクエリ構造を使用し、単にメトリック名を省略することができます。

FROM Metric SELECT cardinality() SINCE today RAW

アカウントのカーディナリティは基本的に各メトリックのカーディナリティの合計であるため、シンプルなFACETクエリを追加することで、最もカーディナリティの高いメトリックを見つけることができます。

FROM Metric SELECT cardinality() SINCE today RAW FACET metricName

最後に、カーディナリティの上限に達したと思われる場合は、関連する NrIntegrationError をチェックすることで確認することができます。

FROM NrIntegrationError SELECT count(*) where name = 'CardinalityViolationException' and newRelicFeature = 'Metrics' facet cardinalityLimitType, metricName, message since today

カーディナリティ貢献者の発見：ディメンション

調査したいメトリックを決定したら、次のステップは、あるメトリックのどのディメンションがそのカーディナリティに最も貢献しているかを決定することです。ディメンションの値に慣れていない場合は、次のようにして見ることができます。

FROM Metric SELECT dimensions() WHERE metricName = 'memory.heap' SINCE today RAW

ここでは、JSON 結果ビューを使用することをお勧めします。これらに目を通すと、ユニークなIDやその他の高度に可変な値を含むディメンションが見つかり、削除する価値があるかもしれません。

自分の属性がどのような値を取ることができるかをすでに知っている場合は、 keySet() の結果を読み取ることが容易になるかもしれません。

FROM Metric SELECT keySet() WHERE metricName = 'memory.heap' SINCE today RAW

カーディナリティの合計に最も影響を与えるディメンションを理解するには、各キーの値が互いにどのように相関しているかを理解する必要があります。あるディメンションを除外リストに追加するだけで、そのディメンションがない場合のカーディナリティを試すことができます。

FROM Metric SELECT cardinality(memory.heap, exclude: {'container.id'}) SINCE today RAW

同様に、クエリのコンテキストに合わせて、インクルードリストも用意されています。

FROM Metric SELECT cardinality(memory.heap, include: {'host.name', 'region'}) SINCE today RAW

カーディナリティを管理することは、概念的には難しいことですが、上記の方法は、"どのメトリックが最もカーディナリティに寄与しているか？" や"ある属性がそのカーディナリティの合計に対してどのような影響を与えているか？" といった質問に対する答えを得るのに役立ちます。

カーディナリティは最もユニークな値を追跡する場合が多く、その値は他の属性が取り得る値を特定することができるからです。しかし、一握りの属性の可能な組み合わせが爆発的に増えることで、カーディナリティの合計が大きくなるケースも多々あります。一般的には、一意の識別子のようなものから始めるのが良いでしょうが、単一のキーではなく、2つ以上のキーの組み合わせである場合もあります。データとそれを生成するシステムに精通していればいるほど、どの属性を含めるべきか、あるいは除外すべきかを簡単に把握することができます。