オブザーバビリティのトラブルシューティングと進化した監視方法

前編ではログ監視を取り巻く状況と、新しい監視アプローチとしてオブザーバビリティをご紹介しました。後編では、オブザーバビリティを使用した場合のトラブルシューティング方法、オブザーバビリティを実践する場合の主なチャレンジ、そしてオブザーバビリティ以外の進化した監視方法を見ていきます。

オブザーバビリティによるトラブルシューティング

それでは、問題発生時にはどのようにアクションを起こすべきでしょうか。それは前編の「オブザーバビリティの3つの柱」で触れたメトリクス、トレース、ログを使用します。

メトリクス：特定の時間間隔で測定された統計値です（例: アクセス数、エラー率、CPU使用率、売上）。

SLO/SLIを始めとして、インフラやアプリケーション、フロントエンド（ユーザーエクスペリエンス）の各重要な値をリアルタイムで可視化することで「問題は起こっているか」を可視化します。

^{メトリクスの例：SLOやユーザーエクスペリエンスに問題はないか}

トレース：依存関係がある一連のリクエストフローをエンドツーエンドでエンコードしたものです。

「問題はどこで起こっているか」を可視化します。

^{トレースの例：あるユーザのセッションで、どのサービスで問題が発生しているか}

ログ：発生した個別のイベントをタイムスタンプ付きで記録したものです（例: アクセスログ、例外トレースのログ）。

「問題はなぜ起こっているか」を可視化します。

^{ログの例：対象セッションの問題のあるサービスでどのようなエラーが発生しているか}

これらのデータを使用することにより、メトリクスにより問題を検出し、トレースによりどこで問題が発生しているかを特定し、ログにより原因を特定し、アクションを行います。

最も重要なことは、これらのデータを一つのプラットフォームで管理することです。特に、トレースとログの紐づけが重要です。上の例では、トレースで問題が発生しているサービスを特定し、そのサービスで発生したログをドリルダウンできるようにしています。

それはどのように実現しているのでしょうか？

鍵は、ログにメタデータとしてTrace ID、Span IDというものを埋め込んでいます。これはリクエストIDやトランザクションIDのようなものです。分散システムにおいて複数のサービスをまたがった処理が行われる場合に与えられるIDです。これによりログにコンテキストが生まれトラブルシューティングが容易になります。

ちなみにTrace ID、Span IDはデータ収集エージェント（OpenTelemetry）で分散トレーシングという技術を用い自動的に付与されます。

^{ログに与えられたTrace ID、Span IDでコンテキストを得る}

なお、オブザーバビリティによりログ監視が無くなるわけではありません。明確にアクションが必要な事象（例えばクリティカルなジョブの失敗）が発生したときにはSLOは関係なく対応する必要があります。

チャレンジ

このようなオブザーバビリティはグローバルでは主流になっています。

しかしチャレンジがあるのは確かです。

• SLO/SLIの定義

定義は運用チームだけでできるものではありません。開発チームはもちろん、サービスオーナーなどステークホルダーの合意が必要です。ステークホルダーへの丁寧な説明と議論を要します。例えばSLOという性質から、ある程度のエラーは見落とすことを前提とします。これを嫌うステークホルダーは「100%」というSLOを要求するかもしれません。ですが、100%を満たすITシステムというものは、大変な高コストであり、また変更が一切できないITシステムです。どこまでエラーを許容するかの合意が必要です。

しかし、サービスレベルを定め、それを基準に運用、開発を行うということは誰しもが同じ基準を持てるという点で大変重要です。

また、前編でもご紹介した『SLO/SLIとは』のページにSLO/SLIの導入方法が紹介されていますので是非ご参考になさってください。

• トラブルシューティング

これまでは定められた手順に従い対応していましたが、トラブルシューティングのスキルが必要になります。一次切り分け、エスカレーションを行ってきた人材は減少し、代わりに運用、開発の知見をもって対応にあたる人材（SREと呼ばれます）が必要です。そのような人材の確保、育成であったり組織変更を要します。

これは現在もエスカレーションを受けた開発チームが対応していたりと、実は大きな変わりはなく、オブザーバビリティによるトラブルシューティングの効率化でメリットが大きいかもしれません。

一足飛びにオブザーバビリティの実践を図るのは困難かもしれません。しかし来たるべき変化に備えるため、運用も変化しなければならないことは確かだと考えます。

オブザーバビリティの実践はすぐには困難だがログ監視を効率化したい、というニーズもあります。そういった場合に何ができるかを見ていきます。

アラート集約

運用や組織を大きく変えずに効率化する手法として考えられるのはアラート集約があります。

例えばSplunk IT Service Intelligence (ITSI)では同一のアラートメッセージはもちろん、同一ホスト、同一サービス、または類似するアラートなど、様々な方法で集約することができます。また、Splunkのデータ分析プラットフォームをベースにしているため、ログのフォーマットはどのようなものでも構いません。

^{認証サービスのエラーとリソースに関するアラートを集約している}

これにより、類似アラートを集約し対応数を減らすということはもちろん、コンテキストも得られます。例えばログ監視の他、リソース監視やその他のアラートも集約することにより、問題発生の前に何か先行事象が発生していないかを確認することでトラブルシューティングをスムーズに行うことができます。先ほどのアラートストームの例では特に有効です。

（それ以外にもITSIにはトラブルシューティングのための様々な機能があります！）

これによりMTTRを削減し、人的リソースの有効活用を目指します。

インシデントレスポンス自動化

ログ監視において対応するアクションが明確になっている場合、それを人が対応するのではなく自動化できるものは自動化する仕組みを採用すべきです。自動化には以下のようなものがあります。

• 適切な担当者の自動アサイン
• 担当者への自動コール（電話、モバイルアプリによる通知など）
• 対応手順の参照
• 関係者間でのコミュニケーションのためチャットツール、ITSMツールとの連携
• 構成管理ツール（Ansible、Puppetなど）との連携による処理の自動化

^{インシデントレスポンス例：対象ITシステムの担当者へ自動コールし、同時にServiceNow、Slackにも通知している}

このようなインシデントレスポンスの自動化により余裕ができたリソースを更に自動化に投資していくことで、人に依存した運用から脱却し、運用高度化を促進します。

どこから手を付けるべきか

改めて申し上げたいのは、ログ監視はこれまでも、これからも重要であり続けます。

しかしながら、来たるべき変化に備えて新たな監視アプローチの有効性をご認識いただければと思い、この記事を書きました。

今後の第一歩としてお勧めするのはオブザーバビリティの試験適用です。例えば新たに開発するクラウドネイティブのITシステムでパイロットプロジェクトとして試すケースが多いです。もちろん既存ITシステムでもログ監視に限界を感じているものがあれば、どのように可視化できるかを試すのもよいと思われます。オブザーバビリティを適用したからと言って既存の運用に影響があるものではありません。

もしSplunkのオブザーバビリティソリューションにご関心がある場合は是非お問い合わせいただくか、Splunk Observabilityの製品ページをご覧ください。

ITシステムに関する状況が変わりつつある現在におけるログ監視の課題と、それにどう対応していくべきかを解説している前編も合わせてご覧ください。

長文となってしまいましたが、お付き合いいただきましてありがとうございました。