メインコンテンツまでスキップ
Sumo Logic Japanese

Explore を使用したトラブルシューティング

Explore で根本原因をすばやく特定する方法がわかるトラブルシューティング シナリオについて説明します。

Explore のナビゲーションを使用すると、デバッグが必要な物理スタック内のオブジェクトをすばやく特定できます。このページでは、トラブルシューティング シナリオを概説し、考えられる解決策を示します。

トラブルシューティングの概要 

ステップ 1: クラスタの分析

Kubernetes クラスタに問題があると思われますが、場所がわかりません。そのため、最初に [Cluster Overview (クラスタの概要)] ダッシュボードを分析します。このダッシュボードには、クラスタで実行中のすべてのものが表示されます。[Terminated and Waiting by Namespace (名前空間別の終了および待機)] パネルでは、各名前空間の障害の状態を簡単に把握できます。このパネルにより、設定の問題と管理全般の問題のどちらに対処すべきかがすぐにわかります。

Explore_TS_Cluster_Overview.png

ステップ 2: 名前空間の調査

クラスタの問題の特定を進めるため、ナビゲーション パネルで [kube-system] を選択し、名前空間を調査してから、[Namespace Overview (名前空間の概要)] ダッシュボードに切り替えます。このダッシュボードには、デプロイで実行中のポッド、失敗したポッド、エラー、CPU とメモリの使用率、ファイル システムの使用状況、終了および待機中のポッド、それにコンテナに関する情報が表示されます。この例では、どこでアプリケーションに問題が発生したかを特定するため、CPU およびメモリの使用率を示すダッシュボード パネルに着目します。

Explore_TS_Namespace_Overview.png

ステップ 3: ポッドへのドリルダウン

問題のあるポッドを特定したら、そのポッドにドリルダウンして、詳細なデータを確認します。たとえば、パネルの詳細アイコンを選択し、検索でそのデータを表示したり、[Log Stream (ログ ストリーム)] パネルで実際のログを確認したりできます。

Explore_TS_Pod_drill-down.png

Explore_TS_Drill-down_Pod_search-results.png

トラブルシューティングの説明 - ポッド レベル認証

このトラブルシューティング シナリオでは、Kubernetes 環境をナビゲートしながら、クラスタの問題を発見します。問題の原因を特定するため、ドリルダウンしてログ ストリームを調査したところ、認証に問題があり、アクセス キーが無効で削除されていることがわかりました。ログのシーケンスをさらに分析すると、問題の根本原因を特定し、予防策を講じて、問題の進行を防ぐことができます。

クラスタの問題をトラブルシューティングするため、次の手順を実行しました。

  1. ナビゲーション パネルの上部にある [Explore By (調査手段)] をクリックし、[Kubernetes Service View (Kubernetes サービス ビュー)] を選択します。次に、調査するクラスタを選択し、右上のメニュー バーで [Kubernetes - Cluster Overview (Kubernetes - クラスタの概要)] ダッシュボードを選択します。

TSS_Cluster_Overview_dialog.png

右側のダッシュボード ビューにクラスタのステータスを示すパネルが表示されます。

  1. このシナリオでは、[Pods Running (実行中のポッド)] パネルで [prod-loggen] 名前空間を選択し、機能していないポッドが 2 つあることがわかりました (赤で示されています)。

TSS_Cluster_Pods-Running_panel.png

  1.  失敗したポッドの 1 つにカーソルを置き、失敗したサービスの詳細を表示しました。

TSS_Failed_Pod_details.png

このシナリオでは、PagerDuty ポッドに着目し、ハイフンの後の最後の 5 文字も含めてポッド名を書き留めました (この例では、pagerduty-84d685f79f-4wjln を見ています)。ポッドはエフェメラルで、pagerduty- の後の文字は常に変化します。詳細な調査を行うには、これらの文字を書き留めておくことが重要です。 

  1. さらなる調査のため、左上にある [Explore By (調査手段)] メニューに戻って [Kubernetes Namespace View (Kubernetes 名前空間ビュー)] を選択し、[prod01.travellogic.info] の左にある矢印をクリックして、その内容を表示しました。次に、[prod-loggen] > [pagerduty-*-*] (接尾辞は、前のステップで書き留めたポッド名に一致) を選択して、ポッドとコンテナを表示しました。

TSS_Pod_select-pagerduty.png

この選択に対するデータは、右側のダッシュボード パネルに表示されます。

