クラウド ネイティブの可観測性 OpenTelemetry の基礎 (アーキテクチャ/分散トレース/メトリック/ログ/サンプリング/コレクター)

OpenTelemetry とは何ですか?

OpenTelemetry は、Cloud Native Computing Foundation (CNCF) がホストするオープンソースの可観測性フレームワークです。これは、OpenCensus プロジェクトと OpenTracing プロジェクトの統合です。トレース、メトリック、ログなど、あらゆる種類の観測可能な信号に対して単一の標準を提供することを目指しています。

• https://opentelemetry.io
• https://www.cncf.io
• https://opencensus.io

OpenTelemetry は、テレメトリ データを収集してバックエンド プラットフォームに送信する方法を指定します。 OpenTelemetry は共通のデータ形式と API を提供することで、組織がさまざまな観測ツールやプラットフォームと統合してテレメトリ データを共有および再利用することを容易にします。

OpenTelemetry アーキテクチャは柔軟性、相互運用性、拡張性を促進し、開発者が特定のニーズと環境を満たす観測可能性のプラクティスを採用できるようにします。

テレメトリデータの種類

OpenTelemetry はさまざまなテレメトリ データ タイプをサポートしています。

• OpenTelemetry トレースは、複数のコンポーネントとサービスにわたる要求または操作の実行パスを表します。詳細なタイミングとコンテキスト情報が提供され、開発者はリクエストフローを理解し、パフォーマンスのボトルネックを特定できます。
• OpenTelemetry メトリックは、システムの動作またはリソース使用率の定量的な測定値です。これらは、時間の経過に伴うパフォーマンスの監視と分析に役立ち、アラート、容量計画、傾向分析に使用できます。
• OpenTelemetry ログには、アプリケーションで発生するイベント、エラー、アクティビティに関する構造化または非構造化テキスト情報が含まれます。これらはデバッグ、監査、トラブルシューティングに非常に役立ちます。

OpenTelemetry の使い方は？

OpenTelemetry を使い始める最も簡単な方法は、分散トレース ツール (Jaeger/SigNoz/Uptrace) を選択し、そのドキュメントに従うことです。

• https://www.jaegertracing.io
• 翻訳元
• https://uptrace.dev

用語集

• OpenTelemetry API は、トレース、メトリック、ログなどのテレメトリ データを収集するためにコードをインストルメント化するために使用できるプログラム インターフェイスです。
• OpenTelemetry SDK は、収集されたテレメトリ データを処理してバックエンドにエクスポートするための OpenTelemetry API の公式実装です。
• OpenTelemetry Instrumentation は、OpenTelemetry API を使用して HTTP リクエスト、DB クエリ、ログ、エラーなどの重要な操作を記録する一般的なフレームワークおよびライブラリ用のプラグインです。
• OpenTelemetry Collector は、アプリケーションとバックエンド間のプロキシです。テレメトリ データを受信し、変換してから、データをバックエンドにエクスポートして永続的に保存します。コレクターは、OpenTelemetry Redis やファイル システム メトリックなどの監視対象システムからテレメトリ データを抽出するエージェントとしても機能します。
• OTLP は、SDK とコレクターがデータをバックエンドまたは他のコレクターにエクスポートするために使用する OpenTelemetry プロトコルです。 OTLP は、トランスポート プロトコルとして、gRPC (OTLP/gRPC) または HTTP (OTLP/HTTP) を使用できます。
• OpenTelemetry バックエンドは、OpenTelemetry によって収集されたテレメトリ データを受信、保存、分析する役割を担います。これはデータの中央リポジトリまたは処理パイプラインとして機能し、アプリケーションによって生成されたテレメトリ データを集計、クエリ、視覚化して分析情報を得ることができます。
• OpenTelemetry Jaeger は OpenTelemetry エコシステムのプロジェクトであり、テレメトリ データを保存、分析、視覚化するためのデフォルトの OpenTelemetry バックエンドとしてよく使用されます。

OpenTelemetry アーキテクチャ

概要

OpenTelemetry アーキテクチャは、アプリケーションやサービスからテレメトリ データを収集、送信、処理するための標準化された方法を提供することを目的としています。これは、分散システムでの可観測性を実現するために連携して動作するいくつかの主要コンポーネントで構成されています。

写真

可観測性シグナル

OpenTelemetry は、観測信号をキャプチャするための標準化された方法を提供します。

• メトリクスは問題があることを示しています。
• トレースを見れば問題がどこにあるのかがわかります。
• ログは根本原因を見つけるのに役立ちます。

OpenTelemetry メトリックは、システムの動作を定量化するのに役立つ定量的な指標です。これらは、CPU 使用率、メモリ消費量、リクエストの待ち時間など、アプリケーションの特定の側面の現在の状態または速度に関する情報を提供します。 OpenTelemetry を使用すると、カスタム メトリックを定義して記録し、アプリケーションのパフォーマンスと健全性を監視できます。

• https://opentelemetry.io/docs/concepts/signals/metrics/

OpenTelemetry Traces は、分散システムを介したリクエストの実行パスの詳細な記録を提供します。個々の操作とその関係のタイミング情報を取得し、リクエスト フローを理解し、ボトルネックを特定し、パフォーマンスの問題をトラブルシューティングできるようにします。 OpenTelemetry を使用すると、コードをインストルメント化して分散トレースを生成し、サービス間の相関関係を調べることができます。

• https://opentelemetry.io/docs/concepts/signals/traces/

OpenTelemetry ログは、アプリケーションの実行中に発生するイベントまたはメッセージのテキスト レコードです。これらは、アプリケーションの動作を理解し、問題を診断し、アクティビティを監査するのに役立ちます。 OpenTelemetry は、アプリケーションから構造化されたログをキャプチャし、コンテキスト情報でログを充実させるメカニズムを提供します。

• https://opentelemetry.io/docs/concepts/signals/logs/

計測ライブラリ（検出ツールプログラム）

OpenTelemetry は、開発者がアプリケーションをインストルメント化し、テレメトリ データを収集するために使用できるさまざまなプログラミング言語用のライブラリを提供します。

計装の公式詳細文書

• https://opentelemetry.io/docs/instrumentation/

オープンテレメトリSDK

OpenTelemetry SDK (ソフトウェア開発キット) は、開発者がアプリケーションをインストルメント化し、監視目的でテレメトリ データを収集できるようにするライブラリとツールのコレクションです。

Otel SDK は、OpenTelemetry をさまざまなプログラミング言語や環境に統合するための標準化された拡張可能なフレームワークを提供します。

輸出業者

