シナリオ：Kaiが疎なデータを考慮してディテクターに最小遅延を設定する 🔗
Splunk Observability Cloudで、Buttercup Gamesのサイト信頼性エンジニアリング（SRE）チームは 「サービスエラー」 というディテクターを設定しています。このディテクターはButtercup Gamesのサービスを監視し、いずれかのサービスのエラー率が5%を超えたときにアラートを発します。
このアラートがあるにもかかわらず、Buttercup Gamesは、productcatalog サービスからのエラーに関する顧客からの苦情を受け取っています。
チームのSREであるKaiが productcatalog を調査したところ、このサービスはリクエスト率が低く、エラーのデータポイントを送信することはほとんどなく、1日に1回しか送信しないこともあることがわかりました。そのため解析エンジンは、この疎なエラー追跡MTSの遅延の増加を追跡できません。そのデータポイントは遅延が大きすぎるため 「サービスエラー」 ディテクターに含めることができず、ディテクターは productcatalog サービスに関するアラートを生成できません。
productcatalog からの遅延したデータポイントを考慮に入れるため、Kaiは /detector エンドポイントへのAPIコールを実行することによって 「サービスエラー」 の「最小遅延」の値を設定します。「最小遅延」設定により、ディテクターは計算を実行する前に一定時間待機しなければなりません。
Kaiは、この疎なMTSからのラグをグラフ化し、通常は30秒未満であるが1分を超えたことはないと判断したため、「サービスエラー」 の「最小遅延」を1分に設定します。
まとめ 🔗
「サービスエラー」 に「最小遅延」の閾値を設定することで、Kaiは疎なデータを含めることに成功し、顧客のエクスペリエンスに影響を与える前に productcatalog サービスからのエラーをキャッチできるようになりました。
さらに詳しく 🔗
ディテクターの「最小遅延」の詳細については、最小遅延 を参照してください。
ディテクターAPIの詳細については、ディテクターAPIリファレンス を参照してください。