可観測性を超えた3つの柱についてお話ししましょう

可観測性は、多くの場合、ログ、メトリック、トレースの 3 つの柱のコンテキストで定義されます。最新のクラウドネイティブ アプリケーションは複雑かつ動的です。予期せぬ事態やパフォーマンスの問題を回避するには、強力な可観測性スタックが必要です。しかし、可観測性はログ、メトリック、トレースの収集だけに限定されるのでしょうか?

SigNoz ブログの「Three Pillars of Observability [And Beyond]」からの翻訳です。リー・フィンチ著。

監視ツールは過去 25 年間、あらゆるビジネスにとって重要な要素であり、インフラストラクチャやアプリケーションの問題が顧客に影響を与える前に、その問題に関する高度なアラートを提供してきました。時間の経過とともに、監視対象のシステムに関するより深い洞察を得るために、監視システムのメトリックの数が増えてきました。

しかし、ソフトウェア システムが複雑になるにつれて、監視のために指標のみに依存することには限界が生じます。エンドユーザーに影響を与えるデジタル エクスペリエンスの問題を引き起こす可能性のある未知の変数を特定できないことがよくあります。

最近、業界では「可観測性」という概念が注目され、従来の監視からの転換が進んでいます。事前定義されたメトリックに重点を置く後者とは異なり、可観測性は、先行サービス レベル インジケーターと後続サービス レベル インジケーターを含め、任意の時点でのシステムの状態を理解することを重視します。このアプローチにより、特定のメトリックに制限されることなく、パフォーマンスの問題やエラーをリアルタイムで把握できます。たとえば、SigNoz などの可観測性ツールを使用して Web リクエストをトレースすると、リクエストのプロセス全体と内部操作が表示され、サーバーの応答時間を測定するだけの場合よりも包括的なビューが提供されます。特定のリクエストのコンテキストで実行されている作業の詳細 (メソッド、クラス、データベース クエリ) が含まれます。

可観測性の 3 つの柱は通常、メトリック、トレース、およびログです。

索引

メトリックを調べる場合、メトリックは通常、特定の時点における特定のメトリックの状態を表します。これは、CPU 使用率の時系列グラフに見られるような、時間の経過に伴う変化を理解するために重要です。

K8s Pod CPU 使用率を表示する SigNoz ダッシュボード

時系列グラフは、MRTG (Multi-Router Traffic Grapher) と呼ばれる最も古い監視ツールの 1 つから生まれました。 MRTG は通常、 SNMP (Simple Network Monitoring Protocol) を使用して5 分ごとにデータを収集し、ルーター インターフェイスの使用状況をグラフィカルに表示します。その後、定期的なポーリング間隔でさまざまなメトリックを収集するために、SNMP が Linux (さらには MS Windows) で普及しました。 SNMP は依然として人気がありますが、OTEL コレクター、REST API、ストリーミング テレメトリを使用したエージェント ベースの監視などの新しいアプローチに比べると、もはや好ましい選択肢ではありません。

一般的な 2 種類のメトリックは、使用率と飽和度に関連しています。使用率メト​​リックは、CPU やメモリの使用率、またはアプリケーション サーバー ワーカー スレッドの使用率などのリソース使用率のパーセンテージを示します。同時に、飽和指数はリソースの競合の度合いを反映します。たとえば、ディスク キューの長さは、指定された間隔でディスクが処理するには作業量が多すぎることを示します。ここでは、使用率は 100% と表示されますが、飽和状態はシステムが処理できる以上のワークロードを示します。

追跡

トレースにより、時間の経過とともに発生するイベントに関する洞察が得られます。 APM および OpenTelemetry のコンテキストでは、通常、コードにライブラリを埋め込むか、プロファイラー/エージェントを使用してアプリケーションとランタイムをインストルメント化します。 Spring Boot を OpenTelemetry および SigNoz と統合して可観測性の 3 つの柱を実現する方法の詳細については、Spring Boot モニタリングに関する記事を参照してください。

典型的なトレースの例としては、Web フロントエンドへの HTTP 要求が挙げられます。この要求では、複数のタスクを完了して応答を返す必要があります。飼い主のプロフィールに新しいペットを追加するための HTTP POST リクエストを検討します。このリクエストには 25 個のスパンが含まれており、各スパンにはスパン、SQL ステートメント、スレッド ID、およびサービス詳細に関する詳細なプロパティが含まれています。

サンプル HTTP トレース

この情報の一部はログから推測できますが、トレースではこれらの作業単位がコンテキストに基づいた標準化された形式で表示されます。 Flamegraphs やGanttチャートなどのトレースを使用すると、複雑な分散設定でさまざまなコンポーネントを通過するリクエスト全体を簡単に視覚化できます。このアプローチにより、単一のリクエストを追跡するために複数のサーバー、コンテナ、ログ ファイルを検索する必要がなくなり、膨大な作業時間を節約できます。

ログ

3 つの可観測性の柱の中で最も古いロギングは、基本的な「print」ステートメントから複雑な構造化形式へと進化してきました。当初は、固有の柔軟性と非構造化の性質により分析が困難でしたが、最新のログ ライブラリ、フレームワーク、標準により、使いやすさが大幅に向上しました。 SigNoz などのツールは、クエリや集計のニーズに合わせてログを変換するためのログ パイプラインを提供します。

トレースID別に集計されたログの例

コンテキストによるログ記録の強化

