OpenTelemetry とは何ですか?OpenTelemetry は、Cloud Native Computing Foundation (CNCF) がホストするオープンソースの可観測性フレームワークです。これは、OpenCensus プロジェクトと OpenTracing プロジェクトの統合です。トレース、メトリック、ログなど、あらゆる種類の観測可能な信号に対して単一の標準を提供することを目指しています。
OpenTelemetry は、テレメトリ データを収集してバックエンド プラットフォームに送信する方法を指定します。 OpenTelemetry は共通のデータ形式と API を提供することで、組織がさまざまな観測ツールやプラットフォームと統合してテレメトリ データを共有および再利用することを容易にします。 OpenTelemetry アーキテクチャは柔軟性、相互運用性、拡張性を促進し、開発者が特定のニーズと環境を満たす観測可能性のプラクティスを採用できるようにします。 テレメトリデータの種類OpenTelemetry はさまざまなテレメトリ データ タイプをサポートしています。
OpenTelemetry の使い方は?OpenTelemetry を使い始める最も簡単な方法は、分散トレース ツール (Jaeger/SigNoz/Uptrace) を選択し、そのドキュメントに従うことです。
用語集
OpenTelemetry アーキテクチャ概要OpenTelemetry アーキテクチャは、アプリケーションやサービスからテレメトリ データを収集、送信、処理するための標準化された方法を提供することを目的としています。これは、分散システムでの可観測性を実現するために連携して動作するいくつかの主要コンポーネントで構成されています。 写真 可観測性シグナルOpenTelemetry は、観測信号をキャプチャするための標準化された方法を提供します。
OpenTelemetry メトリックは、システムの動作を定量化するのに役立つ定量的な指標です。これらは、CPU 使用率、メモリ消費量、リクエストの待ち時間など、アプリケーションの特定の側面の現在の状態または速度に関する情報を提供します。 OpenTelemetry を使用すると、カスタム メトリックを定義して記録し、アプリケーションのパフォーマンスと健全性を監視できます。
OpenTelemetry Traces は、分散システムを介したリクエストの実行パスの詳細な記録を提供します。個々の操作とその関係のタイミング情報を取得し、リクエスト フローを理解し、ボトルネックを特定し、パフォーマンスの問題をトラブルシューティングできるようにします。 OpenTelemetry を使用すると、コードをインストルメント化して分散トレースを生成し、サービス間の相関関係を調べることができます。
OpenTelemetry ログは、アプリケーションの実行中に発生するイベントまたはメッセージのテキスト レコードです。これらは、アプリケーションの動作を理解し、問題を診断し、アクティビティを監査するのに役立ちます。 OpenTelemetry は、アプリケーションから構造化されたログをキャプチャし、コンテキスト情報でログを充実させるメカニズムを提供します。
計測ライブラリ(検出ツールプログラム)OpenTelemetry は、開発者がアプリケーションをインストルメント化し、テレメトリ データを収集するために使用できるさまざまなプログラミング言語用のライブラリを提供します。 計装の公式詳細文書
オープンテレメトリSDKOpenTelemetry SDK (ソフトウェア開発キット) は、開発者がアプリケーションをインストルメント化し、監視目的でテレメトリ データを収集できるようにするライブラリとツールのコレクションです。 Otel SDK は、OpenTelemetry をさまざまなプログラミング言語や環境に統合するための標準化された拡張可能なフレームワークを提供します。 輸出業者OpenTelemetry エクスポータは、テレメトリ データを外部システムまたはバックエンドに送信して、保存、分析、視覚化を行う役割を担います。 OpenTelemetry は、テレメトリ データをエクスポートするためのさまざまなプロトコルと形式をサポートするさまざまなエクスポーターを提供します。このようなエクスポーターを使用すると、ユーザーは OpenTelemetry を好みの監視および分析ツールとシームレスに統合できます。 OpenTelemetry プロトコルOpenTelemetry Protocol (OTLP) は、ソフトウェア システムおよびアプリケーションからテレメトリ データを収集、送信、エクスポートするためのオープン ソースのベンダー中立プロトコルです。 OTLP は、計測アプリケーションとバックエンド システム間で交換される接続形式とデータ構造を定義します。メトリック、トレース、ログのスキーマを含むテレメトリ データのエンコード形式と、ネットワーク経由でこのデータを送信するためのルールを指定します。 OTLP エクスポータを使用すると、収集されたテレメトリ データをバックエンドに転送して処理および分析することができます。 コンテキストの伝播コンテキスト伝播により、関連するコンテキスト データ (トレース ID、スパン ID、その他のメタデータなど) がアプリケーションのさまざまなサービスやコンポーネント間で一貫して伝播されることが保証されます。 OpenTelemetry はコンテキストを伝播することにより、分散型およびマイクロサービス アーキテクチャでも、さまざまなサービスやコンポーネントから収集されたテレメトリ データの関連性が維持されることを保証します。エンドツーエンドのトレースをサポートしているため、リクエストフロー、パフォーマンスのボトルネック、システムの依存関係を理解しやすくなります。 リソースリソース プロパティは、サービス、プロセス、コンテナーなどの監視対象エンティティに関するメタデータを提供するキーと値のペアです。これらは、リソースの識別に役立ち、テレメトリ データをフィルター処理およびグループ化するために使用できる追加情報を提供します。 OpenTelemetry では、テレメトリ データにリソース情報を含めることで、システムの動作をより適切に分析、視覚化、理解できるようになります。さまざまなソースからのテレメトリ データを相関させてコンテキスト化し、監視対象のアプリケーションまたはサービスのより包括的なビューを提供するのに役立ちます。 オープンテレメトリコレクターOpenTelemetry Collector は、柔軟でスケーラブルなテレメトリ データ収集および処理ソリューションを提供することで、OpenTelemetry エコシステムにおいて重要な役割を果たします。
Otel Collector は集中型の仲介者として機能し、データ収集の複雑さを簡素化し、さまざまなバックエンドやシステムとの柔軟な統合を可能にします。 OpenTelemetry バックエンドOpenTelemetry には、データを処理および分析するための特定の組み込みバックエンドまたはストレージ システムは含まれていません。対照的に、OpenTelemetry は、特定のニーズと好みに基づいてさまざまなバックエンド システムを選択し、統合する柔軟性を提供します。 バックエンド システムは、インストルメント化されたアプリケーションまたは OpenTelemetry Collector からエクスポートされたテレメトリ データを受信します。これらのシステムは、テレメトリ データを保存、分析、視覚化する役割を担います。 OpenTelemetry 分散トレース分散トレースを使用すると、リクエストがさまざまなサービスやシステムを通過する方法、各アクションのタイミング、発生したログやエラーを確認できます。 分散トレース ツールは、システムの動作を可視化し、パフォーマンスの問題を特定し、デバッグを支援し、分散アプリケーションの信頼性とスケーラビリティを確保するのに役立ちます。 OpenTelemetry トレースは、アプリケーションがユーザーの要求を満たすために連携して動作する複数の独立したサービスで構成されるマイクロサービス アーキテクチャのコンテキストで特に役立ちます。 追跡はどのように機能しますか?最新のアプリケーション、特にマイクロサービスやサーバーレス アーキテクチャに基づくアプリケーションでは、単一のユーザー要求を満たすために、さまざまなサービスが相互に連携することがよくあります。このため、パフォーマンスのボトルネックを特定し、問題を診断し、システム全体の動作を分析することが困難になります。 分散トレースは、さまざまなサービスやコンポーネントを通過する単一のユーザー要求の経路を表すトレースを作成することで、これらの課題に対処することを目的としています。各トレースは相互接続された一連のスパンで構成され、各スパンは特定のサービスまたはコンポーネント内の単一の操作またはアクティビティを表します。 リクエストがサービスに届くと、トレース コンテキストがリクエストとともに伝播されます。これには通常、リクエストにトレース ヘッダーを挿入して、下流のサービスが同じトレースに参加できるようにすることが含まれま す。 リクエストがシステムを通過すると、各サービスは独自のスパンを生成し、操作期間、メタデータ、および関連するコンテキストに関する情報を使用してトレース コンテキストを更新します。 写真 分散トレース ツールは、生成されたトレース データを使用することで、システムの動作を可視化し、パフォーマンスの問題を特定し、デバッグを支援し、分散アプリケーションの信頼性とスケーラビリティを確保します。 スパンSpan はトレース内の操作 (作業単位) を表します。スパンは、リモート プロシージャ コール (RPC)、データベース クエリ、またはインプロセス関数呼び出しになります。スパンは以下を持ちます:
トレースは、リクエストがアプリケーションを通過するパスを示すスパン ツリーです。ルート スパンはトレースの最初のスパンです。 写真 スパン名OpenTelemetry バックエンドは、スパン名といくつかのプロパティを使用して、類似のスパンをグループ化します。スパンを正しくグループ化するには、短く簡潔な名前を付けます。一意のスパン名の合計数は 1000 未満である必要があります。そうでない場合、スパン グループが多すぎて、エクスペリエンスが低下する可能性があります。 次の名前は短く、一意であり、類似のスパンをグループ化するのに役立つため、適しています。
次の名前は、変数 params と args が含まれているため、正しくありません。
スパンタイプスパンの種別は次のいずれかの値である必要があります。
ステータスコードステータス コードは、操作の成功または失敗を示します。次のいずれかの値である必要があります。
属性コンテキスト情報を記録するために、操作固有の情報を含む属性を使用してスパンに注釈を付けることができます。たとえば、HTTP エンドポイントには http.method = GET および http.route = /projects/:id が含まれる場合があります。 属性には任意の名前を付けることができますが、一般的な操作ではセマンティック属性規則を使用する必要があります。共通プロパティ キーのリストとその意味および可能な値を定義します。 イベント開始時間と任意の数のプロパティを持つイベントでスパンに注釈を付けることもできます。イベントとスパンの主な違いは、イベントには終了時間がない (したがって継続時間がない) ことです。 イベントは通常、例外、エラー、ログ、メッセージ (RPC など) を表しますが、カスタム イベントを作成することもできます。 コンテクストSpan コンテキストはさまざまなコンポーネントやサービスを通じて伝播し、Span に関する情報を伝達します。 トレース/スパン コンテキストは、リクエスト スコープのデータです。例:
スパンのコンテキストは、分散システムにおけるスパンの継続性と関連性を維持するために非常に重要です。これにより、さまざまなサービスとコンポーネントがそれぞれのスパンを正しいトレースに関連付けることができ、リクエストまたはトランザクション フローのエンドツーエンドの可視性が提供されます。 スパンのコンテキストは通常、荷物データが伝播される方法と同様に、サービス間の通信プロトコルのヘッダーまたはメタデータを使用して伝播されます。これにより、サービスがリクエストを受信したときに、スパン コンテキストを抽出し、受信したスパンを正しいトレースに関連付けることができるようになります。 コンテキスト内のデータはスパンの相関やサンプリングに使用できます。たとえば、トレース ID を使用して、どのスパンがどのトレースに属しているかを知ることができます。 コンテキストの伝播コンテキスト伝播により、トレース ID、スパン ID、その他のメタデータなどの関連するコンテキスト データが、アプリケーションのさまざまなサービスやコンポーネント間で一貫して伝播されることが保証されます。 OpenTemetry は、プロセス内の関数間 (プロセス内伝播) や、あるサービスから別のサービス間 (分散伝播) にコンテキストを伝播します。 プロセス内伝播は、使用されるプログラミング言語に応じて、暗黙的または明示的に行うことができます。暗黙的な伝播は、アクティビティ コンテキストをスレッド ローカル変数 (Java、Python、Ruby、NodeJS) に保存することによって自動的に実行されます。明示的な伝播では、アクティビティ コンテキストをパラメーターとして 1 つの関数から別の関数に明示的に渡す必要があります (Go)。 分散コンテキスト伝播のために、OpenTelemetry はコンテキスト データをシリアル化して渡す方法を定義するいくつかのプロトコルをサポートしています。
https://www.w3.org/TR/trace-context/
W3C トレース コンテキストは、デフォルトで有効になっている推奨プロパゲータです。 手荷物Baggage は span context と同様に動作し、カスタムのキーと値のペア (属性) を 1 つのサービスから別のサービスに伝播できます。 gRPC の世界には、gRPC メタデータと呼ばれる同様の概念があります。
Baggage を使用すると、キーと値のペアをリクエストまたはトランザクションに関連付けることができます。これらのキーと値のペアは、ユーザー ID、セッション ID、その他のアプリケーション固有のメタデータなど、リクエストまたはトランザクションに関連する可能性のあるコンテキスト情報を表します。 Baggage は、分散システム全体でコンテキスト情報を維持および相関させるのに役立ち、アプリケーションの動作の観察と分析を向上させます。アドホックなメカニズムや手動の計測に頼ることなく、システム全体に関連データを渡す標準化された方法を提供します。 計測を優先すべき場合計装の公式詳細文書
トレース機能を最大限に活用するために、すべてのアクションをログに記録する必要はありません。これにはかなりの時間がかかる可能性があり、通常は必要ありません。次のアクションを優先します。
OpenTelemetry メトリクスOpenTelemetry Metrics は、メトリックを収集、集約し、Uptrace や Prometheus などの OpenTelemetry APM ツールに送信する方法の標準です。 OpenTelemetry は、新しい標準を定義すると同時に、Prometheus や Statsd などの既存のメトリック ツール プロトコルとの連携にも取り組んでいます。さらに、OpenTelemetry Collector は、AWS Metrics、InfluxDB、Chrony など、さらに多くのプロトコルをサポートしています。 OpenTelemetry を使用すると、例を通じてメトリックとトレースを相関させることもできるため、システムの状態をより広範囲に把握できるようになります。 インジケーターとは何ですか?メトリックは、CPU 使用率、ネットワーク トラフィック、データベース接続など、システムの健全性とパフォーマンスを表す数値データ ポイントです。 メトリックを使用してパフォーマンスを測定、監視、比較できます。たとえば、サーバーの応答時間、メモリ使用率、エラー率などを測定できます。 楽器インストルメントは、アプリケーションの動作の特定の側面に関するデータを収集する特定のタイプのメトリック (カウンター、ゲージ、ヒストグラムなど) です。 次の機能を備えた計測器を作成して測定値を取得します。
時系列機器は複数の時系列を生成できます。時系列は、一意のプロパティ セットを持つメトリックです。たとえば、各ホストには同じメトリック名に対して個別の時系列があります。 付加的な機器加算可能または合計可能な機器は時系列を生成し、それらを加算すると、別の意味のある正確な時系列が生成されます。減少しない数値を測定する加算的な計器は単調とも呼ばれます。 たとえば、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 を使用する必要があります。
楽器を選択
値が単調な場合は、Counter を使用します。 それ以外の場合は、UpDownCounter を使用します。
カウンタ同期単調 カウンターは、加算的で減少しない値を測定する同期機器です。次に例を示します。
カウンターは、イベントの発生回数や時間の経過に伴う値の蓄積を測定するために使用されます。それらは時間の経過とともに増加するだけです。 カウンター時系列の場合、バックエンドは通常、デルタを計算してレート値を表示します。たとえば、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 時系列の場合、バックエンドは通常最後の値を表示するため、異なる時系列を一緒に追加することはできません。 メトリクスの例メールの数送信されたメールの数を測定するには、メールが送信されるたびに増加するカウンター インストルメントを作成します。 後で、次のようなプロパティを追加して詳細な統計情報を収集できます。
運用遅延操作のレイテンシを測定するには、ヒストグラム インストルメントを作成し、操作と同期して更新します。 キャッシュヒット率キャッシュヒット率を測定するには、CounterObserver を作成し、キャッシュ統計を監視します。 エラー率エラー率を直接測定するには、GaugeObserver を作成し、計算方法を気にせずに値を観察することができます。 OpenTelemetry ログOpenTelemetry Logs を使用すると、他の観測可能な信号との相関関係とより適切な統合を可能にする方法でログの記録と収集を行うことができます。 ログは、アプリケーションの動作を理解し、問題を診断し、システムの健全性を監視するために重要です。分散トレースとメトリックはシステム パフォーマンスに関する貴重な洞察を提供し、ログは特定のイベント、エラー、アプリケーションの動作に関する詳細なコンテキストと情報を提供します。 概要OpenTelemetry は主にメトリックとトレースの収集に重点を置いていますが、ログ API を介したログ収集もサポートしています。 OpenTelemetry は既存のログ記録ソリューションをサポートし、既存のログ記録ライブラリおよびログ収集ツールと適切に連携することを保証します。 OpenTelemetry は、アプリケーションを計測し、構造化されたログを生成できるログ API を提供します。 OpenTelemetry Logging API は、メトリックやトレースなどの他のテレメトリ データと連携して、統合された可観測性ソリューションを提供するように設計されています。 OpenTelemetry は構造化されたログ記録を重視しており、属性またはメタデータを通じてログ エントリに追加のコンテキスト情報を添付できます。これにより、タイムスタンプ、リクエスト ID、ユーザー ID、相関 ID、その他のカスタム コンテキストなど、ログ分析やトラブルシューティングに役立つ関連詳細を含めることができます。 さまざまな種類のログOpenTelemetry は、アプリケーションまたはシステム内のさまざまなソースからのログのキャプチャをサポートします。ログは、生成および収集方法に基づいて 3 つのカテゴリに分類できます。 システムとインフラストラクチャのログシステム ログは、システムの動作、パフォーマンス、セキュリティに関する貴重な情報を提供します。システム ログは通常、オペレーティング システム、アプリケーション、ネットワーク デバイス、サーバーなど、システム内のさまざまなコンポーネントによって生成されます。 システム ログはホスト レベルで書き込まれ、簡単に変更できない定義済みの形式と内容を持ちます。システム ログには、トレース コンテキストに関する情報は含まれません。 レガシーファーストパーティログファーストパーティ ログは内部アプリケーションによって生成され、特定のアプリケーション イベント、エラー、およびユーザー アクティビティを記録します。これらのログは、アプリケーションのデバッグやトラブルシューティングに非常に役立ちます。 通常、開発者はこれらのアプリケーションを変更して、ログの書き込み方法やログに含まれる情報を変更できます。たとえば、ログとトレースを関連付けるには、開発者は各ログ ステートメントにトレース コンテキストを手動で追加するか、ログ ライブラリのプラグインを使用して自動的に追加することができます。 たとえば、コンテキストを伝播し、ログ記録をスパンに関連付けるには、ログ メッセージで次の属性を使用できます。
例えば: 新しいファーストパーティログ新しいプロジェクトを開始するときは、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プロパティを確認する必要があります。 サンプラーは、作成されるルートスパンを受け入れる関数です。この関数はサンプリング決定を返します。
デフォルトでは、Opentelemetryはすべてのトレースをサンプリングしますが、トレースのサブセットをサンプリングするように構成できます。この場合、バックエンドは確率的サンプリングを使用してスパン数を調整します。 Opentelemetryサンプラー常にトレースをサンプリングします。つまり、リクエストごとに新しいトレースが開始され、エクスポートされます。 AlwaysOffサンプラーは、トレースをサンプリングしません。つまり、すべてのトレースを削除します。このサンプラーを使用して、ロードテストを実行したり、トレースを一時的に無効にしたりできます。 TraceIDRATiobasedサンプラーは、トレースIDを使用して、トレースの20%などのトレースのごく一部をサンプリングします。 親ベースのサンプラーは、スパンの親要素に応じて異なる動作をする複合サンプラーです。新しいトレースを開始すると、サンプラーはそれをサンプリングするかどうかを決定し、その決定を他のサービスに伝播します。 レート制限サンプリングレート制限サンプリングはサーバー側で発生し、特定の制限を超えないようにします。たとえば、10枚以下のトラックを毎秒サンプリングできます。 速度制限サンプリングは調整カウントをサポートしますが、精度は低くなります。より良い結果を得てパフォーマンスを向上させるには、より効率的で正確なヘッドベースのサンプリングで速度制限サンプリングを使用する必要があります。 ほとんどのバックエンドは、必要に応じて速度制限サンプリングを自動的に適用します。 テールサンプリングに基づいていますヘッドサンプリングに基づくサンプリングでは、サンプリングの決定は事前に行われ、通常はランダムです。この情報は追跡の最後にのみ取得できるため、ヘッドベースのサンプリングは失敗または異常に長い操作をサンプリングすることはできません。 テールベースのサンプリングを使用して、追跡されたすべてのスパンが利用可能になるまでサンプリングの決定を遅らせ、追跡されたすべてのデータに基づいてより良いサンプリング決定になります。たとえば、失敗または異常に長いトレースをサンプリングできます。 ほとんどのOpentelemetryバックエンドは、必要に応じてテールベースのサンプリングを自動的に適用しますが、OpentelemetryコレクターとTailSamplingProcessorを使用して、ニーズに応じてサンプリングを構成することもできます。 確率ベースのサンプリング確率ベースのサンプリングは、構成された確率またはサンプリングレートに基づいて記録されるトラックのサブセットをランダムに選択します。たとえば、サンプリングレートを10%に設定できます。つまり、トレースの10%のみが記録され、残りが廃棄されます。 確率ベースのサンプリングは、システム動作の代表的なサンプルを維持しながら追跡されたデータの量を減らしたい場合に役立ちます。オーバーヘッドと必要な観測可能性レベルのバランスをとるのに役立ちます。 Uptraceに基づいて、Opentelemetry Goで確率ベースのサンプラーを構成する方法を次に示します。 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-ContribOpentelemetry Collectorには、Githubに2つのリポジトリがあります。
Otelcol-Contribは、コアと同じくらい安定しており、より多くの機能をサポートするため、常にインストールして使用する必要があります。 インストールOpentelemetryコレクターは、Linux、MacOS、およびWindowsの事前コンパイルされたバイナリを配布します。 リナックスOtelcol-Contribバイナリと関連するSystemDサービスをインストールするには、次のコマンドを実行して、0.82.0を必要なバージョンに、AMD64を必要なスキーマに置き換えます。 デビアン
RPM 次のコマンドを使用して、インストールされたサービスのステータスを確認できます。 次のコマンドでログを確認してください。 /etc/otelcol-contrib/config.yamlで構成を編集できます。 Opentelemetryコレクターを再起動します。 ソースコードからコンパイルしますOpentelemetryコレクターをローカルにコンパイルすることもできます。 構成Opentelemetry Collectorは高度に構成可能であるため、動作をカスタマイズして観測可能性スタックに統合できます。入力、プロセッサ、輸出業者を指定するための構成オプションを提供し、特定のニーズに合わせてエージェントをカスタマイズできるようにします。 デフォルトでは、/etc/otelcol-contrib/config.yamlで構成ファイルを見つけることができます。たとえば(Uptrace): Otel Collectorの詳細については、公式ドキュメントをご覧ください。
トラブルシューティングOtelcolが期待どおりに機能していない場合は、ログ出力の潜在的な問題を確認できます。冗長ロギングのレベルはデフォルトで情報ですが、構成ファイルを使用して変更できます。 潜在的な問題のログを表示します。 また、メトリックがOpentelemetryコレクターを監視できるようにすることもできます。 拡張機能拡張機能は、Opentelemetryコレクターに追加の機能を提供し、テレメトリーデータへの直接アクセスを必要としません。たとえば、ヘルスチェック拡張はヘルスチェックリクエストに応答します。 リソース検出ホストからリソース情報を検出するために、Otel Collectorには独自のResourcedEtectionプロセッサが付属しています。
リソース検出プロセッサは、データ生成環境に関するメタデータを自動的に検出およびタグ付けします。このメタデータは「リソース」と呼ばれ、テレメトリデータのコンテキストを提供します。これには、ホスト、サービス、コンテナ、クラウドプロバイダーなどの情報が含まれます。 たとえば、host.nameおよびos.typeプロパティを検出するには、システム検出器を使用できます。 IPアドレスなどのカスタムプロパティを追加するには、ENV変数とENV検出器を使用できます。 より多くの情報を検出するには、より専門的な検出器を使用できます。たとえば、Amazon EC2を使用している場合、EC2検出器を使用してCloud.RegionとCloud.Abailability_Zoneプロパティを発見できます。 Google Cloudを使用している場合: Dockerを使用している場合: Heroku、Azure、Consul、および他の多くの検出器の公式ドキュメントをご覧ください。
メモリリミッターMemoryLimiterProcessorは、テレメトリデータを処理するときにOpentelemetryコレクターによって消費されるメモリの量をユーザーが制限できるコンポーネントです。これにより、コレクターがあまりにも多くのメモリを使用することを防ぎ、パフォーマンスの問題を引き起こしたりクラッシュしたりする可能性があります。
メモリ限定プロセッサは、Opentelemetryコレクターによって消費されるメモリの量を定期的にチェックし、ユーザー定義のメモリ制限と比較することで機能します。コレクターがメモリを使用して指定された制限を超えた場合、プロセッサはメモリの使用量が制限を下回るまでテレメトリデータの破棄を開始します。 メモリリミッターを有効にするには: OpentelemetryホストメトリックHostmetricsReceiverは、CPU、RAM、ディスクメトリック、その他のシステムレベルメトリックなどのホストシステムに関するさまざまなメトリックを収集するOpentelemetry Collectorプラグインです。
ホストメトリックを収集および分析することにより、ホストシステムのパフォーマンスと健康に関する洞察を得て、アプリケーションとサービスの全体的なパフォーマンスに影響を与える可能性のある潜在的な問題またはボトルネックを特定できます。 ホストメトリックホストメトリックの収集を開始するには、監視する各システムにコレクターをインストールし、次の行をコレクター構成に追加する必要があります。 ファイルシステムメトリック珍しいファイルシステムを使用している場合は、ファイルシステムレシーバーをより徹底的に構成することをお勧めします。たとえば、サポートされているファイルシステムタイプのみをクロールし、警告を避けてください。 プロセスメトリック各プロセスのCPU、メモリ、およびディスクI/Oメトリックを収集するには、それぞれのクローラーを有効にする必要があります。 これらのクローラーは、他のプロセスから情報にアクセスするために、より高い権限を持つオペンテレメトリーコレクターを実行する必要があるため、デフォルトで無効にされています。 Linuxでは、Otelcol-ContribをRootで実行できます。 または、sudoを使用してプロセスを開始します。 コンテナホストメトリックLinuxでは、OpenteleMetryがLinux Systemディレクトリからメトリックを収集します。コンテナではなくホストシステムに関するメトリックを収集するには、コンテナを実行するときにホストファイルシステムをマウントできます。 次に、root_pathを構成して、Hostmetricsレシーバーがrootファイルシステムの場所を把握できるようにします。 参照
|
>>: 従来のITシステムを使用したクラウド移行の障害を克服する方法
ドメイン名とウェブサイトのランキング ドメイン名の登録は、検索エンジンのランキングにおいて最も重要な...
この調査の結果、人工知能と機械学習、クラウドコンピューティング、5Gテクノロジーが2022年に影響を...
uanode は 2009 年に登録されたウクライナの会社で、ウクライナにコンピューター ルームを持...
「クラウド化」がコンセンサスとなった今、クラウド上で企業ビジネスの継続性と可用性をどのように確保する...
AWS Identity and Access Management (IAM) を使用すると、AW...
著者 |デビッド・リンシカム企画 |ヤン・ジェンコードがどんなに単純であっても、上司はそれを書きませ...
VXLAN は NVO3 のネットワーク仮想化技術です。元のホストから UDP で送信されたデータ ...
bacloud は現在、すべての VPS が 12% オフとなるハロウィーン プロモーションを実施し...
ウェブサイトを構築するとき、私たちはみな、ウェブサイトをもっと良くしたいと願っています。要件がどんど...
実際、racknerd は、シアトル、ダラス、シカゴ、アトランタ、ニューヨーク、アッシュバーンの 6...
[[419727]]詳細については、以下をご覧ください。 51CTOとHuaweiが共同で構築したH...
IDCは2020年上半期の中国ローカルコンピューティングクラウド端末市場に関するデータを公開し、レノ...
業界のキーワードをランク付けするためにフォーラムを運営し始めるウェブマスターが増えていますが、多...
昼食後、同僚は全員出かけました。私はオフィスで一人、ホットなニュースを読んでいました。「馬鋼舎」を使...
編集者注/ C2B(顧客対企業)モデルは、アリババグループの参謀長である曽明氏によって初めて提案され...