オープンテレメトリ (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 Collector を使用する主な利点は何ですか?
主な利点はベンダー中立のアプローチであり、組織はアプリケーションを再インストルメント化することなくテレメトリ バックエンドを切り替えることができます。
1 つのパイプラインで複数のレシーバーを使用できますか?
はい、単一のパイプライン内で複数のレシーバーを構成して、さまざまなソースからデータを取り込み、データ収集戦略を最適化できます。
OTel Collector がシステムに合わせて拡張されることをどのように確認すればよいですか?
構成ファイルのベスト プラクティスを実装し、パフォーマンスを継続的に監視して、最も多くのリソースを使用する信号の種類に基づいて必要に応じてリソース属性を調整し、コレクターの展開がシステムに合わせて効率的に拡張されるようにします。
OTel Collector を導入する場合のセキュリティ上の考慮事項は何ですか?
転送中および保存中のデータが暗号化されていることを確認し、アクセス制御を適用してテレメトリ データのセキュリティと整合性を維持します。

私たちのブログを購読する
このような記事をあなたの受信箱に直接お届けします