Docs » Splunk Observability CloudとSplunkプラットフォームのシナリオ » シナリオ:KaiがIT Service IntelligenceとSplunk Observability Cloudを使用して迅速なトラブルシューティングを実行する

シナリオ:KaiがIT Service IntelligenceとSplunk Observability Cloudを使用して迅速なトラブルシューティングを実行する 🔗

自社製品を販売するECサイトを運営する架空の企業、「オンラインブティック」は、突然オンライン販売の収益が低下する事態に見舞われます。「オンラインブティック」のサイト信頼性エンジニアであるKaiは、Splunk IT Service IntelligenceとSplunk Observability Cloudを併用して、トラブルシューティングを迅速化します。

問題のトラブルシューティングのため、Kaiは次のようなアクションを取ることにしました:

  1. Splunk IT Service Intelligenceでサービスの健全性をチェック

  2. Splunk Observability Cloudを使用したトラブルシューティング

Splunk IT Service Intelligenceでサービスの健全性をチェック 🔗

  1. Kaiは、Splunk IT Service Intelligence(ITSI)を開いて、サービスの健全性を監視する画面に移動します。この画面には、リアルタイムで更新されるサービス健全性スコアが表示されています。

    このスクリーンショットは、Splunk IT Service Intelligence内でサービス健全性を追跡する画面を示しています。
  2. この画面の「サービス健全性スコア」セクションで、Kaiは、「精算サービス」の「Syntheticsチェック」と「Real User Monitoring」の下に、健全性の状態が悪いことを示す赤い点があることを確認しました。また、「決済サービス」の「Real User Monitoring」と「Application Performance Monitoring」の下にも、健全性が低いことを示す指標を確認しました。Kaiは、「精算サービス」の「Syntheticsチェック」の下の赤い点を選択して調査を開始しました。これにより、Splunk Observability CloudでSyntheticsが開きます。

    このスクリーンショットは、Splunk IT Service Intelligenceの画面の「サービス健全性スコア」セクションをクローズアップしたものです。

Splunk Observability Cloudを使用したトラブルシューティング 🔗

Splunk Observability Cloudで、Kaiは、Synthetic MonitoringとApplication Performance Monitoring(APM)ビューを使用してITSIで最初に特定した問題をトラブルシューティングします。

Splunk Synthetic Monitoringでの合成テストの調査 🔗

  1. Syntheticsビューで、Kaiは、失敗したテストの1つを開き、最新の実行結果のセクションまでスクロールダウンして、結果の1つを開きます。そして、Splunkが「オンラインブティック」のウェブサイトの各要素のフロントエンドサービスを追跡していることに気がつきます。Splunkはエンドツーエンドのカスタマージャーニーの視覚的体験も追跡しているので、ビデオキャプチャで、顧客が表示する画面を再生できます。

    このスクリーンショットは、Syntheticsの最近実行されたテストを示しています。
  2. Kaiは、右上のビデオキャプチャを再生します。ビデオキャプチャは、ユーザーが購入を試みたものの精算で問題が発生したことを示しています。このアプリケーションはユーザーに対してエラーもフィードバックも提供していないため、受け入れられないカスタマーエクスペリエンスとなっています。Kaiはビデオキャプチャを閉じます。

    このスクリーンショットはSyntheticsビューを示すもので、右上にはユーザーエクスペリエンスのビデオキャプチャが表示されています。
  3. Kaiは、長くかかった精算リクエストの横にあるAPMのリンクを選択してSplunk APMを開き、どのプロシージャコールが遅いか、停止しているか、失敗しているかを確認します。Splunk APMの完全忠実トレーシングを使用して、この問題が発生した正確な時刻から再構築したアプリケーションマップにピボットしたり、ライブのサービス依存関係マップを表示したりすることができます。

    このスクリーンショットは、SyntheticsからAPMへのリンク方法を示しています。

Splunk APMでサービスの依存関係を調査 🔗

  1. Splunk APMで、Kaiはライブサービスマップに移動することにしました。そして外部クライアントと決済サービスの間の遅れを示す赤い線を見つけます。paymentservice にカーソルを合わせて、それが多くの根本原因エラーに関与していることを確認します。

    このスクリーンショットは、フロントエンドの精算サービスと決済サービスをクローズアップしたものです。
  2. Kaiはマップ上で paymentservice を選択し、アプリケーションのバージョン別に決済サービスを分割して、最近のコードプッシュが顧客に悪影響を及ぼした可能性を明らかにします。右のパネルで、Breakdown を選択し、次に Version、そして Errors を選択します。案の定、新バージョンのコードがすべての遅延と根本原因エラーを引き起こしています。Kaiは開発チームに、新しいバージョンのv350.10をロールバックすべきだと伝えます。

    このスクリーンショットは、決済サービスをコードバージョン別でフィルタリングしたサービスマップを示しています。すべてのエラーが最近のコードプッシュに関連しています。

収益低下問題の原因を突き止めた後、KaiはSplunk IT Service Intelligenceの画面に戻り、当該のアプリケーションとビジネスサービスを、同時期に発生したセキュリティ重要ベントと関連付けることができました。脅威アクティビティと、その直前に発生したアクセスとネットワークのアクティビティを確認しました。すぐにセキュリティチームにこの調査結果を報告します。

This page was last updated on 2023年10月20日.