シナリオ：KaiがKubernetesナビゲーターを使用してサーバー障害のトラブルシューティングを行う 🔗
以下のシナリオは、架空のeコマース企業であるButtercup Gamesの例です。
Buttercup Games のサイト信頼性エンジニア (SRE) である Kai は、Kubernetes 環境の Web サーバーの監視を担当しています。この1 時間、Kai は Apache ウェブサーバーが Splunk Observability Cloud でデータを表示しなくなったことに気づきました。他の Web サーバーはすべてデータを送信し続けているため、Kai は Apache 固有の問題ではないかと疑っています。
サービスの依存関係を調べる 🔗
さらに詳しく調査するため、Kai は Apache のサービス依存関係を調べています。
Kai はApacheナビゲーターからKubernetesノードナビゲーターに切り替えると、すぐにいくつかのKubernetesポッドが実行されていないように見えることに気づきます。
問題箇所を特定する 🔗
Using the hierarchical map, Kai drills down into the appropriate cluster and identifies the node with a failing pod. Kai can see that the pod is in a failed state.
Splunk Observability アカウントチームの助けを借りて、Kai は Pending ポッドのメモリ制限が正しく設定されておらず、起動できないことを突き止めました。
ポッドの障害を解決するために設定を更新する 🔗
Kaiはサーバー障害の根本原因を知ったので、Kubernetesの設定を更新し、ポッドを再起動した。Kai はポッドが稼働し、Apacheのダッシュボードに受信データが再び表示されていることを確認します。
概要 🔗
Kai used Splunk Observability Cloud to monitor web servers in a Kubernetes environment, and recognized a lack of data coming from Apache servers. Kai then opened Kubernetes Navigator, also called K8s Navigator, to help diagnose that problem and recognized a defective pod in the color-coded visualization provided by the navigator interface. They drilled down to the individual pod, spoke with the Splunk account team about parameters shown there, and determined that an incorrect memory limit had caused failure. When Kai updated the configuration and restarted the pod, the system worked again as designed.
さらに詳しく 🔗
Splunk Observability Cloud へのデータ送信については、Splunk Observability Cloud にデータを取り込む を参照してください。
Splunk Infrastructure Monitoring のナビゲーターの概要については、Splunk Infrastructure Monitoring でナビゲーターを使用する を参照してください。