オブザーバビリティーの3本柱：ログ、メトリクス、トレース

多くの統治組織や組織は、成功を確実にするために3つの柱に依存しています。企業責任の実践は、環境、社会、財務のサステナビリティーに焦点を当ててビジネス慣行を導きます。

デジタル・トランスフォーメーションを目指す企業は、多くの場合、人材、プロセス、テクノロジーという3つの柱を活用して移行を進めます。このフレームワークは、意思決定者が創造的で協力的な技術専門家（人）を維持することに焦点を当てることを奨励します。構造化された細心のデータ管理およびセキュリティーの実践（プロセス）を使用します。そして、進歩を促進するために高度なツールとプラットフォームに頼ります。

そして、アジャイルなプロジェクト管理を可能にする一連のフレームワークと原則であるスクラムを支える3本柱は、透明性、検査、適応性です。これらのいずれの場合も、3本の柱は明確で不可欠ですが、完全はありません。それぞれに独自の自由度と優先順位がありますが、その真の力は、より大きな目標をサポートするためにどのように連携し、やり取りするかにかかっています。オブザーバビリティーも同様です。

ITのコンテキストでは、オブザーバビリティーは遠隔測定データの3本柱（メトリクス、ログ、トレース）を使用して、膨大なコンピューティング・ネットワークをより簡単に可視化し、把握できるようにします。その結果、開発者は外部アウトプットに基づいてシステム内部の状態を把握できます。ネットワークが観測可能な場合、IT担当者は、追加のテストやコーディングを行わずに、生成されるデータを確認することで、パフォーマンス問題の根本原因を特定できます。

オブザーバビリティー・ソリューションは、システムの生のアウトプットデータを使用してデータ分析を実行し、効果的なトラブルシューティングとデバッグに必要なエンドツーエンドのネットワーク可視性と実行可能な知見をチームに提供します。

オブザーバビリティー・アーキテクチャーは、エンジニアリング・チームやネットワーク管理者が最新のコンピューティング・ネットワークの複雑さを管理できるように支援します。そして今日、それはハイブリッドクラウドやマルチクラウドの構成、各種クラウドネイティブ・アプリケーション、マイクロサービス、Kubernetesコンテナーを含む大規模で高度に動的なコンピューティング・ネットワークを維持することを意味します。

オープンソース・ソリューションのOpenTelemetry などのオブザーバビリティー・ツールは、システムの健全性に関する包括的かつコンテキスト化されたビューを企業に提供します。フルスタックの可視性により、エンドユーザーに影響が及ぶ前に、異常なデータ・パターンや性能のボトルネックを特定することができます。そのため、オブザーバビリティーは、企業がネットワークのダウンタイムを最小限に抑え、さまざまなユースケースにわたってサービスの信頼性を維持するのに役立ちます。

しかし、ネットワークの複雑さに関係なく、オブザーバビリティーはシステムの「イベント」とその主要な3本の柱に依存します。この柱により、オブザーバビリティー・プラットフォームは、分散システム上で動作するフロントエンド・アプリケーション、バックエンド・サービス、CI/CDパイプライン、ストリーミング・データ・パイプラインからデータを収集し、分析することができます。

オブザーバビリティーがシステム・イベントの「内容」「場所」「理由」を判断し、イベントがアーキテクチャー全体の性能にどのような影響を与えるかを明らかにするためには、ネットワークのあらゆるコンポーネントからの綿密なデータ収集が必要です。したがって、イベントはモニタリングと遠隔計測の基礎となります。

イベントは、特定の時間にネットワーク上で発生する個別の出来事であり、通常はログ、メトリクス、トレースにとって貴重なデータを生成するため、3本の柱と同様にオブザーバビリティーにとって不可欠な要素となります。イベントは、より広範なコンテキスト内に存在します。

例えば、クライアントがエンタープライズ・サーバーからリソースを要求する場合、クライアントはエンドポイントのURLを使用して適切なAP エンドポイントに要求を送信します。サーバーは要求を受信し、認証情報（APIキーなど）とクライアントの権限を確認し、それらが有効であると想定して、 APIの仕様に従って要求を処理します（例えば、応答が正しくフォーマットされていることを確認します）。次に、サーバーは要求されたデータを含む応答をクライアントに送信します。

イベントは、特定の瞬間にしかるべきアクションをトリガーします。そのため、DevOpsチームがIT環境を可視化し、ネットワークを最適化できるように、オブザーバビリティー・ツールはこれらのアクションを基に追跡、分析、相関プロセスを開始します。

メトリクスは、さまざまなネットワーク・パラメーターを測定することで、システムの性能に関する定量的な知見を提供します。これらは、チームがシステム問題の「内容」を理解するのに役立ちます。メトリクスのタイプには、次のものがあります。