OpenTelemetry エクスポータは、テレメトリ データを外部システムまたはバックエンドに送信して、保存、分析、視覚化を行う役割を担います。

OpenTelemetry は、テレメトリ データをエクスポートするためのさまざまなプロトコルと形式をサポートするさまざまなエクスポーターを提供します。このようなエクスポーターを使用すると、ユーザーは OpenTelemetry を好みの監視および分析ツールとシームレスに統合できます。

OpenTelemetry プロトコル

OpenTelemetry Protocol (OTLP) は、ソフトウェア システムおよびアプリケーションからテレメトリ データを収集、送信、エクスポートするためのオープン ソースのベンダー中立プロトコルです。

OTLP は、計測アプリケーションとバックエンド システム間で交換される接続形式とデータ構造を定義します。メトリック、トレース、ログのスキーマを含むテレメトリ データのエンコード形式と、ネットワーク経由でこのデータを送信するためのルールを指定します。

OTLP エクスポータを使用すると、収集されたテレメトリ データをバックエンドに転送して処理および分析することができます。

コンテキストの伝播

コンテキスト伝播により、関連するコンテキスト データ (トレース ID、スパン ID、その他のメタデータなど) がアプリケーションのさまざまなサービスやコンポーネント間で一貫して伝播されることが保証されます。

OpenTelemetry はコンテキストを伝播することにより、分散型およびマイクロサービス アーキテクチャでも、さまざまなサービスやコンポーネントから収集されたテレメトリ データの関連性が維持されることを保証します。エンドツーエンドのトレースをサポートしているため、リクエストフロー、パフォーマンスのボトルネック、システムの依存関係を理解し​​やすくなります。

リソース

リソース プロパティは、サービス、プロセス、コンテナーなどの監視対象エンティティに関するメタデータを提供するキーと値のペアです。これらは、リソースの識別に役立ち、テレメトリ データをフィルター処理およびグループ化するために使用できる追加情報を提供します。

OpenTelemetry では、テレメトリ データにリソース情報を含めることで、システムの動作をより適切に分析、視覚化、理解できるようになります。さまざまなソースからのテレメトリ データを相関させてコンテキスト化し、監視対象のアプリケーションまたはサービスのより包括的なビューを提供するのに役立ちます。

オープンテレメトリコレクター

OpenTelemetry Collector は、柔軟でスケーラブルなテレメトリ データ収集および処理ソリューションを提供することで、OpenTelemetry エコシステムにおいて重要な役割を果たします。

• https://opentelemetry.io/docs/collector/

Otel Collector は集中型の仲介者として機能し、データ収集の複雑さを簡素化し、さまざまなバックエンドやシステムとの柔軟な統合を可能にします。

OpenTelemetry バックエンド

OpenTelemetry には、データを処理および分析するための特定の組み込みバックエンドまたはストレージ システムは含まれていません。対照的に、OpenTelemetry は、特定のニーズと好みに基づいてさまざまなバックエンド システムを選択し、統合する柔軟性を提供します。

バックエンド システムは、インストルメント化されたアプリケーションまたは OpenTelemetry Collector からエクスポートされたテレメトリ データを受信します。これらのシステムは、テレメトリ データを保存、分析、視覚化する役割を担います。

OpenTelemetry 分散トレース

分散トレースを使用すると、リクエストがさまざまなサービスやシステムを通過する方法、各アクションのタイミング、発生したログやエラーを確認できます。

分散トレース ツールは、システムの動作を可視化し、パフォーマンスの問題を特定し、デバッグを支援し、分散アプリケーションの信頼性とスケーラビリティを確保するのに役立ちます。

OpenTelemetry トレースは、アプリケーションがユーザーの要求を満たすために連携して動作する複数の独立したサービスで構成されるマイクロサービス アーキテクチャのコンテキストで特に役立ちます。

追跡はどのように機能しますか?

最新のアプリケーション、特にマイクロサービスやサーバーレス アーキテクチャに基づくアプリケーションでは、単一のユーザー要求を満たすために、さまざまなサービスが相互に連携することがよくあります。このため、パフォーマンスのボトルネックを特定し、問題を診断し、システム全体の動作を分析することが困難になります。

分散トレースは、さまざまなサービスやコンポーネントを通過する単一のユーザー要求の経路を表すトレースを作成することで、これらの課題に対処することを目的としています。各トレースは相互接続された一連のスパンで構成され、各スパンは特定のサービスまたはコンポーネント内の単一の操作またはアクティビティを表します。

リクエストがサービスに届くと、トレース コンテキストがリクエストとともに伝播されます。これには通常、リクエストにトレース ヘッダーを挿入して、下流のサービスが同じトレースに参加できるようにすることが含まれま す。

リクエストがシステムを通過すると、各サービスは独自のスパンを生成し、操作期間、メタデータ、および関連するコンテキストに関する情報を使用してトレース コンテキストを更新します。

写真

分散トレース ツールは、生成されたトレース データを使用することで、システムの動作を可視化し、パフォーマンスの問題を特定し、デバッグを支援し、分散アプリケーションの信頼性とスケーラビリティを確保します。

スパン

Span はトレース内の操作 (作業単位) を表します。スパンは、リモート プロシージャ コール (RPC)、データベース クエリ、またはインプロセス関数呼び出しになります。スパンは以下を持ちます:

• スパン名（操作名）。
• 親スパン。
• 種類(タイプ)を範囲で指定します。
• 開始時間と終了時間。
• 操作の成功または失敗のステータスを報告します。
• 操作を記述するキー値属性のセット。
• イベントのタイムライン。
• 他のスパンへのリンクのリスト。
• サービス間でトレース ID やその他のデータを伝播するスパン コンテキスト。

トレースは、リクエストがアプリケーションを通過するパスを示すスパン ツリーです。ルート スパンはトレースの最初のスパンです。

写真

スパン名

OpenTelemetry バックエンドは、スパン名といくつかのプロパティを使用して、類似のスパンをグループ化します。スパンを正しくグループ化するには、短く簡潔な名前を付けます。一意のスパン名の合計数は 1000 未満である必要があります。そうでない場合、スパン グループが多すぎて、エクスペリエンスが低下する可能性があります。

次の名前は短く、一意であり、類似のスパンをグループ化するのに役立つため、適しています。

次の名前は、変数 params と args が含まれているため、正しくありません。

スパンタイプ

スパンの種別は次のいずれかの値である必要があります。

