可観測性（ソフトウェア）

ソフトウェアエンジニアリング、特に分散コンピューティングにおいて、可観測性とは、プログラムの実行、モジュールの内部状態、コンポーネント間の通信に関するデータを収集する能力を指します。[ 1 ] [ 2 ]可観測性を向上させるために、ソフトウェアエンジニアは幅広いロギングおよびトレース技術を用いてテレメトリ情報を収集し、それを分析・活用するためのツールを活用します。可観測性は、サービス停止のトリアージにおける最初のステップであるため、サイト信頼性エンジニアリングの基礎となります。可観測性の目標の一つは、問題のデバッグに必要な事前知識を最小限に抑えることです。

語源、用語、定義

この用語は制御理論から借用されたもので、システムの「可観測性」とは、その出力からシステムの状態をどの程度正確に判断できるかを測定するものです。同様に、ソフトウェアの可観測性は、取得したテレメトリ（メトリクス、ログ、トレース、プロファイリング）からシステムの状態をどの程度正確に把握できるかを測定します。

可観測性の定義はベンダーによって異なります。

可観測性とは、システムの内部状態をより透明化するプロセスです。システムは、生成されるデータによって観測可能になり、インフラストラクチャやアプリケーションが健全で正常に動作しているかどうかを判断するのに役立ちます。

— グラファナラボ[ 3 ]

新しいコードを出荷することなく、システムがどんなに斬新で奇妙な状態であっても、それをどれだけ理解し説明できるかを測る尺度

— ハニカム[ 4 ]

分散アプリケーションとその上で実行されるハードウェアおよびネットワークから得られるパフォーマンス データの安定したストリームを集約、相関、分析するためのソフトウェア ツールとプラクティス

— IBMインスタント[ 5 ]

観測可能性は、分析を始める前にすべての生データを中央サービスに送信することから始まります。

— エッジデルタ[ 6 ]

ログ、メトリック、トレースなどのシステムが生成するデータに基づいてシステムの現在の状態を測定する機能

— ダイナトレース[ 7 ]

可観測性とは、チームがシステムを積極的にデバッグできるようにするツールまたは技術ソリューションです。可観測性は、事前に定義されていない特性やパターンを探索することに基づいています。

— Google Cloud [ 8 ]

すべてのメトリック、イベント、ログ、トレースを積極的に収集、視覚化し、インテリジェンスを適用することで、複雑なデジタルシステムの動作を理解できます。

— ニューレリック[ 9 ]

この用語は、しばしば数字の頭文字であるo11y（11は単語の最初の文字と最後の文字の間の文字数を表す）で呼ばれる。これは、 i18n、l10n、k8sといった他のコンピュータサイエンスの略語と類似している。[ 10 ]

観測可能性と監視

観測可能性と監視は互換的に使用されることがあります。[ 11 ]ツール、商用製品、実践が複雑化するにつれて、「監視」は新しいツールを古いツールと区別するために観測可能性として再ブランド化されました。

これらの用語は、システムが事前に定義されたテレメトリセットを使用して監視されるという点と、監視対象のシステムが観測可能であるという点において、一般的に対比されます。[ 8 ]

Majorsらは、監視ツールしか持たないエンジニアリングチームは専門家の先見性（熟練度）に頼ることになるのに対し、観測可能性ツールを持つチームは探索的分析（好奇心）に頼ることになる、と示唆している。[ 4 ]

テレメトリの種類

可観測性は、メトリクス、ログ、トレースの3つの主要なテレメトリデータに依存します。[ 7 ] [ 8 ] [ 13 ]これらはしばしば「可観測性の柱」と呼ばれます。[ 14 ]

メトリクス

メトリックとは、システムの状態を表す、ある時点における測定値（スカラー値）です。一般的なメトリックの例としては、以下のようなものがあります。

  • 1 秒あたりの HTTP リクエスト数。
  • クエリ失敗の合計数。
  • データベースのサイズ（バイト単位）。
  • 最後のガベージコレクションからの経過時間（秒）。

監視ツールは通常、特定のメトリック値が設定されたしきい値を超えた場合にアラートを発するように構成されます。しきい値は、通常の動作条件に関する知識と経験に基づいて設定されます。

