シナリオ：データのルーティングとアーカイブにより、ストレージの使用とコストを改善する 🔗
以下のシナリオは、架空のeコマース企業であるButtercup Gamesの例です。
背景 🔗
SkylerはButtercup Gamesの中央observabilityチームの管理者です。Skylerは、会社の予算内に収まるように、様々なチームのobservabilityの使用状況を監視しています。
最近、Skylerはメトリック時系列（MTS）の使用量が増加していることに気づいていました。Splunk Observability Cloudアカウントチームの助けを借りて、Skylerは詳細なメトリクス使用レポートを取得しました。このレポートにより、SkylerはMTSの量、カーディナリティの高いディメンションの使用、チャートやディテクターでのMTSの使用、異なるチーム間でのMTSの分布に関する洞察を得ることができました。
Skyler は、あるチームが割り当てられた使用量の上限に近づいていることに気づきます。Skyler はそのチームのサイト信頼性エンジニア（SRE）リードである Kai に連絡を取り、チームの使用量を最適化するよう依頼します。Skyler は、カーディナリティの高いディメンションの MTS、MTS の総使用量、チームの MTS 使用量を Kai に伝えました。
調査結果 🔗
メトリクスの使用レポートを見ると、Kaiのチームは service.latency メトリクスの約50,000 MTSをSplunk Observability Cloudに送信していますが、完全な粒度のMTSがすべて必須というわけではありません。Kaiはレポートを見て、さまざまなディメンションのカーディナリティについて理解を深めています。
Kai は、彼らのチームがヨーロッパのデータセンターのサービス遅延のパフォーマンスだけを気にしていることを知っているので、data_center_region = Europe のデータだけをフィルタリングしています。しかし、他のデータをさらに深く調べたい場合に備えて、最近のデータにもアクセスできるようにしておきたいと思っています。
アクション 🔗
KaiはArchived Metricsを使用して、Splunk Observability Cloudがチームのデータをどのように保存するかを制御することにしました。
Splunk Observability Cloud で、Kaiは Settings にアクセスし、次に Metrics Management にアクセスします。Pipeline Management タブでKaiはメトリクス
service.latencyを検索し、取り込みルートをArchived Metricsに設定します。これでKaiはすべてのMTSをArchived MTSとして見ることができます。Kai はルート例外ルールを作成し、
data_center_region = Europeの場合にフィルターを指定します。これにより、2,497件のリアルタイム MTS が推定されます。Kai はまた、前の時間のデータを復元し、ギャップがないことを確認します。今、Kaiは、
service.latencyを使用しているチャートとディテクターのリストを表示します。リストの表示やダウンロードの詳細については、メトリクス使用状況レポートでメトリクスの使用状況を把握する を参照してください。Kai はすでにチャートとディテクターに
data_center_region = Europeのフィルターを設定していました。Kai はチャートの1つにデータが表示されていることを確認します。Kai は Metric Pipeline Management のメトリクス
service.latencyを再度表示し、MTS の推定値を確認します。推定値は、リアルタイムの MTS カウントが50,000から2,497へと95% 減少したことを示しています。
概要 🔗
MTS の一部をアーカイブし、リアルタイムにルーティングすることで、Kai とSkyler は Buttercup Games のストレージコストを削減しながら、MTS の使用量を全体的に削減し、使用量の上限を下回ることに成功しました。
さらに詳しく 🔗
詳しくは、以下のドキュメントを参照してください：