• server は、HTTP サーバー ハンドラーなどのサーバー操作に使用されます。
• client は、HTTP クライアント要求などのクライアント操作に使用されます。
• producer Kafka プロデューサーなどのメッセージ プロデューサー用。
• コンシューマーは通常、Kafka コンシューマーなどのメッセージ コンシューマーと非同期処理に使用されます。
• internal は内部操作に使用されます。

ステータスコード

ステータス コードは、操作の成功または失敗を示します。次のいずれかの値である必要があります。

• OK - 成功しました。
• エラー - 失敗。
• 未設定 - バックエンドが状態のデフォルト値を割り当てることを許可します。

属性

コンテキスト情報を記録するために、操作固有の情報を含む属性を使用してスパンに注釈を付けることができます。たとえば、HTTP エンドポイントには http.method = GET および http.route = /projects/:id が含まれる場合があります。

属性には任意の名前を付けることができますが、一般的な操作ではセマンティック属性規則を使用する必要があります。共通プロパティ キーのリストとその意味および可能な値を定義します。

イベント

開始時間と任意の数のプロパティを持つイベントでスパンに注釈を付けることもできます。イベントとスパンの主な違いは、イベントには終了時間がない (したがって継続時間がない) ことです。

イベントは通常、例外、エラー、ログ、メッセージ (RPC など) を表しますが、カスタム イベントを作成することもできます。

コンテクスト

Span コンテキストはさまざまなコンポーネントやサービスを通じて伝播し、Span に関する情報を伝達します。

トレース/スパン コンテキストは、リクエスト スコープのデータです。例:

• トレースID。トレースまたはクエリ全体のグローバルに一意の識別子。トレース内のすべてのスパンは同じトレース ID を持ちます。
• スパンID。トレース内の特定のスパンの一意の識別子。トレース内の各スパンには異なるスパン ID があります。
• トレースフラグ。トレースがサンプリングされているかどうかなど、トレースのさまざまなプロパティを示すフラグ。サンプリングとは、どのスパンを記録して観測性バックエンドに報告するかを決定するプロセスを指します。
• トレース状態。トレースに関連する追加のベンダーまたはアプリケーション固有のデータを格納するオプション フィールド。

スパンのコンテキストは、分散システムにおけるスパンの継続性と関連性を維持するために非常に重要です。これにより、さまざまなサービスとコンポーネントがそれぞれのスパンを正しいトレースに関連付けることができ、リクエストまたはトランザクション フローのエンドツーエンドの可視性が提供されます。

スパンのコンテキストは通常​​、荷物データが伝播される方法と同様に、サービス間の通信プロトコルのヘッダーまたはメタデータを使用して伝播されます。これにより、サービスがリクエストを受信したときに、スパン コンテキストを抽出し、受信したスパンを正しいトレースに関連付けることができるようになります。

コンテキスト内のデータはスパンの相関やサンプリングに使用できます。たとえば、トレース ID を使用して、どのスパンがどのトレースに属しているかを知ることができます。

コンテキストの伝播

コンテキスト伝播により、トレース ID、スパン ID、その他のメタデータなどの関連するコンテキスト データが、アプリケーションのさまざまなサービスやコンポーネント間で一貫して伝播されることが保証されます。

OpenTemetry は、プロセス内の関数間 (プロセス内伝播) や、あるサービスから別のサービス間 (分散伝播) にコンテキストを伝播します。

プロセス内伝播は、使用されるプログラミング言語に応じて、暗黙的または明示的に行うことができます。暗黙的な伝播は、アクティビティ コンテキストをスレッド ローカル変数 (Java、Python、Ruby、NodeJS) に保存することによって自動的に実行されます。明示的な伝播では、アクティビティ コンテキストをパラメーターとして 1 つの関数から別の関数に明示的に渡す必要があります (Go)。

分散コンテキスト伝播のために、OpenTelemetry はコンテキスト データをシリアル化して渡す方法を定義するいくつかのプロトコルをサポートしています。

• W3C トレース コンテキストは、traceparent ヘッダーにあります (例: traceparent=00-84b54e9330faae5350f0dd8673c98146-279fa73bc935cc05-01)。

https://www.w3.org/TR/trace-context/

• B3 Zipkin は、 x-b3- で始まるヘッダー内にあります (例: X-B3-TraceId )。
• https://github.com/openzipkin/b3-propagation

W3C トレース コンテキストは、デフォルトで有効になっている推奨プロパゲータです。

手荷物

Baggage は span context と同様に動作し、カスタムのキーと値のペア (属性) を 1 つのサービスから別のサービスに伝播できます。 gRPC の世界には、gRPC メタデータと呼ばれる同様の概念があります。

• https://github.com/open-telemetry/opentelemetry-specation/blob/main/specation/baggage/api.md

Baggage を使用すると、キーと値のペアをリクエストまたはトランザクションに関連付けることができます。これらのキーと値のペアは、ユーザー ID、セッション ID、その他のアプリケーション固有のメタデータなど、リクエストまたはトランザクションに関連する可能性のあるコンテキスト情報を表します。

Baggage は、分散システム全体でコンテキスト情報を維持および相関させるのに役立ち、アプリケーションの動作の観察と分析を向上させます。アドホックなメカニズムや手動の計測に頼ることなく、システム全体に関連データを渡す標準化された方法を提供します。

計測を優先すべき場合

計装の公式詳細文書

• https://opentelemetry.io/docs/instrumentation/

トレース機能を最大限に活用するために、すべてのアクションをログに記録する必要はありません。これにはかなりの時間がかかる可能性があり、通常は必要ありません。次のアクションを優先します。

• HTTP リクエストや RPC 呼び出しなどのネットワーク操作。
• ファイルの読み取り/書き込みなどのファイルシステム操作。
• ネットワーク操作とファイル システム操作を組み合わせたデータベース クエリ。
• たとえば、エラーやログでは構造化されたログが使用されます。

OpenTelemetry メトリクス

OpenTelemetry Metrics は、メトリックを収集、集約し、Uptrace や Prometheus などの OpenTelemetry APM ツールに送信する方法の標準です。

OpenTelemetry は、新しい標準を定義すると同時に、Prometheus や Statsd などの既存のメトリック ツール プロトコルとの連携にも取り組んでいます。さらに、OpenTelemetry Collector は、AWS Metrics、InfluxDB、Chrony など、さらに多くのプロトコルをサポートしています。

OpenTelemetry を使用すると、例を通じてメトリックとトレースを相関させることもできるため、システムの状態をより広範囲に把握できるようになります。

インジケーターとは何ですか?

メトリックは、CPU 使用率、ネットワーク トラフィック、データベース接続など、システムの健全性とパフォーマンスを表す数値データ ポイントです。

