背景

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

最近、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 がチームのデータを取り込む方法を制御するために、メトリクスパイプライン管理を使用することにしました。

1. Splunk Observability Cloudでは、Kaiは service.latency ディメンションを維持し、region と instance_id を破棄することで、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のストレージコストを最小限に抑えながら、チームにとってより集中的なモニタリング体験を生み出しています。

さらに詳しく

詳しくは、以下のドキュメントを参照してください：

• メトリクス パイプライン管理の概要

• データルーティングを使用して、メトリクスの保存、アーカイブ、破棄を行います。

• 集計ルールを使ってデータ量をコントロールする

• メトリクス使用状況レポートでメトリクスの使用状況を把握する