TSS_Pod_Pagerduty_dashboard.png

  1. ページ下部の [Log Stream (ログ ストリーム)] が出現するまでスクロールして、PagerDuty で生成されたログを表示します。次に、右上にある詳細アイコン (3 つのドット) をクリックして、[Open in Search (検索で開く)] を選択します。

TSS_Pod_Log_Stream_Logs.png

  1. デフォルトでは [Aggregates (集計)] ビューが表示されますが、ログ メッセージを分析するため、[Messages (メッセージ)] タブをクリックしました。

TSS_Logs_Messages_tab.png

  1. 探しているデータをさらに分離するため、左側のナビゲーション パネルで [Message (メッセージ)] のチェックを外しました。メッセージ フィールドを除外するために、ログ メッセージを parse しました。これにより、より理解しやすいログ メッセージを表示し、parse されたログ メタデータに着目できるようになりました。 

TSS_Logs_Message_field.png

  1. 認証の問題を特定するため、2 つのメッセージに着目します。最初のメッセージには java.io.IOException が示されており、認証に関する HTTP ステータス コード 401 が含まれています。2 番目のメッセージには、認証に使用される access_id が示されています。これをさらに分離するため、access_id suRhn0DW7l4DZ を強調表示し、右クリックして [Copy Selected Text (選択したテキストをコピー)] を選択しました。

TSS_Logs_2_messages.png

  1. キーワード suRhn0DW7l4DZU を検索するため、[+ New (+ 新規)] をクリックし、ドロップダウン メニューから [Log Search (ログ検索)] を選択して、間隔を [Last 60 Minutes (過去 60 分)] に変更しました。次に、access_id キーワード suRhn0DW7l4DZU をクエリ ウィンドウに貼り付けて、[Start (開始)] をクリックしました。2 つの Source カテゴリから取得したログを表示するため、左側の [Hidden fields (非表示のフィールド)] に移動して、[Source Category (Source カテゴリ)] をクリックしました。

TSS_New_Log_Search_drilldown.png

  1. [Labs/Sumo_Logic (ラボ/Sumo_Logic)] に 2 件のメッセージしかないことに注目しました。この点に注意を引かれたのは、根本原因項目の発生頻度がより低くなっているためです。さらに調査を行うため、[Labs/Sumo_Logic (ラボ/Sumo_Logic)] Source Category を強調表示して選択しました。

TSS_Source_Category_Labs-Sumo_Logic.png

アクセス キー suRhn0DW7l4DZU が無効で削除されていることを発見しましたが、見ていたのは、access_id を含むログのみでした。これは、限定的すぎて、根本問題の原因を判断する決め手にはなりませんでした。発生した事象についての理解を深めるため、アクセス キーが削除および無効化されたのと同じころに発生した他のメッセージを確認したいと考えました。

  1.  [Category Labs/Sumo_Logic (カテゴリ ラボ/Sumo_Logic)] をクリックした後、ドロップダウン メニューから [Surrounding Messages (周囲のメッセージ)][+/- 1 Minute (+/- 1 分)] を選択し、前後に発生した他のログ メッセージを表示しました。

TSS_Surrounding_Log_messages.png

発生した事象がわかったメッセージは 5 件ありました。イベントの順序を知るため、下から上に向かってそれぞれの行を読み、認証の問題の根本原因にたどり着きました。

  • 5 行目: kenneth がログアウトしました。
  • 4 行目: ユーザ shady+soc がログインしました。
  • 3 行目: ユーザ shady+soc がユーザ kenneth を削除しました。
  • 2 行目: ユーザ kenneth の削除によりアクセス キーが無効になりました。
  • 1 行目: ユーザ kenneth の削除によりアクセス キーも削除されました。

TSS_Log_resolution_sequence.png

結論:

管理者の shady+soc がユーザ Kenneth を削除し、さらには Kenneth のアクセス キーも無効にして削除していたことがわかりました。ポッド ビューで見たように、Kenneth のアクセス キーは PagerDuty に対する認証のために使用されましたが、アクセス キーが削除された後、サービスは認証を行えなくなり、認証は失敗しました。 

詳細な調査の結果、Kenneth は退社しており、shady+soc によってオフボードされていたことがわかりました。Kenneth のユーザ アカウントを削除する前に、Kenneth のアカウントにアクティブな鍵が関連付けられているかや、Kenneth のユーザ アカウントに関連付けられているアクティブな鍵の調査が済んでいるかを shady+soc がマネージャに確認していれば、認証の問題は避けられていたでしょう。

  • この記事は役に立ちましたか?