ソフトウェアエンジニアリング、特に分散コンピューティングにおいて、可観測性とは、プログラムの実行、モジュールの内部状態、コンポーネント間の通信に関するデータを収集する能力を指します。[ 1 ] [ 2 ]可観測性を向上させるために、ソフトウェアエンジニアは幅広いロギングおよびトレース技術を用いてテレメトリ情報を収集し、それを分析・活用するためのツールを活用します。可観測性は、サービス停止のトリアージにおける最初のステップであるため、サイト信頼性エンジニアリングの基礎となります。可観測性の目標の一つは、問題のデバッグに必要な事前知識を最小限に抑えることです。
この用語は制御理論から借用されたもので、システムの「可観測性」とは、その出力からシステムの状態をどの程度正確に判断できるかを測定するものです。同様に、ソフトウェアの可観測性は、取得したテレメトリ（メトリクス、ログ、トレース、プロファイリング）からシステムの状態をどの程度正確に把握できるかを測定します。
可観測性の定義はベンダーによって異なります。
可観測性とは、システムの内部状態をより透明化するプロセスです。システムは、生成されるデータによって観測可能になり、インフラストラクチャやアプリケーションが健全で正常に動作しているかどうかを判断するのに役立ちます。
新しいコードを出荷することなく、システムがどんなに斬新で奇妙な状態であっても、それをどれだけ理解し説明できるかを測る尺度
分散アプリケーションとその上で実行されるハードウェアおよびネットワークから得られるパフォーマンス データの安定したストリームを集約、相関、分析するためのソフトウェア ツールとプラクティス
観測可能性は、分析を始める前にすべての生データを中央サービスに送信することから始まります。
ログ、メトリック、トレースなどのシステムが生成するデータに基づいてシステムの現在の状態を測定する機能
可観測性とは、チームがシステムを積極的にデバッグできるようにするツールまたは技術ソリューションです。可観測性は、事前に定義されていない特性やパターンを探索することに基づいています。
すべてのメトリック、イベント、ログ、トレースを積極的に収集、視覚化し、インテリジェンスを適用することで、複雑なデジタルシステムの動作を理解できます。
この用語は、しばしば数字の頭文字であるo11y（11は単語の最初の文字と最後の文字の間の文字数を表す）で呼ばれる。これは、 i18n、l10n、k8sといった他のコンピュータサイエンスの略語と類似している。[ 10 ]
観測可能性と監視は互換的に使用されることがあります。[ 11 ]ツール、商用製品、実践が複雑化するにつれて、「監視」は新しいツールを古いツールと区別するために観測可能性として再ブランド化されました。
これらの用語は、システムが事前に定義されたテレメトリセットを使用して監視されるという点と、監視対象のシステムが観測可能であるという点において、一般的に対比されます。[ 8 ]
Majorsらは、監視ツールしか持たないエンジニアリングチームは専門家の先見性（熟練度）に頼ることになるのに対し、観測可能性ツールを持つチームは探索的分析（好奇心）に頼ることになる、と示唆している。[ 4 ]
可観測性は、メトリクス、ログ、トレースの3つの主要なテレメトリデータに依存します。[ 7 ] [ 8 ] [ 13 ]これらはしばしば「可観測性の柱」と呼ばれます。[ 14 ]
メトリックとは、システムの状態を表す、ある時点における測定値（スカラー値）です。一般的なメトリックの例としては、以下のようなものがあります。
監視ツールは通常、特定のメトリック値が設定されたしきい値を超えた場合にアラートを発するように構成されます。しきい値は、通常の動作条件に関する知識と経験に基づいて設定されます。
メトリックは通常、グループ化と検索を容易にするためにタグ付けされます。
アプリケーション開発者は、ソフトウェアをリリースする前に、どのようなメトリクスを計測するかを選択します。その結果、これまで未知の問題が発生した場合、新しいコードをリリースせずに新しいメトリクスを追加することは不可能です。さらに、メトリクスのカーディナリティ（基数）によって、テレメトリデータのストレージサイズが法外なコストになってしまう可能性があります。メトリクスはカーディナリティに制限があるため、集計値（例：平均ページ読み込み時間、5秒間のリクエストレートの平均など）を表すために使用されることがよくあります。外部コンテキストがなければ、イベント（ユーザーリクエストなど）と個別のメトリクス値を相関させることは不可能です。
ログ、またはログ行は、一般的に自由形式の非構造化テキストBLOBであり、人間が判読できるように意図されています。現代のログ記録は、機械による解析を可能にするように構造化されています。[ 4 ]メトリクスと同様に、アプリケーション開発者は事前にアプリケーションをインストルメント化し、異なるログ情報が必要な場合は新しいコードをリリースする必要があります。
ログには通常、タイムスタンプと重大度レベルが含まれます。イベント（ユーザーリクエストなど）は複数のログ行に分割され、同時発生しているイベントのログと混在する場合があります。
クラウドネイティブアプリケーションは通常、単一のリクエストを処理する分散サービスで構成されています。分散トレースとは、単一のユーザーリクエストの進行を追跡する、相互に関連する一連の個別のイベント（スパンとも呼ばれます）です。[ 4 ]トレースは、リクエストを処理するために相互運用するサービス間の因果関係と時間的関係を示します。
アプリケーションをトレースで計測するということは、スパン情報をトレースバックエンドに送信することを意味します。トレースバックエンドは受信したスパンを相関させ、表示可能なトレースを生成します。リクエストが複数のサービスを通過する際に追跡できるようにするため、スパンには一意の識別子が付与され、スパン間の親子関係を構築できます。スパン情報は通常、送信リクエストのHTTPヘッダーで共有されます。[ 4 ] [ 15 ] [ 16 ]
継続的なプロファイリングは、アプリケーションがリソースをどのように消費しているかを正確に判断するために使用される別のテレメトリタイプです。[ 17 ]
アプリケーションを観察するには、アプリケーションの動作に関するテレメトリを収集またはエクスポートする必要があります。インストルメンテーションとは、アプリケーションの通常の動作と並行してテレメトリを生成することを意味します。[ 4 ]テレメトリは独立したバックエンドによって収集され、後で分析されます。
急速に変化するシステムでは、計測機器自体が、意図（エンジニアが名前を付けて収集することを決定したディメンションは何ですか？）と、生産のライブステータスのリアルタイムの最新情報を組み合わせるため、最良のドキュメントとなることがよくあります。[ 4 ]
インストルメンテーションは自動またはカスタムで実行できます。自動インストルメンテーションは包括的なカバレッジと即時的な価値を提供します。一方、カスタムインストルメンテーションはより高い価値をもたらしますが、インストルメント対象のアプリケーションへのより密接な関与が必要になります。
インストルメンテーションはネイティブ（コード内で実行、インストルメントされたアプリケーションのコード変更）またはコード外（サイドカー、eBPFなど）で行うことができます。
新しい機能をカスタムインストルメンテーションとともに出荷することで本番環境で検証することは、「観測性駆動開発」と呼ばれる手法です。[ 4 ]
メトリクス、ログ、トレースは、可観測性の柱として最も一般的に挙げられます。[ 14 ]メジャーズらは、可観測性の柱は高カーディナリティ、高次元性、探索可能性であると示唆し、 「現代のシステムでは、全く同じ方法で2度失敗することはめったにない」ため、ランブックやダッシュボードにはほとんど価値がないと主張しています。[ 4 ]
セルフモニタリングとは、可観測性スタックが相互に監視することで、目立たない障害のリスクを軽減する手法です。高可用性と冗長性に加えてセルフモニタリングを導入することで、相関する障害をさらに回避できます。