メトリックを使用してパフォーマンスを測定、監視、比較できます。たとえば、サーバーの応答時間、メモリ使用率、エラー率などを測定できます。

楽器

インストルメントは、アプリケーションの動作の特定の側面に関するデータを収集する特定のタイプのメトリック (カウンター、ゲージ、ヒストグラムなど) です。

次の機能を備えた計測器を作成して測定値を取得します。

• http.server.duration などの一意の名前。
• ヒストグラムなどの計器タイプ。
• ミリ秒やバイトなどのオプションの測定単位。
• オプションの説明。

時系列

機器は複数の時系列を生成できます。時系列は、一意のプロパティ セットを持つメトリックです。たとえば、各ホストには同じメトリック名に対して個別の時系列があります。

付加的な機器

加算可能または合計可能な機器は時系列を生成し、それらを加算すると、別の意味のある正確な時系列が生成されます。減少しない数値を測定する加算的な計器は単調とも呼ばれます。

たとえば、http.server.requests は、異なるホストからのリクエストの数を合計してリクエストの合計数を取得できるため、加算的な時系列です。

ただし、異なるホストからのメモリ使用率の合計は意味をなさないため (90% + 90% = 180%)、system.memory.utilization (パーセント) は加算されません。

同期機器

同期計測器は、測定している操作とともに呼び出されます。たとえば、リクエストの数を測定するには、新しいリクエストが行われるたびに counter.Add(ctx, 1) を呼び出すことができます。同期測定には、関連付けられたトレース コンテキストを設定できます。

同期機器の場合、加算機器とグループ化機器の違いは、加算機器は合計可能な時系列を生成するのに対し、グループ化機器はヒストグラムを生成することです。

非同期機器

非同期計測器は、定期的にコールバック関数を呼び出して測定値を収集します。たとえば、ウォッチャーを使用してメモリや CPU の使用状況を定期的に測定できます。非同期測定には、関連付けられたトレース コンテキストを持つことはできません。

UpDownCounterObserver (加算) と GaugeObserver (グループ化) のどちらかを選択する場合、合計可能な時系列の場合は UpDownCounterObserver を選択し、それ以外の場合は GaugeObserver を選択します。たとえば、system.memory.usage (バイト) を測定するには、UpDownCounterObserver を使用する必要があります。ただし、system.memory.utilization (パーセント単位) を測定するには、GaugeObserver を使用する必要があります。

楽器を選択

1. ヒストグラム、ヒートマップ、またはパーセンタイルが必要な場合は、ヒストグラムを使用します。
2. 増分値を記録してカウントする場合:

値が単調な場合は、Counter を使用します。

それ以外の場合は、UpDownCounter を使用します。

3. 絶対値を記録して何かを測定したい場合:

• 値が単調な場合は、CounterObserver を使用します。
• それ以外の場合は、UpDownCounterObserver を使用します。
• 値が加算可能/合計可能な場合:
• 値が加算/合計可能でない場合は、GaugeObserver を使用します。

カウンタ

同期単調

カウンターは、加算的で減少しない値を測定する同期機器です。次に例を示します。

• 処理されたリクエスト
• エラー
• 受信バイト数
• ディスク読み取り

カウンターは、イベントの発生回数や時間の経過に伴う値の蓄積を測定するために使用されます。それらは時間の経過とともに増加するだけです。

カウンター時系列の場合、バックエンドは通常、デルタを計算してレート値を表示します。たとえば、per_min(http.server.requests) は 1 分あたりに処理されるリクエストの数を返します。

カウンターオブザーバー

非同期単調

CounterObserver は、Counter インストルメントの非同期バージョンです。

アップダウンカウンター

同期加算

UpDownCounter は、時間の経過とともに増加または減少する可能性のある増分値を測定するために使用される同期計測器です。次に例を示します。

• アクティブなリクエスト
• オープン接続
• 使用中のメモリ（メガバイト）

減少しない値を追加するには、Counter または CounterObserver を使用する必要があります。

UpDownCounter 時系列の場合、バックエンドは通常最後の値を表示しますが、異なる時系列を追加することもできます。たとえば、go.sql.connections_open は開いている接続の合計数を返し、go.sql.connections_open{service.name = myservice} はサービスの開いている接続の数を返します。

アップダウンカウンターオブザーバー

非同期加算

UpDownCounterOserver は、UpDownCounter インストルメントの非同期バージョンです。

ヒストグラム

同期グループ化

ヒストグラムは、記録された値に基づいてヒストグラムを生成する同期機器です。次に例を示します。

• リクエストの遅延
• リクエストサイズ

ヒストグラムは、時間の経過に伴う値の分布を測定するために使用されます。ヒストグラムの時系列の場合、バックエンドでは通常、パーセンタイル、ヒートマップ、ヒストグラムが表示されます。

ゲージオブザーバー

非同期グループ化

GaugeObserver は、合計しても意味のある正しい結果が得られない非加算値を測定するために使用される非同期機器です。例えば：

• エラー率
• メモリ使用率
• キャッシュヒット率

GaugeObserver 時系列の場合、バックエンドは通常最後の値を表示するため、異なる時系列を一緒に追加することはできません。

メトリクスの例

メールの数

送信されたメールの数を測定するには、メールが送信されるたびに増加するカウンター インストルメントを作成します。

 import "go.opentelemetry.io/otel/metric" var emailCounter = meter.NewInt64Counter( "some.prefix.emails", metric.WithDescription("Number of sent emails"), ) emailCounter.Add(ctx, 1)

後で、次のようなプロパティを追加して詳細な統計情報を収集できます。

• kind = welcome と kind = reset_password は異なるメールを測定します。
• バウンスされたメールを測定するには、state = sent および state = bounced を使用します。

運用遅延

操作のレイテンシを測定するには、ヒストグラム インストルメントを作成し、操作と同期して更新します。

 import "go.opentelemetry.io/otel/metric" var opHistogram = meter.NewInt64Histogram( "some.prefix.duration", metric.WithDescription("Duration of some operation"), ) t1 := time.Now() op(ctx) dur := time.Since(t1) opHistogram.Record(ctx, dur.Microseconds())

キャッシュヒット率