メトリックは通常、グループ化と検索を容易にするためにタグ付けされます。

アプリケーション開発者は、ソフトウェアをリリースする前に、どのようなメトリクスを計測するかを選択します。その結果、これまで未知の問題が発生した場合、新しいコードをリリースせずに新しいメトリクスを追加することは不可能です。さらに、メトリクスのカーディナリティ（基数）によって、テレメトリデータのストレージサイズが法外なコストになってしまう可能性があります。メトリクスはカーディナリティに制限があるため、集計値（例：平均ページ読み込み時間、5秒間のリクエストレートの平均など）を表すために使用されることがよくあります。外部コンテキストがなければ、イベント（ユーザーリクエストなど）と個別のメトリクス値を相関させることは不可能です。

ログ

ログ、またはログ行は、一般的に自由形式の非構造化テキストBLOBであり、人間が判読できるように意図されています。現代のログ記録は、機械による解析を可能にするように構造化されています。[ 4 ]メトリクスと同様に、アプリケーション開発者は事前にアプリケーションをインストルメント化し、異なるログ情報が必要な場合は新しいコードをリリースする必要があります。

ログには通常、タイムスタンプと重大度レベルが含まれます。イベント（ユーザーリクエストなど）は複数のログ行に分割され、同時発生しているイベントのログと混在する場合があります。

痕跡

分散トレース

クラウドネイティブアプリケーションは通常、単一のリクエストを処理する分散サービスで構成されています。分散トレースとは、単一のユーザーリクエストの進行を追跡する、相互に関連する一連の個別のイベント（スパンとも呼ばれます）です。[ 4 ]トレースは、リクエストを処理するために相互運用するサービス間の因果関係と時間的関係を示します。

アプリケーションをトレースで計測するということは、スパン情報をトレースバックエンドに送信することを意味します。トレースバックエンドは受信したスパンを相関させ、表示可能なトレースを生成します。リクエストが複数のサービスを通過する際に追跡できるようにするため、スパンには一意の識別子が付与され、スパン間の親子関係を構築できます。スパン情報は通常、送信リクエストのHTTPヘッダーで共有されます。[ 4 ] [ 15 ] [ 16 ]

継続的なプロファイリング

継続的なプロファイリングは、アプリケーションがリソースをどのように消費しているかを正確に判断するために使用される別のテレメトリタイプです。[ 17 ]

計装

アプリケーションを観察するには、アプリケーションの動作に関するテレメトリを収集またはエクスポートする必要があります。インストルメンテーションとは、アプリケーションの通常の動作と並行してテレメトリを生成することを意味します。[ 4 ]テレメトリは独立したバックエンドによって収集され、後で分析されます。

急速に変化するシステムでは、計測機器自体が、意図（エンジニアが名前を付けて収集することを決定したディメンションは何ですか？）と、生産のライブステータスのリアルタイムの最新情報を組み合わせるため、最良のドキュメントとなることがよくあります。[ 4 ]

インストルメンテーションは自動またはカスタムで実行できます。自動インストルメンテーションは包括的なカバレッジと即時的な価値を提供します。一方、カスタムインストルメンテーションはより高い価値をもたらしますが、インストルメント対象のアプリケーションへのより密接な関与が必要になります。

インストルメンテーションはネイティブ（コード内で実行、インストルメントされたアプリケーションのコード変更）またはコード外（サイドカー、eBPFなど）で行うことができます。

新しい機能をカスタムインストルメンテーションとともに出荷することで本番環境で検証することは、「観測性駆動開発」と呼ばれる手法です。[ 4 ]

「可観測性の柱」

メトリクス、ログ、トレースは、可観測性の柱として最も一般的に挙げられます。[ 14 ]メジャーズらは、可観測性の柱は高カーディナリティ、高次元性、探索可能性であると示唆し、 「現代のシステムでは、全く同じ方法で2度失敗することはめったにない」ため、ランブックやダッシュボードにはほとんど価値がないと主張しています。[ 4 ]

自己監視

セルフモニタリングとは、可観測性スタックが相互に監視することで、目立たない障害のリスクを軽減する手法です。高可用性と冗長性に加えてセルフモニタリングを導入することで、相関する障害をさらに回避できます。

