オープンテレメトリ (OTEL)は、ベンダーに依存しないアプリケーションインストルメンテーション方法を提供し、顧客がテレメトリバックエンドを再度インストルメンテーションすることなく切り替えられるようにします。これにより、貴重なデータを その他の監視システムOpenTelemetry は、OpenTelemetry SDK、OpenTelemetry API、OpenTelemetry Collector で構成されています。このアプローチにより、監視システムの柔軟性と標準化が保証されます。
この記事では、OTel とそのアーキテクチャ (レシーバー、プロセッサ、エクスポーター、拡張機能、サービス構成) について説明します。また、組織のニーズを満たすために OTel Collector を展開および維持するのに役立つ重要なプラクティスについても学習します。
主要な取り組み
OpenTelemetryコレクターを理解する
OpenTelemetryのコアコンポーネントであるOTelコレクターは、計測アプリケーションとテレメトリバックエンド間のパイプラインコンポーネントとして導入されます。OTelコレクターを使用すると、テレメトリ信号が複数の形式で取り込まれ、OTelネイティブのデータ形式に変換され、バックエンドネイティブの形式にエクスポートされます。これらは、 可観測性のXNUMX本の柱 (メトリック、ログ、トレース)。API のトレースが最も成熟しており、メトリックとログは開発のさまざまな段階にあります。
OTEL Collector は、ベンダー中立の可観測性を組織に提供し、あらゆるテレメトリ バックエンドとのシームレスな統合を可能にします。
OTel Collectorアーキテクチャの主要コンポーネント
当学校区の OpenTelemetryコレクター レシーバー、プロセッサ、エクスポーターの 3 つの主要コンポーネントで構成されます。これらのコレクター コンポーネントは、テレメトリ パイプラインの構築に使用されます。
受信機: テレメトリデータの収集
レシーバーは、コレクターにデータを転送する役割を担います。レシーバーはプッシュベースまたはプルベースにすることができます。レシーバーは指定された形式でデータを受け取り、それを内部形式に変換してから、該当するパイプラインで定義されたバッチ プロセッサとエクスポーターに渡します。サポートされるトレース データまたはメトリックの形式は、レシーバーによって異なります。
プロセッサ: データの変換と強化
プロセッサは、データをエクスポータに送信する前に、メトリックを変換し、スパンの名前を変更します。また、送信前にデータをバッチ処理し、エクスポートが失敗した場合に再試行し、メタデータと末尾ベースのサンプリングを追加します。プロセッサが構成される順序によって、データ処理のシーケンスが決まります。
エクスポーター: バックエンドへのデータの送信
エクスポーターの役割は、処理済みのテレメトリ データを、オープンソースと商用の両方のさまざまな可観測性バックエンドにエクスポートすることです。エクスポーターは、さまざまな可観測性プラットフォームとのシームレスな統合をサポートし、互換性のある形式で可観測性データが目的の宛先に確実に届くようにします。
拡張機能: コレクター機能の強化
拡張機能は、テレメトリ データに直接アクセスせずに、OTel コレクターにオプションの機能を追加します。これらは主に OTel コレクターの管理と監視に使用され、コレクターのコア機能のオプションの拡張機能を提供します。
サービス構成: コンポーネントの有効化
OTel Collectorのサービスセクションでは、定義されたレシーバー、プロセッサー、エクスポーター、および拡張機能セクション内で構成されたコンポーネントを有効にします。このセクションには、レシーバー、プロセッサー、およびエクスポーターのセットで構成されるトレース、メトリック、およびログの拡張機能とパイプラインのリストが含まれています。詳細については、 OpenTelemetryコレクタープロセッサの構成 LM OTELコレクターのログ記録.
設定例
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
exporters:
otlp:
endpoint: otelcol:4317
extensions:
health_check:
pprof:
zpages:
service:
extensions: [health_check,pprof,zpages]
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlp]OTel Collector の実装に関するベスト プラクティス
- 適切な構成を確認してください: コレクターが効果的に機能するには、各コンポーネント (レシーバー、プロセッサ、エクスポーター) が正しく構成され、パイプラインに含まれている必要があります。 バリデータを使用する 適切な構成を確保するのに役立ちます。
- 拡張機能を賢く活用しましょう: 拡張機能はオプションですが、コレクターの機能を大幅に強化し、貴重な監視および管理機能を提供できます。
- 複数のパイプラインを活用する: 異なるタイプのテレメトリ データを処理するために、固有の構成を持つ複数のパイプラインを定義します。プロセッサはパイプラインごとに表されますが、レシーバーとエクスポーターはパイプライン間でコレクター インスタンスを共有します。
- データ処理を最適化: プロセッサの順序、バッチ処理、サンプリング戦略、キャッシュ、およびデータ変換とエンリッチメントのプロセスを最適化する構成を最適化することが重要です。
- スケーラビリティと柔軟性: OTelコレクターの構成 システムの拡張に伴って増加するデータ負荷を処理することで、効率とパフォーマンスを維持するのに役立ちます。
ベスト プラクティスを実装することで、ユーザーは OTEL Collector のパフォーマンス、スケーラビリティ、セキュリティを最適化し、その監視可能性を最大限に高めることができます。
LogicMonitorのOpenTelemetryコレクター
LogicMonitor は、計測されたアプリケーションから LogicMonitor プラットフォームにトレースを転送するように事前構成された、OTel Collector のカスタマイズされたバージョンを提供します。LogicMonitor の集中管理機能により、ユーザーとプロバイダーはトラブルシューティングをほとんど行わずに、観測可能性戦略を合理化できます。
LogicMonitorとの統合の詳細については、 LogicMonitor用OpenTelemetryコレクターの概要.
よくある質問
当学校区の OTELコレクター テレメトリデータを受信、処理、エクスポートする独立したプロセスです。一方、SDKはアプリケーション内に常駐し、テレメトリデータを生成してコレクターまたはバックエンドに直接送信する役割を担います。
はい、 オープンテレメトリ Collectorは、ローカライズされた制御のためのサイドカー(アプリまたはサービスごと)として、または複数のソースからテレメトリを収集するための集中型サービスとして導入できます。どちらを選択するかは、お客様の可観測性戦略とインフラストラクチャの規模によって異なります。
はい。 テレメトリパイプライン 少なくとも 1 つのレシーバー (データを取り込むため)、1 つのプロセッサ (オプションですが、バッチ処理やサンプリングには推奨)、および 1 つのエクスポーター (バックエンドにデータを送信するため) が必要です。
もし 受信機 正しく設定されていないか、パイプラインにリストされていない場合、コレクターはそのソースからデータを取り込みません。テレメトリ取り込みにおけるサイレントエラーを回避するために、必ず設定を検証してください。
LogicMonitorは、事前設定された オープンテレメトリ セットアップの複雑さを軽減し、ユーザーがインフラストラクチャの配管ではなく観測可能性に集中できるようにすることで、トレースをプラットフォームに自動的にルーティングするコレクター。
© LogicMonitor 2025 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。