キャッシュヒット率を測定するには、CounterObserver を作成し、キャッシュ統計を監視します。

 import "go.opentelemetry.io/otel/metric" var counter metric.Int64CounterObserver // Arbitrary key/value labels. hits := []attribute.KeyValue{attribute.String("type", "hits")} misses := []attribute.KeyValue{attribute.String("type", "misses")} errors := []attribute.KeyValue{attribute.String("type", "errors")} batchObserver := meter.NewBatchObserver( func(ctx context.Context, result metric.BatchObserverResult) { stats := cache.Stats() result.Observe(hits, counter.Observation(int64(stats.Hits))) result.Observe(misses, counter.Observation(int64(stats.Misses))) result.Observe(errors, counter.Observation(int64(stats.Errors))) }) counter = batchObserver.NewInt64CounterObserver("some.prefix.cache_operations")

エラー率

エラー率を直接測定するには、GaugeObserver を作成し、計算方法を気にせずに値を観察することができます。

 import "go.opentelemetry.io/otel/metric" _ = meter.NewFloat64GaugeObserver("some.prefix.error_rate", func(ctx context.Context, result metric.Float64ObserverResult) { result.Observe(rand.Float64()) }, metric.WithDescription("Error rate as reported by some other system"), )

OpenTelemetry ログ

OpenTelemetry Logs を使用すると、他の観測可能な信号との相関関係とより適切な統合を可能にする方法でログの記録と収集を行うことができます。

ログは、アプリケーションの動作を理解し、問題を診断し、システムの健全性を監視するために重要です。分散トレースとメトリックはシステム パフォーマンスに関する貴重な洞察を提供し、ログは特定のイベント、エラー、アプリケーションの動作に関する詳細なコンテキストと情報を提供します。

概要

OpenTelemetry は主にメトリックとトレースの収集に重点を置いていますが、ログ API を介したログ収集もサポートしています。 OpenTelemetry は既存のログ記録ソリューションをサポートし、既存のログ記録ライブラリおよびログ収集ツールと適切に連携することを保証します。

OpenTelemetry は、アプリケーションを計測し、構造化されたログを生成できるログ API を提供します。 OpenTelemetry Logging API は、メトリックやトレースなどの他のテレメトリ データと連携して、統合された可観測性ソリューションを提供するように設計されています。

OpenTelemetry は構造化されたログ記録を重視しており、属性またはメタデータを通じてログ エントリに追加のコンテキスト情報を添付できます。これにより、タイムスタンプ、リクエスト ID、ユーザー ID、相関 ID、その他のカスタム コンテキストなど、ログ分析やトラブルシューティングに役立つ関連詳細を含めることができます。

さまざまな種類のログ

OpenTelemetry は、アプリケーションまたはシステム内のさまざまなソースからのログのキャプチャをサポートします。ログは、生成および収集方法に基づいて 3 つのカテゴリに分類できます。

システムとインフラストラクチャのログ

システム ログは、システムの動作、パフォーマンス、セキュリティに関する貴重な情報を提供します。システム ログは通常、オペレーティング システム、アプリケーション、ネットワーク デバイス、サーバーなど、システム内のさまざまなコンポーネントによって生成されます。

システム ログはホスト レベルで書き込まれ、簡単に変更できない定義済みの形式と内容を持ちます。システム ログには、トレース コンテキストに関する情報は含まれません。

レガシーファーストパーティログ

ファーストパーティ ログは内部アプリケーションによって生成され、特定のアプリケーション イベント、エラー、およびユーザー アクティビティを記録します。これらのログは、アプリケーションのデバッグやトラブルシューティングに非常に役立ちます。

通常、開発者はこれらのアプリケーションを変更して、ログの書き込み方法やログに含まれる情報を変更できます。たとえば、ログとトレースを関連付けるには、開発者は各ログ ステートメントにトレース コンテキストを手動で追加するか、ログ ライブラリのプラグインを使用して自動的に追加することができます。

たとえば、コンテキストを伝播し、ログ記録をスパンに関連付けるには、ログ メッセージで次の属性を使用できます。

• trace_id は TraceId に使用され、16 進数でエンコードされます。
• span_id は 16 進数でエンコードされた SpanId です。
• trace_flags は、W3C トレースフラグ形式に従ってフォーマットされたトレースフラグに使用されます。

例えば：

 request failed trace_id=958180131ddde684c1dbda1aeacf51d3 span_id=0cf859e4f7510204

新しいファーストパーティログ

新しいプロジェクトを開始するときは、OpenTelemetry の推奨事項とベスト プラクティスに従って、自動インストルメンテーションを使用してログを出力する方法や、OpenTelemetry ログ アペンダーを使用するようにログ ライブラリを構成する方法を学習できます。

OpenTelemetry のログ API を使用すると、開発者はアプリケーションをインストルメント化して、ログ バックエンドまたはログ管理システムで収集および処理できる構造化ログを生成できます。 Logging API は、タグ、属性、メタデータなどの追加のコンテキスト情報をログエントリに添付する方法を提供します。

Logger API を使用して、デバッグ、情報、警告、エラーなど、さまざまな重大度のイベントまたはメッセージをログに記録します。ログ エントリに追加のプロパティまたはコンテキストを追加して、詳細情報を提供することもできます。

OpenTelemetry は、分散システム全体にログ内のコンテキストを伝播するための標準化された方法も提供します。これにより、ログがシステムのさまざまなコンポーネントによって生成された場合でも、関連する実行コンテキストが一貫してキャプチャされ、保存されます。

OpenTelemetry Logs データ モデルを使用すると、TraceId と SpanId を LogRecords に直接含めることができます。

オープンテレメトリコレクター

OpenTelemetry Collector は、テレメトリ データを収集、処理、エクスポートするための柔軟で拡張可能なエージェントです。複数のバックエンドまたは可観測性システムにデータをエクスポートする機能により、複数のソースからのテレメトリ データの取り込みと管理のタスクが簡素化されます。

OpenTelemetry Collector は、アプリケーション ログ、ログ ファイル、ログ リポジトリ、サードパーティのログ システムなど、複数のログ ソースをサポートします。一般的なログ記録フレームワークおよびライブラリとの統合を提供し、ログ データをシームレスに取り込むことを可能にします。

コレクターは、ログ データを変換および強化する機能を提供します。ログのプロパティを変更したり、メタデータを追加したり、追加のコンテキスト情報でログを充実させたりすることで、ログの価値を高め、分析やトラブルシューティングにとってより有意義なものにすることができます。

収集と処理の後、OpenTelemetry Collector はログ データをさまざまなログ バックエンドまたはシステムにエクスポートできます。長期保存、分析、視覚化のために、一般的なログ記録プラットフォーム、ストレージ システム、またはログ管理ツールにログをエクスポートすることをサポートしています。

OpenTelemetry バックエンド

