Log Observer Connect を使用してビジネス トランザクション エラーをトラブルシューティングする

Log Observer を使用して Log Observer Connect を介して Splunk プラットフォームログにアクセスする際のビジネストランザクション問題のトラブルシューティング例。

架空の企業 Buttercup Games は、自社製品を販売するための EC サイトを運営しています。同社は Splunk Cloud Platform でログを分析しています。同社は最近、マイクロサービスアーキテクチャと Kubernetes をインフラに採用したクラウドネイティブなアプローチを使用するように、サイトを再設計しました。オブザーバビリティ ソリューションとして Splunk Observability Cloud を購入しています。Buttercup Games は、ポイントアンドクリック方式の Splunk Observability Cloud ツールである Log Observer で Splunk Cloud Platform のログを分析しています。 設定は Log Observer Connect を介して行なわれています。

Buttercup Games のサイト信頼性エンジニアとサービスオーナーは、サイトを訪れた人々が素晴らしい体験を得られるよう、共同でサイトの監視と保守を行っています。同社は Splunk Observability Cloud を使用して、オンラインストアでの購入時に障害や失敗を引き起こす問題を発見し、解決しています。

過去 1 時間で、Buttercup Games サイトでの購入数が大幅に減少し、チェックアウトの完了率が非常に低くなりました。SRE の Aisha とサービスオーナーの Deepu は、Splunk Observability Cloud の Splunk Log Observer とその他のビューを使って以下のタスクを実行し、購入ビジネストランザクションに関する問題の根本原因を特定してトラブルシューティングを行いました。

  1. どのログが重要かを判断する

  2. ログの初期分析を実施する

  3. ログパターンを検索する

  4. 仮説を絞り込む

  5. 仮説を検証する

  6. 根本原因を特定し、改善する

どのログが重要かを判断する

Aisha は、Splunk Application Performance Monitoring（APM）でサービスマップを開きます。チェックアウトの完了率が非常に低い理由を確認するために、サービスマップで [/cart/checkout] ビジネストランザクションを選択します。サービスマップに、[/cart/checkout] ビジネストランザクションの背後で稼働する全サービス間の依存関係の相互作用が表示されるようになりました。

このスクリーンショットは、Splunk APMのサービスマップを示すもので、ルートエラーの発生源としてpaymentserviceが表示されています。

Aisha は、[paymentservice] で、ビジネストランザクションのエクスペリエンスの低下につながるダウンストリームエラーの数が最も多いことを確認しました。Splunk APM は、問題を根本原因のエラーとして特定しています。Aisha は [paymentservice] を選択します。Splunk Observability Cloud には、サービスのエラーと遅延に関する詳細が表示されます。

アプリケーションの他領域にある関連データへのアクセスを提供する [Related Content] タイルも表示されます。たとえば、[paymentservice] を実行する Kubernetes クラスターの正常性を調べたり、[paymentservice] によって発行されるログを調べたりすることができます。

このスクリーンショットはSplunk APMのサービスマップを示すもので、2つの「関連コンテンツ」タイル（paymentserviceのK8sクラスターとpaymentserviceのログ）へのアクセスが提示されています。

Aisha はログの詳細を調べることにします。[Related Content] タイルの [Logs for paymentservice] を選択します。Log Observer が開き、Aisha のビューが自動的に絞り込まれ、[paymentservice] からのログだけが表示されます。Log Observer は、Splunk Cloud Platform に送信された [paymentservice] のログを表示します。Log Observer はログを取り込みませんが、Splunk Cloud Platform のストレージからログを表示します。

Aisha は最初に Splunk APM でビジネストランザクションの問題を追跡しているため、[paymentservice] からのログのみに検索を絞り込むことができました。これで、Aisha は Log Observer を使用してログを分析できます。

ログの初期分析を実施する

Aisha は、Log Observer のポイントアンドクリック UI で [paymentservice] ログに対してクエリを実行し、ログをフィルタリングして集計し、根本的な問題にドリルダウンすることができます。SPL クエリ言語を使用したより複雑な分析では、Splunk Cloud Platform Search & Reporting アプリケーションで [paymentservice] のログの分析を続行できます。

ログテーブルの受信ログを見て、Aisha はいくつかのエラーログを見つけたので、構造化されたビューで詳細を見るために 1 つを選択します。右側のログの詳細ビューで、Aisha は「Failed payment processing through ButtercupPayments: Invalid API Token (test-20e26e90-356b-432e-a2c6-956fc03f5609)」というエラーメッセージに気付きます。

