シナリオ：集約ルールとドロップルールを組み合わせて、メトリクスのカーディナリティとボリュームを制御する 🔗
以下のシナリオは、架空のeコマース企業であるButtercup Gamesの例です。
背景 🔗
SkylerはButtercup Gamesの中央observabilityチームの管理者です。Skylerは、会社の予算内に収まるように、様々なチームのobservabilityの使用状況を監視しています。
最近、Skyler はメトリクスの使用量が急増していることに気づきました。Splunk Observability Cloud アカウントチームの助けを借りて、Skyler は詳細なメトリクス使用レポートを入手しました。このレポートにより、Skyler はメトリクスの量、カーディナリティの高いディメンション、チャートやディテクターでのこれらのメトリクスの使用状況、異なるチーム間でのメトリクスの分布に関する洞察を得ることができました。
Skyler は、あるチームが割り当てられた使用量の上限に近づいていることに気づきます。Skyler はそのチームのサイト信頼性エンジニア（SRE）リーダーである Kai に連絡を取り、チームの使用量を最適化するよう依頼します。Skyler は Kai に、カーディナリティの高いメトリクスとチームの使用量を伝えます。
調査結果 🔗
メトリクスの使用レポートは、Kaiのチームが service.latency メトリクスの約50,000メトリック時系列（MTS）をSplunk Observability Cloudに送信していることを示しますが、完全な粒度のデータすべてが必須というわけではありません。Kaiは、さまざまなディメンションのカーディナリティについてより深く理解するためにレポートを見ます。彼らは、instance_id と host_name ディメンションが、 service.latency の最もカーディナリティの高いディメンションであることに気づきます。
しかし、Kaiは、彼らのチームがサービスの遅延に関して、異なるリージョンを最も気にしていることを知っているので、region ディメンションだけを監視したいと思います。instance_id または host_name のディメンションは、彼らが監視する必要のある情報ではありません。
アクション 🔗
Kaiは、Splunk Observability Cloudがチームのデータをどのように取り込むかを制御するために、メトリクス パイプライン管理を使用することにしました。
Splunk Observability Cloudでは、Kaiは
service.latencyディメンションを維持し、regionとinstance_idを破棄することで、host_nameのカーディナリティを削減する集約ルールを作成します。Kai は、1,623MTSしか得られない新しい集計された
service.latency_by_regionメトリクスを持っています。Kaiは、
service.latencyメトリクスを使用するチャートとディテクターのリストをダウンロードします。関連する各チャートとディテクターについて、Kai は
service.latencyをservice.latency_by_regionに置き換えます。Kai はSkyler に、集計されたメトリクスを作成し、関連するすべてのチャートとディテクターを更新したことを知らせます。
Skylerは、メトリクスパイプライン管理 ページで
service.latencyを選択し、メトリクスの現在のルールを表示します。Skyler は Keep data を Drop data に変更します。
Skyler は不要なデータをドロップした後、新しいメトリクス量を確認し、ルールを保存します。
概要 🔗
Kai とSkyler は、集計とデータドロップルールを組み合わせることで、高いカーディナリティのメトリクスをまとめることに成功し、Buttercup Gamesのストレージコストを最小限に抑えながら、チームにとってより集中的なモニタリング体験を生み出しています。
さらに詳しく 🔗
詳しくは、以下のドキュメントを参照してください：