ログ データがログ記録バックエンドにエクスポートされると、プラットフォームの機能を使用してログを処理および分析できます。これには、ログのフィルタリング、検索、集約、視覚化が含まれ、アプリケーションの動作に関する洞察を得て、問題をトラブルシューティングすることができます。

OpenTelemetry サンプリング

OpenTelemetry サンプリングは、作成された (サンプリングされた) スパンの数を減らすことで、トレースのコストと冗長性を削減します。パフォーマンスの面では、サンプリングにより、スパンの収集、処理、エクスポートに必要な CPU サイクルとメモリが節約されます。

サンプリングとは何ですか?

サンプリングは分散トレースで使用され、収集されてトレース バックエンドに送信されるデータの量を制御しま す。データ量と追跡精度のトレードオフのバランスをとるのに役立ちます。

分散トレースでは、リクエストがシステムを流れるときにスパンを生成します。スパンは、リクエストの処理中に発生した単一のアクションまたはイベントを表します。複雑なシステムでは、これらのスパンが非常に大きくなる可能性があり、それらをすべてトレースバックエンドに送信すると、大幅なオーバーヘッドとストレージコストが発生する可能性があります。

サンプリングには、記録する期間と廃棄する期間を決定することが含まれます。

サンプリング：いつどこで

サンプリングは、スパン処理のさまざまな段階で発生する可能性があります。

• トレースを作成するとき - ヘッダーサンプリング。
• バックエンドがトレース - レート制限サンプリングを受信したとき。
• 完全なトレースが利用可能な場合 - テールベースのサンプリング。

サンプリング戦略の選択は、目的のレベルの観測可能性、利用可能なリソース、システムの特定のユースケースなど、いくつかの要因に依存します。

確率サンプリング

サンプリングは、サンプリングされたスパンの一部のみを使用して、すべてのスパンの正確な統計的カウントを可能にするサンプリング確率を提供します。たとえば、サンプリング確率が50％で、サンプリングされたスパンの数が10の場合、調整された（合計）スパン数は10 /50％= 20です。

ヘッドベースのサンプリング

ヘッドベースのサンプリングは、できるだけ早くサンプリングの決定を行い、コンテキストを使用して他の参加者にそれらを伝播します。これにより、スパンを削除するためにテレメトリーデータを収集しないことにより、CPUとメモリリソースを保存できます。

ヘッドベースのサンプリングは、最も単純で、最も正確で、最も信頼性の高いサンプリング方法であり、他のすべての方法よりもこの方法を好む必要があります。

ヘッダーベースのサンプリングの欠点の1つは、スパンが作成されたときにその情報が利用できないため、エラーのあるスパンをサンプリングできないことです。この問題に対処するために、テールベースのサンプリングを使用できます。

ヘッダーベースのサンプリングは、トラフィックピークを考慮しておらず、望ましいよりも多くのデータを収集する場合があります。これは、レート制限サンプリングが役立つ場所です。

Opentelemetryのヘッダーベースのサンプリング

OpenteleMetryには、クライアントサンプリングを担当する2つのスパンプロパティがあります。

• isRecording-偽の場合、スパンはプロパティ、イベント、リンクなどを破棄します。
• サンプリング - falseの場合、Opentelemetryはスパンを削除します。