このスクリーンショットは、エラーの重大度とエラーメッセージを含む、Splunk Log Observer のエラーログの詳細を示しています。

Aisha は、他のログに同じエラーメッセージがあるかどうかを確認することにしました。パターンを見つけることができれば、問題の原因となっているものを特定できます。

ログパターンを検索する

Aisha は、他のログにも同じエラーメッセージがあるかどうかを確認するために、他のログをいくつか開きます。開いたログのいくつかに、同じエラーメッセージ「Failed payment processing through ButtercupPayments: Invalid API Token (test-20e26e90-356b-432e-a2c6-956fc03f5609)」が表示されています。

Aisha は、無効な API トークンはすべて「test」で始まることに気づきました。現在のバージョン v350.10 が実稼働環境では動作しないテストトークンを使ってプッシュされた可能性があります。

この仮説をチェックするために、Aisha はこのエラーメッセージを選択し、[Add to filter] を選択して、同じエラーメッセージが含まれるログのみを表示します。

仮説を絞り込む

次に、Aisha はテスト API トークンを含むログのグループが複数のバージョンにあるかどうかを確認するために、ログをバージョン別にグループ化したいと考えました。[Group by] フィールドを [version] に変更します。

これでAisha は、テストAPIトークンを含むすべてのログがバージョンv350.10であることを確認できます。

このスクリーンショットは、エラーメッセージでフィルタリングされ、バージョン 350.10 でグループ化されたイベントの Log Observer ページを示しています。表示されているログはすべてエラーログです。

Aisha は、最新バージョンである v350.1 のみで、エラーメッセージ「Failed payment processing through ButtercupPayments: Invalid API Token (test-20e26e90-356b-432e-a2c6-956fc03f5609)」を含むログに問題が特定されたと確信しています。次は、その仮定を検証したいと考えました。

仮説を検証する

念のため、Aisha はメッセージフィルタ値の目のアイコンを選択し、一時的にフィルタを除外します。バージョン v350.9 も表示されるログがありますが、エラーメッセージは含まれていません。Aisha は、テストトークンのエラーメッセージを含むすべてのログ（エラーメッセージを含まないログは除く）をバージョン v350.10 に関連付けることができました。

根本原因を特定し、改善する

Log Observer で調査した結果、Aisha は v350.10 のテスト API トークンが支払い完了に失敗する原因として最も可能性が高いと確信しました。Aisha は、問題のあるバージョンの v350.10 から v350.9 に Buttercup Games のコードをロールバックします。

また、テストトークンである無効な API トークンについて Deepu に知らせます。Deepu は、テストトークンを実稼働環境で機能するトークンに置き換えます。

概要

サイト信頼性エンジニアの Aisha は、Buttercup Games の e-コマースサイトでチェックアウトの完了率が低下し、購入数が低下していることに気付いた際、Splunk APM サービス マップで [/cart/checkout] ビジネストランザクションを確認しました。そして、APM がエラーの根本原因として [paymentservice] を特定したことを確認します。Aisha は、[Related Content] バーを介して APM から 関連ログにリンクすることで、ログの詳細を調べることにしました。

Log Observer で、[paymentservice] からのいくつかのログに同じエラーがあることが確認されます。エラーメッセージに共通していたのは、API トークンが「test」で始まっていることでした。Aisha は、テストトークンが問題であると考えました。ログをフィルタリングして集計することで、他の考えられる問題を除外しました。疑わしいテストトークンのエラーメッセージが v350.10 のログにのみ関連していることを確認しました。

[paymentservice] のオーナーである Deepu に問い合わせたところ、テスト API トークンが問題の原因である可能性が高いということで意見が一致しました。v350.9 のログにはテストトークンのエラーメッセージが含まれていなかったため、Aisha はコードを以前のバージョンにロールバックしました。次に、Deepu はテストトークンを実稼働環境で機能するトークンに置き換えました。

修正後、ユーザーはチェックアウトを完了し、Buttercup Games の e-コマースサイトから購入することができるようになりました。今後のこのような問題を防ぐために、Aisha は、トークンに「test」が含まれている場合にチームに警告するディテクタを作成することにしました。アラートとディテクタは、お客様が購入を試みて失敗する前に、Aisha と Deepu のチームに通知します。

さらに詳しく