対象読者
この連載では以下の読者を想定しています。
- オブザーバビリティやOpenTelemetryに興味がある人
- SREやDevOps、Platform Engineeringに取り組んでいるエンジニア
- バックエンド開発者、クラウドエンジニア、インフラエンジニア
オブザーバビリティに関してよく耳にする「計装」とは
前回までの連載で以下のようなテーマを扱ってきました。
- 第1回：オブザーバビリティとは何か、OpenTelemetryとは何か
- 第2回：オブザーバビリティを支えるテレメトリーデータとは何か、どう活用するか
- 第3回：OpenTelemetry Collectorによって、どのようにデータを扱うか
まだご覧になっていない方は、是非ご一読ください。
第4回目となる今回は、計装に注目します。
計装とはアプリケーションやシステムに対する設定やコードの追加によって、トレース、メトリクス、ログなどのテレメトリーデータを出力させることを指します。
前回の連載で扱ったOpenTelemetry CollectorによってOSやミドルウェアなどのテレメトリーデータを扱う方法をご紹介しましたが、アプリケーションやソフトウェアに関しては、それぞれの開発言語や実装、提供機能などに応じた出力の設定が必要です。
なぜ計装が必要なのか、それは今のシステムの状態をより正しく把握するためです。例えば何らかの問題が起きた時には、以下のようなことを知りたくなるはずです。
- システムの利用者がどんな操作を行ったか
- その操作はどのアプリケーションで処理されたか
- そのアプリケーションは、どのようなライブラリやフレームワークを用いて、どれくらいの時間で処理したのか
- 次にどのアプリケーションに連携されたのか
- 一連の処理の中で、どこで、どんなエラーが起きたのか
他にも、システムに変更を加える場合には、どこに影響が及びうるか、その影響をどのように捉えることができるか、といった点を気にするでしょう。
こういったシステムの内部状態を理解できるようにする取り組みの一つとして「計装」というものが必要になっていくのです。
計装を通じてシステムの内部状態に対する理解の解像度が上がるほど、システムの信頼性を維持・向上させることにつながるはずです。ITに関わる方であれば「障害原因を推測するしかない状態に陥った」「その推測が誤っていて障害が再発してしまった」「何らかのデバッグに必要な情報が足りず原因が見つからない」といった経験をされた方も少なくないでしょう。これに対するアプローチとして、アプリケーションの内部状態を観測できるように、テレメトリーデータを生成・出力できるようにする取り組みが計装であると言えます。
メトリクスによってアプリケーションの処理の全体的な傾向を理解し、トレースによって問題が発生した処理を特定し、ログによって問題の原因を特定していく……というのは第2回でも扱った内容です。
