Docs » Splunk Infrastructure Monitoring のメトリクス パイプライン管理 » シナリオ：集約ルールとドロップルールを組み合わせて、メトリクスのカーディナリティとボリュームを制御する

シナリオ：集約ルールとドロップルールを組み合わせて、メトリクスのカーディナリティとボリュームを制御する 🔗

Available in Enterprise Edition. For more information, see Subscription types, expansions, renewals, and terminations.

以下のシナリオは、架空のeコマース企業であるButtercup Gamesの例です。

背景 🔗

SkylerはButtercup Gamesの中央observabilityチームの管理者です。Skylerは、会社の予算内に収まるように、様々なチームのobservabilityの使用状況を監視しています。

最近、Skyler はメトリクスの使用量が急増していることに気づきました。Splunk Observability Cloud アカウントチームの助けを借りて、Skyler は詳細なメトリクス使用レポートを入手しました。このレポートにより、Skyler はメトリクスの量、カーディナリティの高いディメンション、チャートやディテクターでのこれらのメトリクスの使用状況、異なるチーム間でのメトリクスの分布に関する洞察を得ることができました。

Skyler は、あるチームが割り当てられた使用量の上限に近づいていることに気づきます。Skyler はそのチームのサイト信頼性エンジニア（SRE）リーダーである Kai に連絡を取り、チームの使用量を最適化するよう依頼します。Skyler は Kai に、カーディナリティの高いメトリクスとチームの使用量を伝えます。

調査結果 🔗

The metrics usage report shows that Kai’s team sends about 50,000 metric time series (MTS) for the service.latency metric to Splunk Observability Cloud, but not all the data at full granularity is essential. Kai looks at the report to understand more about the cardinality of different dimensions. They notice that the instance_id and host_name dimensions are the highest cardinality dimensions for service.latency.

しかし、Kaiは、彼らのチームがサービスの遅延に関して、異なるリージョンを最も気にしていることを知っているので、region ディメンションだけを監視したいと思います。instance_id または host_name のディメンションは、彼らが監視する必要のある情報ではありません。

アクション 🔗

Kai decides to use metrics pipeline management to control how Splunk Observability Cloud ingests their team’s data.

  1. In Splunk Observability Cloud, Kai creates an aggregation rule that reduces the cardinality of service.latency by keeping the region dimension and discarding instance_id and host_name.

  2. Kai は、1,623MTSしか得られない新しい集計された service.latency_by_region メトリクスを持っています。

  3. Kaiは、service.latency メトリクスを使用するチャートとディテクターのリストをダウンロードします。

  4. 関連する各チャートとディテクターについて、Kai は service.latency を service.latency_by_region に置き換えます。

  5. Kai はSkyler に、集計されたメトリクスを作成し、関連するすべてのチャートとディテクターを更新したことを知らせます。

  6. Skylerは、Metrics pipeline management ページで service.latency を選択し、メトリクスの現在のルールを表示します。

  7. Skyler は Keep data を Drop data に変更します。

  8. Skyler は不要なデータをドロップした後、新しいメトリクス量を確認し、ルールを保存します。

概要 🔗

Kai とSkyler は、集計とデータドロップルールを組み合わせることで、高いカーディナリティのメトリクスをまとめることに成功し、Buttercup Gamesのストレージコストを最小限に抑えながら、チームにとってより集中的なモニタリング体験を生み出しています。

さらに詳しく 🔗

To learn more, see the following docs:

このページは 2024年11月13日 に最終更新されました。