• ホストのメトリクス：メモリー、ディスク、CPUの使用率
• ネットワーク・パフォーマンス・メトリクス：アップタイム、レイテンシー、スループット
• アプリのメトリクス：応答時間、要求、エラー率
• サーバー・プールのメトリクス：インスタンス総数、実行中のインスタンス数
• 外部依存関係のメトリクス：可用性、サービスの状態

メモリー使用量やレイテンシーなどの一般的なメトリクスは、システムの健全性と直感的に一致します。ただし、その他の多くのメトリクスや主要業績評価指標（KPI）によってシステムの問題が明らかになる場合があります。例えば、オペレーティング・システム（OS）ハンドルが脆弱になるとシステムの速度が低下し、機能を復元するために再起動が必要になることがよくあります。

メトリクスは多くの場合、ダッシュボードやその他の可視化（時系列グラフなど）を使用したサマリー・ビューを提供するために集約され、開発者がシステム全体の健全性を迅速に評価し、データの傾向を分析し、ネットワーク問題に対応するのに役立ちます。また、スケーリングやリソースの割り当てに関する意思決定にも有用であるため、効果的なキャパシティー・プランニングや負荷管理には欠かせないメトリクスとなっています。

一部のメトリクスは、潜在的な問題を発生前に予測するのに有益であるため、チームが追跡するメトリクスを慎重に選択し、継続的に分析することが重要です。

チームは、侵害が発生した場合にアラートをトリガーして、現在の問題または差し迫った問題をITスタッフに通知するメトリックのしきい値を設定できます。また、メトリックにより、オブザーバビリティー・ツールは、OSハンドルのリークなど、時間の経過とともに蓄積され、顧客体験を損なうずっと前から始まる問題を検出できます。

ただし、メトリクスのコンテキストは限られていることが多いため、開発者がシステムイベントを包括的に理解できるようにするには、通常、ログやトレースとの相関関係が必要です。また、高解像度のメトリクスでは大量のデータが生成されるため、効率的な保管と管理が難しい場合があります。そのため、オブザーバビリティーを実現するには、メトリクス・データを処理して分析に利用できるようにする、高品質で長期にわたるストレージ・ソリューションが必要になることがよくあります。

ログは、システム内で発生する個別のイベントの変更できない包括的な記録です。これらは、チームがシステム問題の「理由」を理解する助けになります。

ログ・ファイルには、システムの動作とアプリケーシヨン・プロセスに関する詳細情報が保管されます。

• イベントのタイムスタンプ
• トランザクションID
• IPアドレスとユーザーID
• イベントとプロセスの詳細
• エラー・メッセージ
• 接続の試み
• 構成変更

イベント・ログは、バイナリー、非構造化（プレーン・テキストなど）、構造化（JSON形式など）にすることができます。ログ・ファイルはいずれも適切なコンテキスト内では役立ちますが、構造化されたロギングのアプローチでは、テキストとメタデータが生成時に構造化されるため、解析と分析が簡単になります。

オブザーバビリティー・ツール内のロギング機能は、オペレーティング・システム、ネットワーク・デバイス、内部およびサードパーティ製アプリケーション、IoT（モノのインターネット）デバイスからのログ・ファイルを集約し、開発チームがエラーを診断し、システム障害を理解する助けになります。エラー、セキュリティー侵害、コンプライアンス上の問題が発生した場合、ログには根本原因を追跡し、何が問題だったのかを理解するために必要な詳細情報が記載されています。

ログは、システム・イベントや問題に関する貴重な知見を提供しますが、それだけでは全体像を把握できません。メトリクスと同様に、オブザーバビリティー・ツールは、ログデータを分析してメトリクスやトレースと関連付け、その価値を最大化する必要があります。また、メトリクスと同様に、ログはデータ量を大幅に増加させるため、企業はデータ負荷を処理するために高度なログ管理ツールに投資しなければならないことがよくあります。

さらに、包括的なイベント・ロギングにより、重要な情報が関連性の低いデータに埋もれ、IT担当者による問題の特定を複雑にする「ノイズ」が生じることがあります。そのため、最新のオブザーバビリティー・ソリューションでは、アラートの実施を改善し、重要なアラートとノイズを区別するために、 AIと機械学習（ML）主導の自動化ワークフローを活用しています。

メトリクスとログの主要な機能の一部を組み合わせたトレースは、コンポーネント全体でデータをマッピングして、要求のワークフローを示します。これらは、ネットワークを介した要求のエンドツーエンドの移動を表し、要求の処理に関連する各コンポーネントのパスとライフサイクルを取得します。つまり、トレースにより、サイト信頼性エンジニア（SRE）とソフトウェア・エンジニアリング・チームがシステム・イベントと問題の発生場所と発生方法を理解できます。