参照

参考文献

  • アレックス・ボテン、チャリティ・メジャーズ（2022年）。OpenTelemetryによるクラウドネイティブ・オブザーバビリティ。Packt Publishing。ISBN 978-1-80107-190-1. OCLC  1314053525 .
  • メジャーズ、チャリティ、フォン＝ジョーンズ、ミランダ、ジョージ (2022). 『可観測性エンジニアリング：優れた製造工程の実現』（第1版）. セバストポル、カリフォルニア州: O'Reilly Media, Inc. ISBN 9781492076445. OCLC  1315555871 .
  • シンディ・スリダラン（2018年）『分散システムの可観測性：堅牢なシステム構築ガイド』（第1版）セバストポル、カリフォルニア州：オライリー・メディア社ISBN 978-1-4920-3342-4. OCLC  1044741317 .
  • ハウゼンブラス、マイケル（2023年）『クラウド・オブザーバビリティの実践』マニング社、ISBN 9781633439597. OCLC  1359045370 .

参考文献

  1. ^フェローズ、ジェフ (1998). 「高性能クライアント/サーバー：堅牢な分散システムの構築と管理ガイド」.インターネットリサーチ. 8 (5) intr.1998.17208eaf.007. doi : 10.1108/intr.1998.17208eaf.007 . ISSN 1066-2243 . 
  2. ^ Cantrill, Bryan (2006). 「隠れた問題点：ソフトウェアの可観測性の向上は、最も深刻なパフォーマンス問題の診断に役立つ」 . ACM Queue . 4 (1): 26– 36. doi : 10.1145/1117389.1117401 . ISSN 1542-7730 . S2CID 14505819 .  
  3. ^ 「可観測性とは？」 Grafana Labs . 2025年12月8日閲覧。
  4. ^ a b c d e f g h iメジャーズ、チャリティ、フォン＝ジョーンズ、リズ、ミランダ、ジョージ (2022).可観測性エンジニアリング：優れた生産環境の実現（第1版）. セバストポル、カリフォルニア州: O'Reilly Media, Inc. ISBN 9781492076445. OCLC  1315555871 .
  5. ^ 「可観測性とは何か」 IBM 、 2021年10月15日。 2023年3月9日閲覧。
  6. ^ 「データソースでの可観測性の開始方法」 . Cisco . 2023年10月26日. 2023年10月26日閲覧。
  7. ^ a b Livens, Jay (2021年10月). 「可観測性とは何か？」 Dynatrace . 2023年3月9日閲覧。
  8. ^ a b c「DevOps測定：モニタリングとオブザーバビリティ」 Google Cloud . 2023年3月9日閲覧。
  9. ^ Reinholds, Amy (2021年11月30日). 「可観測性とは何か？」 . New Relic . 2023年3月9日閲覧。
  10. ^ 「構造化ログとイベントの違いは？」 2018年6月26日。
  11. ^ Hadfield, Ally (2022年6月29日). 「オブザーバビリティ vs. モニタリング：DevOpsにおける違いとは？」 Instana . 2023年3月15日閲覧。
  12. ^ Kidd, Chrissy. 「モニタリング、オブザーバビリティ、テレメトリ：オブザーバブルな作業に必要なすべてのこと」 . 2023年3月15日閲覧。
  13. ^ 「オブザーバビリティとは？初心者向けガイド」Splunk . 2023年3月9日閲覧。
  14. ^ a b Sridharan, Cindy (2018). 「第4章 可観測性の3つの柱」 . 『分散システムの可観測性：堅牢なシステム構築ガイド』（第1版）. セバストーポル、カリフォルニア州: O'Reilly Media, Inc. ISBN 978-1-4920-3342-4. OCLC  1044741317 .
  15. ^ 「トレースコンテキスト」 . W3C. 2021年11月23日. 2023年9月27日閲覧。
  16. ^ "b3-propagation" . openzipkin . 2023年9月27日閲覧。
  17. ^ 「継続的なプロファイリングとは？」 Cloud Native Computing Foundation . 2022年5月31日. 2023年3月9日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Observability_(software)&oldid=1326403744#Telemetry_types」から取得