高価なテレメトリデータの収集を避けるために、iSRecordingプロパティを確認する必要があります。

 if span.IsRecording() { // collect expensive data }

サンプラーは、作成されるルートスパンを受け入れる関数です。この関数はサンプリング決定を返します。

• ドロップ - トレースがドロップされます。 isRecording = false、sampled = false。
• Recordonly-トレースを記録しますが、サンプリングしないでください。 isRecording = true、sampled = false。
• RecordAndSample-トレースを記録してサンプリングします。 isRecording = true、sampled = true。

デフォルトでは、Opentelemetryはすべてのトレースをサンプリングしますが、トレースのサブセットをサンプリングするように構成できます。この場合、バックエンドは確率的サンプリングを使用してスパン数を調整します。

Opentelemetryサンプラー

常にトレースをサンプリングします。つまり、リクエストごとに新しいトレースが開始され、エクスポートされます。

AlwaysOffサンプラーは、トレースをサンプリングしません。つまり、すべてのトレースを削除します。このサンプラーを使用して、ロードテストを実行したり、トレースを一時的に無効にしたりできます。

TraceIDRATiobasedサンプラーは、トレースIDを使用して、トレースの20％などのトレースのごく一部をサンプリングします。

親ベースのサンプラーは、スパンの親要素に応じて異なる動作をする複合サンプラーです。新しいトレースを開始すると、サンプラーはそれをサンプリングするかどうかを決定し、その決定を他のサービスに伝播します。

レート制限サンプリング

レート制限サンプリングはサーバー側で発生し、特定の制限を超えないようにします。たとえば、10枚以下のトラックを毎秒サンプリングできます。

速度制限サンプリングは調整カウントをサポートしますが、精度は低くなります。より良い結果を得てパフォーマンスを向上させるには、より効率的で正確なヘッドベースのサンプリングで速度制限サンプリングを使用する必要があります。

ほとんどのバックエンドは、必要に応じて速度制限サンプリングを自動的に適用します。

テールサンプリングに基づいています

ヘッドサンプリングに基づくサンプリングでは、サンプリングの決定は事前に行われ、通常はランダムです。この情報は追跡の最後にのみ取得できるため、ヘッドベースのサンプリングは失敗または異常に長い操作をサンプリングすることはできません。

テールベースのサンプリングを使用して、追跡されたすべてのスパンが利用可能になるまでサンプリングの決定を遅らせ、追跡されたすべてのデータに基づいてより良いサンプリング決定になります。たとえば、失敗または異常に長いトレースをサンプリングできます。

ほとんどのOpentelemetryバックエンドは、必要に応じてテールベースのサンプリングを自動的に適用しますが、OpentelemetryコレクターとTailSamplingProcessorを使用して、ニーズに応じてサンプリングを構成することもできます。

確率ベースのサンプリング

確率ベースのサンプリングは、構成された確率またはサンプリングレートに基づいて記録されるトラックのサブセットをランダムに選択します。たとえば、サンプリングレートを10％に設定できます。つまり、トレースの10％のみが記録され、残りが廃棄されます。

確率ベースのサンプリングは、システム動作の代表的なサンプルを維持しながら追跡されたデータの量を減らしたい場合に役立ちます。オーバーヘッドと必要な観測可能性レベルのバランスをとるのに役立ちます。

Uptraceに基づいて、Opentelemetry Goで確率ベースのサンプラーを構成する方法を次に示します。

 import "go.opentelemetry.io/contrib/samplers/probability/consistent" sampler := consistent.ParentProbabilityBased( consistent.ProbabilityBased(0.5), // sample 50% of traces ) uptrace.ConfigureOpentelemetry( uptrace.WithTraceSampler(sampler), // Other options )

Opentelemetryコレクター

Opentelemetry Collectorは、観測可能性データのための高性能でスケーラブルで信頼性の高いデータ収集パイプラインです。さまざまなソースからテレメトリデータを受信し、処理を実行して共通形式に変換し、保存と分析のためにデータをさまざまなバックエンドにエクスポートします。

Otel Collectorは、さまざまなデータ形式、プロトコル、プラットフォームをサポートしているため、観察可能性のニーズに合わせて柔軟でスケーラブルなソリューションになっています。

Opentelemetryコレクターはどのように機能しますか？

Opentelemetry Collectorは、アプリケーションとSIGNOZ/JAEGERなどの分散追跡ツールの間のベンダーに依存しないエージェント/ミッドルマンです。

Opentelemetryコレクターは、さまざまなソースからテレメトリデータを受信し、データを処理および正規化し、ストレージと分析のためにさまざまなバックエンドにエクスポートすることにより機能します。

Otel Collectorは強力なデータ処理機能を提供し、集約、フィルタリング、サンプリング、リッチテレメトリデータを実行できます。バックエンドシステムにデータを送信する前に、データを変換および再構築して、特定の監視と分析のニーズを満たすことができます。

Otel CollectorはGOで記述され、Apache 2.0ライセンスを使用します。これにより、ソースコードを変更してカスタムエクステンションをインストールできます。これは、独自のOpentelemetryコレクターインスタンスを実行および維持することを犠牲にして提供されます。

Opentelemetryコレクターをいつ使用するのですか？

ほとんどの場合、テレメトリーデータをバックエンドに直接送信することは、Opentelemetryを開始するのに最適な方法です。ただし、バッチ処理、再試行、機密データフィルタリングなどを取得するために、サービスの横にコレクターを展開することをお勧めします。

Opentelemetry Collectorの最も顕著な特徴は、単一のスパンではなく、軌道全体を操作できることです。これを達成するために、Opentelemetry Collector Buffersはスパンを受信し、Trace IDでグループ化しました。これは、テールベースのサンプリングを実装するための重要な要件です。

Opentelemetryコレクターは、監視対象システム、たとえばOpentelemetry Redisまたはホストメトリックなどからテレメトリデータを抽出するエージェントとして機能することもできます。

OtelcolおよびOtelcol-Contrib

Opentelemetry Collectorには、Githubに2つのリポジトリがあります。

• Opentelemetry-Collectorは、最も重要なコンポーネントのみを含むコアです。 Otelcolバイナリとして分布しています。

• https://github.com/open-telemetry/opentelemetry-collector

• OpenteleMetry-Collector-Contribには、RedisやPostgreSQLレシーバーなど、コアと追加の利用可能なすべてのコンポーネントが含まれています。 Otelcol-Contribバイナリとして分布しています。
• https://github.com/open-telemetry/opentelemetry-collector-contrib

Otelcol-Contribは、コアと同じくらい安定しており、より多くの機能をサポートするため、常にインストールして使用する必要があります。

インストール

Opentelemetryコレクターは、Linux、MacOS、およびWindowsの事前コンパイルされたバイナリを配布します。

リナックス

Otelcol-Contribバイナリと関連するSystemDサービスをインストールするには、次のコマンドを実行して、0.82.0を必要なバージョンに、AMD64を必要なスキーマに置き換えます。

デビアン

wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.82.0/otelcol-contrib_0.82.0_linux_amd64.deb sudo dpkg -i otelcol-contrib_0.82.0_linux_amd64.deb

RPM

 wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.82.0/otelcol_0.82.0_linux_amd64.rpm sudo rpm -ivh otelcol_0.82.0_linux_amd64.rpm

次のコマンドを使用して、インストールされたサービスのステータスを確認できます。

 sudo systemctl status otelcol-contrib

次のコマンドでログを確認してください。

 sudo journalctl -u otelcol-contrib -f

/etc/otelcol-contrib/config.yamlで構成を編集できます。 Opentelemetryコレクターを再起動します。

 sudo systemctl restart otelcol-contrib

ソースコードからコンパイルします

Opentelemetryコレクターをローカルにコンパイルすることもできます。

 git clone https://github.com/open-telemetry/opentelemetry-collector-contrib.git cd opentelemetry-collector-contrib make install-tools make otelcontribcol ./bin/otelcontribcol_linux_amd64 --config ./examples/local/otel-config.yaml

構成

Opentelemetry Collectorは高度に構成可能であるため、動作をカスタマイズして観測可能性スタックに統合できます。入力、プロセッサ、輸出業者を指定するための構成オプションを提供し、特定のニーズに合わせてエージェントをカスタマイズできるようにします。

デフォルトでは、/etc/otelcol-contrib/config.yamlで構成ファイルを見つけることができます。たとえば（Uptrace）：

 # receivers configure how data gets into the Collector. receivers: otlp: protocols: grpc: http: # processors specify what happens with the received data. processors: resourcedetection: detectors: [env, system] cumulativetodelta: batch: send_batch_size: 10000 timeout: 10s # exporters configure how to send processed data to one or more backends. exporters: otlp/uptrace: endpoint: otlp.uptrace.dev:4317 headers: uptrace-dsn: 'https://<token>@uptrace.dev/<project_id>' # service.pipelines pull the configured receivers, processors, and exporters together into # pipelines that process data. # # receivers, processors, and exporters that are not used in pipelines are silently ignored. service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlp/uptrace] metrics: receivers: [otlp] processors: [cumulativetodelta, batch, resourcedetection] exporters: [otlp/uptrace] logs: receivers: [otlp] processors: [batch] exporters: [otlp/uptrace]

Otel Collectorの詳細については、公式ドキュメントをご覧ください。

• https://opentelemetry.io/docs/collector/configuration/

トラブルシューティング

Otelcolが期待どおりに機能していない場合は、ログ出力の潜在的な問題を確認できます。冗長ロギングのレベルはデフォルトで情報ですが、構成ファイルを使用して変更できます。

 service: telemetry: logs: level: 'debug'

潜在的な問題のログを表示します。

 sudo journalctl -u otelcol-contrib -f

また、メトリックがOpentelemetryコレクターを監視できるようにすることもできます。

 receivers: prometheus/otelcol: config: scrape_configs: - job_name: 'otelcol' scrape_interval: 10s static_configs: - targets: ['0.0.0.0:8888'] service: telemetry: metrics: address: ':8888' pipelines: metrics/hostmetrics: receivers: [prometheus/otelcol] processors: [cumulativetodelta, batch, resourcedetection] exporters: [otlp/uptrace]

拡張機能

拡張機能は、Opentelemetryコレクターに追加の機能を提供し、テレメトリーデータへの直接アクセスを必要としません。たとえば、ヘルスチェック拡張はヘルスチェックリクエストに応答します。

 extensions: # Health Check extension responds to health check requests health_check: # PProf extension allows fetching Collector's performance profile pprof: # zPages extension enables in-process diagnostics zpages: # Memory Ballast extension configures memory ballast for the process memory_ballast: size_mib: 512

リソース検出

ホストからリソース情報を検出するために、Otel Collectorには独自のResourcedEtectionプロセッサが付属しています。

• https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor

リソース検出プロセッサは、データ生成環境に関するメタデータを自動的に検出およびタグ付けします。このメタデータは「リソース」と呼ばれ、テレメトリデータのコンテキストを提供します。これには、ホスト、サービス、コンテナ、クラウドプロバイダーなどの情報が含まれます。

たとえば、host.nameおよびos.typeプロパティを検出するには、システム検出器を使用できます。

 processors: resourcedetection: detectors: [env, system] service: pipelines: metrics: receivers: [otlp, hostmetrics] processors: [batch, resourcedetection] exporters: [otlp/uptrace]

IPアドレスなどのカスタムプロパティを追加するには、ENV変数とENV検出器を使用できます。

 export OTEL_RESOURCE_ATTRIBUTES="instance=127.0.0.1"

より多くの情報を検出するには、より専門的な検出器を使用できます。たとえば、Amazon EC2を使用している場合、EC2検出器を使用してCloud.RegionとCloud.Abailability_Zoneプロパティを発見できます。

 processors: resourcedetection/ec2: detectors: [env, ec2]

Google Cloudを使用している場合：

 processors: resourcedetection/gcp: detectors: [env, gcp]

Dockerを使用している場合：

 processors: resourcedetection/docker: detectors: [env, docker]

Heroku、Azure、Consul、および他の多くの検出器の公式ドキュメントをご覧ください。

• https://github.com/open-telemetry/opentelemetry-clollector-contrib/tree/main/processor/resourcedetectionprocessor#system-metadata

メモリリミッター

MemoryLimiterProcessorは、テレメトリデータを処理するときにOpentelemetryコレクターによって消費されるメモリの量をユーザーが制限できるコンポーネントです。これにより、コレクターがあまりにも多くのメモリを使用することを防ぎ、パフォーマンスの問題を引き起こしたりクラッシュしたりする可能性があります。

• https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/memorylimiterprocessor/readme.md

メモリ限定プロセッサは、Opentelemetryコレクターによって消費されるメモリの量を定期的にチェックし、ユーザー定義のメモリ制限と比較することで機能します。コレクターがメモリを使用して指定された制限を超えた場合、プロセッサはメモリの使用量が制限を下回るまでテレメトリデータの破棄を開始します。

メモリリミッターを有効にするには：

 processors: memory_limiter: check_interval: 1s limit_mib: 4000 spike_limit_mib: 800 service: pipelines: metrics: processors: [memory_limiter]

Opentelemetryホストメトリック

HostmetricsReceiverは、CPU、RAM、ディスクメトリック、その他のシステムレベルメトリックなどのホストシステムに関するさまざまなメトリックを収集するOpentelemetry Collectorプラグインです。

• https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver

ホストメトリックを収集および分析することにより、ホストシステムのパフォーマンスと健康に関する洞察を得て、アプリケーションとサービスの全体的なパフォーマンスに影響を与える可能性のある潜在的な問題またはボトルネックを特定できます。

ホストメトリック

ホストメトリックの収集を開始するには、監視する各システムにコレクターをインストールし、次の行をコレクター構成に追加する必要があります。

 processors: resourcedetection: detectors: [env, system] cumulativetodelta: receivers: hostmetrics: collection_interval: 10s scrapers: # CPU utilization metrics cpu: # Disk I/O metrics disk: # File System utilization metrics filesystem: # CPU load metrics load: # Memory utilization metrics memory: # Network interface I/O metrics & TCP connection metrics network: # Paging/Swap space utilization and I/O metrics paging: service: pipelines: metrics: receivers: [otlp, hostmetrics] processors: [cumulativetodelta, batch, resourcedetection] exporters: [otlp/uptrace]

ファイルシステムメトリック

珍しいファイルシステムを使用している場合は、ファイルシステムレシーバーをより徹底的に構成することをお勧めします。たとえば、サポートされているファイルシステムタイプのみをクロールし、警告を避けてください。

 receivers: hostmetrics: collection_interval: 10s scrapers: cpu: disk: load: filesystem: include_fs_types: match_type: strict fs_types: [ext3, ext4] memory: network: paging:

プロセスメトリック

各プロセスのCPU、メモリ、およびディスクI/Oメトリックを収集するには、それぞれのクローラーを有効にする必要があります。

 receivers: hostmetrics: collection_interval: 10s scrapers: # Process count metrics process: # Per process CPU, Memory, and Disk I/O metrics processes:

これらのクローラーは、他のプロセスから情報にアクセスするために、より高い権限を持つオペンテレメトリーコレクターを実行する必要があるため、デフォルトで無効にされています。

Linuxでは、Otelcol-ContribをRootで実行できます。

 # /lib/systemd/system/otelcol-contrib.service User=root Group=root

または、sudoを使用してプロセスを開始します。

 # /lib/systemd/system/otelcol-contrib.service ExecStart=sudo /usr/bin/otelcol-contrib $OTELCOL_OPTIONS

コンテナホストメトリック

Linuxでは、OpenteleMetryがLinux Systemディレクトリからメトリックを収集します。コンテナではなくホストシステムに関するメトリックを収集するには、コンテナを実行するときにホストファイルシステムをマウントできます。

 # mount the entire filesystem docker run -v /:/hostfs ... # or mount only parts you need docker run -v /proc:/hostfs/proc ...

次に、root_pathを構成して、Hostmetricsレシーバーがrootファイルシステムの場所を把握できるようにします。

 receivers: hostmetrics: root_path: /hostfs

参照

• https://opentelemetry.io/
• https://uptrace.dev/opentelemetry/
• Reactフロントエンドアプリケーション（SIGNOZ/K8S）でOpentelemetryクラウドネイティブの観測性をすばやく練習する