トレース・データには、次のものが含まれます。

• ネットワーク・イベントとオペレーションの期間
• アーキテクチャーを介したデータ・パケットのフロー
• 要求がネットワーク・サービスを通過する順序
• システム・エラーの根本原因

トレース、特に分散トレースは、要求が受信先に到達する前に地理的に分散した複数のサービスを経由する可能性があるマイクロサービス・アーキテクチャーで有益です。トレースは、さまざまなコンポーネントやサービス間の依存関係と相互作用についての知見を提供し、ITチームがユーザーが特定のアクションを完了するのにどれくらいの時間がかかるかを理解する助けになります。

オブザーバビリティー・ツールのトレース機能は、遅延分析に不可欠です。この分析は、エンジニアがユーザーにとって性能のボトルネックを引き起こしかねない問題のあるコンポーネントやパフォーマンスの低いサービスを特定するのに役立ちます。

これらは、要求と応答のフローとネットワーク要素間の因果関係を示すことにより、デバッグ・プロセスを促進します。また、根本原因分析中にトレースを利用すると、複雑なワークフロー内のネットワーク問題の原因をチームが正確に特定し、より迅速かつ正確に問題を解決できます。

メトリクスやログとは異なり、トレースはコンテキスト情報を提供して洞察を豊かにするのに役立ちます。しかし、トレースだけではデータの傾向やパターンを明らかにすることはできません。分散トレースを設定するには、サービス・デプロイメント全体にわたる計測も必要であるため、プロセスが特に複雑で時間がかかる可能性があります。そして、それが適切に管理されていない場合、トレースとそれが必要とするコンピューティング能力によって、環境にさらなるレイテンシーが生じる可能性があります。

3本の柱を組み合わせることで、開発チームと運用チームは複雑なシステムの動作を全体的に把握し、きめ細かく理解できるようになります。メトリクスはチームに問題を知らせるために使われますが、トレースは実行経路を示し、ログは問題解決に必要なコンテキストを示します。

これらを組み合わせることで、問題の特定と解決を加速し、問題に対処するための補完的なツールをチームに提供し、ネットワーク・パフォーマンスの最適化を実現し、フルスタックのオブザーバビリティーを可能にします。

メトリクス、ログ、トレースはオブザーバビリティーの主な柱として広く知られていますが、他の基本的なコンポーネントの存在が排除されるわけではありません。コンテキスト、相関関係、アラートもオブザーバビリティーの柱だと主張する声もありますが、

結局のところ、コンテキスト（背景情報）は、ネットワーク環境（トポロジー、デバイス・ロール、アプリケーションの依存関係など）に関する追加情報を提供することで、メトリクス、ログ、トレースを充実させます。コンテキストがなければ、オブザーバビリティー・データは実用的な意味を欠きます。

相関関係は、メトリクス、ログ、トレース、コンテキスト情報を結び付けて、ネットワーク・スタックのさまざまな層のイベントについて一貫したビューを提供します。また、アラートがなければ、問題が発生したときにオブザーバビリティー・ツールはプロンプト通知を送信できません。

しかし、プロファイリングはオブザーバビリティーのもう一つの主要な機能として浮上しています。

プロファイリング（継続的プロファイリングとも呼ばれる）は、アプリケーションを実行し、特定の瞬間におけるコードの実行状態に関する詳細なデータを継続的に収集するプロセスのことです。例えば、プロファイルにより、Javaスレッドが実行状態か待機状態かを確認できます。または、アプリにメモリー・リークの問題がある場合、プロファイルはコードのどの部分がリソースを過剰に消費しているかを明確にすることができます。

したがって、プロファイルは、単一のシステム・コンポーネントの内部動作に対するX線として機能します。

プロファイリングは、個々の機能やコード・ブロックに影響を与える問題など、下位の問題を特定するのに活用できるため、ITチームは使用中のコードパスを特定し、未使用のパスを特定して廃止し、将来のイベントややり取りに向けて重要なパスに優先順位を付けることができます。

プロファイルは3本柱の1本ではありませんが、プロファイリング機能は大幅に進化しました。Linux カーネルのExtended Berkeley Packet Filter（eBPF） などのプロジェクトにより、プロファイラーの開発が合理化され、開発チームのプロファイリング・プロセスが簡素化されました。

開発チームは、トレース、サンプリング、インストルメンテーション・プロファイルを使用して、アプリケーション・コードをより深く、詳細に把握できます。また、オブザーバビリティーの他の柱と併用すると、プロファイリングはアプリケーションのパフォーマンスに関するリアルタイムの知見を提供し、ソフトウェア開発ライフサイクルを加速し、企業がDevOps戦略を最適化するのに役立ちます。