概要

Tag Cardinality Control プロセッサーは、各メトリクスのタグ値の数を制限します。たとえば、userID のような無制限のタグキーを持つメトリクスの場合、メトリクスのカーディナリティの急増を引き起こし、取り込みコストやインデックス作成コストに影響する可能性があります。このような予期しない急増を防ぐには、プロセッサーを使用してフィルタークエリに一致するメトリクスにカーディナリティ制限を設定し、制限に達した後に受信したメトリクスを削除するか、それらのメトリクスのタグを削除します。

また、オプションでメトリクスごとのオーバーライドを構成して、特定のメトリクスの制限を設定するか、そのメトリクスをカーディナリティ制限の対象外にすることができます。メトリクスごとの各オーバーライドでは、メトリクス内の個々のタグにカスタム制限を設定するか、メトリクスごとのカーディナリティ制限の対象外にすることもできます。

セットアップ

Tag Cardinality Control プロセッサーをセットアップするには、次のようにします。

1. フィルタークエリを定義します。詳細については、メトリクス検索構文 を参照してください。
   • フィルターに一致するメトリクスのみが処理されます。
   • フィルタークエリに一致するかどうかにかかわらず、すべてのメトリクスがパイプラインの次のステップに送信されます。
2. ドロップダウンメニューで [Tracking mode] (追跡モード) を選択します。詳細については、厳密モードと確率的モードのセクションを参照してください。
3. タグごとの個別の値の最大数に対するカーディナリティ制限を入力します。この制限は、フィルタークエリに一致するすべてのメトリクスに適用されます。
4. [When the limit is reached] (制限に達したときの動作) ドロップダウンメニューで、カーディナリティ制限を超えたメトリクスに対してタグを削除するか、イベントを削除するかを選択します。

(オプション) メトリクスごとのオーバーライド設定

特定のメトリクスに対してカーディナリティ制限を設定するには、次のようにします。

1. サイドパネルで [Manage Overrides] (オーバーライドの管理) をクリックし、[Add Metric Override] (メトリクスオーバーライドの追加) をクリックします。
2. メトリクスの名前を入力します。
3. ドロップダウンメニューでオーバーライドモードを選択します。
   • Custom limit (カスタム制限): このメトリクスのカーディナリティ制限を設定します。
   • Exclude from limit (制限から除外): このメトリクスを、カーディナリティ制限の対象としてカウントしません。これは、重要なメトリクスを追跡しており、カーディナリティ制限のためにサンプルやタグを削除したくない場合に便利です。
4. [When the limit is reached] (制限に達したときの動作) ドロップダウンメニューで、カーディナリティ制限を超えたメトリクスに対してタグを削除するか、イベントを削除するかを選択します。

タグごとのオーバーライド

このメトリクスに特定のタグオーバーライドを追加するには、次のようにします。

1. [Add Tag Override] (タグオーバーライドを追加) をクリックします。
2. 制限を設定するタグキーを入力します。
3. ドロップダウンメニューでオーバーライドモードを選択します。
   • Custom limit (カスタム制限): タグごとの一意の値の数に制限を設定します。たとえば、タグ制限が 5 に設定されている場合、最初に受信した 5 つのタグ値が使用されます。
     • 注: タグ値は、Worker が再起動されるか、パイプライン構成が更新されるまで保持されます。パイプライン構成が更新されると、その更新によって Tag Cardinality Control プロセッサーが変更されない場合でも、タグ値はリセットされます。
   • Exclude from limit (制限から除外): 指定されたタグを持つメトリクスを、カーディナリティ制限の対象としてカウントしません。
4. タグキー値の最大数の制限を入力します。
5. [Add Override] (オーバーライドを追加) をクリックします。

プロセッサーの仕組み

厳密モードと確率的モード

Tag Cardinality Control プロセッサーは、タグのカーディナリティを追跡するために 2 つのモードをサポートしています。

• 厳密: メモリ使用量を最適化するためにタグ値を 8 バイトのハッシュとして保存しますが、かなり低い確率で 2 つの異なる値が同じフィンガープリントにハッシュされる可能性があります。
• 確率的: ブルームフィルター を使用して既知の値を追跡します。これにより、メモリ使用量を大幅に最適化できますが、誤検知が発生する可能性があります。誤検知は、まだ確認されていない値が誤って確認済みと判断される場合に発生し、プロセッサーが指定されたカーディナリティ制限をわずかに超える原因となります。

厳密モードのメモリ使用量

次に、厳密モードが使用するメモリ量を計算する式を示します。

$$A = \text"total number of metrics"\ \×\ \text"average number of tag keys per metric"$$

$$B = \text"average length of each tag key"\ + (\text"value_limit"\ \×\ \text"average length of tag values")$$

$$\text"Memory usage" = A\ \×\ B$$

すべてのタグ値は 8 バイトのハッシュフィンガープリントとして保存されるため、average length of tag values は 8 となります。

確率的モードのメモリ使用量

確率的モードでは、ブルームフィルターを使用してすべての (メトリック、タグ) ペアの既知の値を追跡します。たとえばメトリック名が request.latency でタグキーが host および region の場合、追跡されるペアは次のようになります。

• (request.latency, host)
• (request.latency, region)

次に、確率的モードのメモリ使用量を推定する式を示します。

$$A = \text"total number of metrics"\ \×\ \text"average number of tag keys per metric"$$

$$B = \text"average length of field names for the tags"\ +\ \text"cache_size_per_key"$$

$$\text"Memory usage" = A\ \×\ B$$

cache_size_per_key は、標準的な式を使用する Bloom Filter Calculator で算出できます。ここで、n はカーディナリティ制限であり、誤検知率 (p) は Worker 内で 0.1% に固定されています。

厳密モードと確率的モードのベンチマーク

次の表に、厳密モードと確率的モードのベンチマークを示しています。各タグの一意の値の数が増えるにつれて、確率的モードのメモリ効率が高くなります。これらのベンチマークに使用されたメトリクス名とタグ名は、ランダムに生成された 20 バイトの文字列です。

ベンチマークに使用されたマシンタイプは、AWS M6gd.4xlarge インスタンスです。

追跡対象メトリクスが 10,000 個の場合のベンチマーク

次の表に、10,000 個のメトリクスを追跡する際の確率的モードと厳密モードにおける Worker の RSS メモリ使用量を示します。

メトリクスあたり 10 個のタグ

追跡対象メトリクスが 50,000 個の場合のベンチマーク

次の表に、50,000 個のメトリクスを追跡する際の確率的モードと厳密モードにおける Worker の RSS メモリ使用量を示します。

メトリクスあたり 10 個のタグ

メトリクスあたり 50 個のタグ

追跡対象メトリクスが 100,000 個の場合のベンチマーク

次の表に、100,000 個のメトリクスを追跡する際の確率的モードと厳密モードにおける Worker の RSS メモリ使用量を示します。

メトリクスあたり 10 個のタグ

メトリクスあたり 50 個のタグ