Logback や Log4J などのフレームワークによりログの変更が簡素化され、OpenTelemetry や SigNoz がログを簡単に使用できるようになり、個別のログ パイプラインが不要になりました。たとえば、Logback の構造化フィールド、プロパティ、値を SigNoz でクエリして、無関係なデータをフィルタリングしたり、特定のトレースまたはスパン ID に関連するログを分離したりできます。

トレースIDとスパンIDを示すログの例

3つの柱を超えて - コンテキスト

可観測性は、ログ、メトリック、トレースの 3 つの柱を収集して分析するだけから進化しました。 「コンテキスト」は、従来の 3 つの柱であるメトリック、ログ、トレースを補完する、複雑な分散システムのデバッグにおける重要なコンポーネントとしてますます認識されています。

コンテキストは、さまざまなシグナルを相関させ、観測可能性の 3 つの柱にさらに多くの情報を提供する、観測可能性の 4 番目の柱と言えます。

可観測性におけるコンテキストの役割

トラブルシューティングでは、コンテキストが重要です。メトリック、ログ、トレースからのさまざまな情報を接続します。この相互接続性により、問題を迅速に特定し、その影響を理解し、より効果的な解決策を開発できるようになります。

コンテキストを可観測性の 3 つの柱と統合します。

• 相関ログとトレース: トレース識別子とスパン識別子を挿入することで、ログとトレースを相関させることができます。トレースを使用して、問題のあるリクエストのフローを理解し、問題が発生した段階を特定します。次に、特定のスパンまたはサービスのログをドリルダウンして、詳細なエラー情報を取得します。
• コンテキストのあるメトリクス: メトリクスは、単なる定量的データよりもコンテキストと組み合わせると、より意味のあるものになります。たとえば、リソース使用量の急増は、どのデプロイメントまたは変更によって急増が引き起こされたかがわかっていると、より有益な情報になります。

可観測性の今後のトレンドは、学習したパターンに基づいて AI を活用し、迅速なデータ解釈を行って、サイト信頼性エンジニアリング (SRE) と可観測性チームにとって重要な情報を優先し、重要度の低いデータを除外することです。このアプローチにより、最も影響力のある問題に焦点を絞ることが容易になります。さらに、AI を使用すると、関連するデバッグ情報の収集やサービスの再起動など、標準イベントに対する日常的な応答を自動化できます。この自動化により、サービスの復旧における人的介入の必要性が減り、チームは根本原因分析 (RCA) と予防戦略に集中できるようになります。

データの可視化 - 可観測性の重要な要素

可観測性においては、視覚化が重要であり、データをさまざまな対象者が理解できるストーリーに変換します。ダッシュボードは、専門家だけでなく、あらゆるスキル レベルと専門知識を持つユーザーに重要な情報を伝達する必要があります。

組織が直面する最大の課題の 1 つは、すべての情報を 1 つのビューに表示するダッシュボードを作成することです。ダッシュボードを理解するためにそれを読む必要がある場合、それはダッシュボードではなくレポートです。

ダッシュボードを簡単に理解できるようにする

効果的なダッシュボードには、ターゲット ユーザーに対する共感が必要です。たとえば、経営者はサービスが利用可能で、適切に機能しているかどうかだけを知りたい場合があります。その場合、必要なのは 1 つの信号機だけかもしれません。対照的に、サービス所有者は、ユーザー数、平均パフォーマンス、外れ値を識別するための p95 値と p99 値などのより詳細なメトリックからメリットを得ることができます。

「効果的なダッシュボードの鍵は、シンプルで読みやすく、ユーザー中心のデザインです。」

SigNoz のシンプルな CPU とスレッドのダッシュボード

組織における可観測性の成熟度をナビゲートする

成熟度指数は、アプリケーションやサービスの使用方法をベンチマークし、デジタル エクスペリエンスにおけるリスクを軽減するためにどのような手順を踏めばよいかを理解するための効果的な方法です。成熟度を評価するには、サービスに関連する人材、プロセス、テクノロジーを評価する必要があります。

まず人的側面から始め、チームの可観測性スキルと、可観測性の実践を組み込むための組織の取り組みを評価します。

プロセスにより、特定の個人への依存を減らし、ビジネスまたはサービスの回復力を高める必要があります。たとえば、サービス低下計画では、一時的なイベント中に 3 つの柱から情報を収集する手順の概要が示される場合があります。

テクノロジーは単なるツールではありません。これらのツールを活用してサービスを完全に計測することが重要です。この記事では、Spring Boot モニタリングを例に、3 つの柱を使用したインストルメンテーションについて説明します。

これらの各要素について、成熟度指数を使用して現在の状態と望ましい状態を比較し、どのサービスに投資するかに焦点を当てます。

結論は

最新のクラウドネイティブ アプリケーションにおける可観測性の進化の状況を包括的に紹介します。これは従来の監視の範囲を超え、コンテキストを第 4 の柱の一部として組み込むことで、可観測性をより動的かつ接続性の高いものにする方法を強調しています。可観測性の将来は、複雑なデータを理解可能かつ実用的なものにするために、人工知能と効果的なデータ視覚化にますます依存するようになると考えられています。

デジタル エクスペリエンスとシステムの信頼性を強化したい組織にとって、可観測性のこうした進化する側面を受け入れることは非常に重要です。重要なのは、これらのプラクティスを運用文化に組み込み、強力で応答性が高く、回復力のあるテクノロジー エコシステムを確保することです。