第4章 Collector の設定
4.1. Collector の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of OpenTelemetry Operator は、Red Hat build of OpenTelemetry リソースを作成およびデプロイするときに使用されるアーキテクチャーと設定を定義するカスタムリソース定義 (CRD) ファイルを使用します。デフォルト設定をインストールすることも、ファイルを変更することもできます。
4.1.1. デプロイメントモード リンクのコピーリンクがクリップボードにコピーされました!
OpenTelemetryCollector カスタムリソースを使用すると、OpenTelemetry Collector の次のいずれかのデプロイメントモードを指定できます。
- Deployment
- デフォルトです。
- StatefulSet
- Collector の File Storage Extension または Tail Sampling Processor を使用する場合など、ステートフルワークロードを実行する必要がある場合は、StatefulSet デプロイメントモードを使用します。
- DaemonSet
- たとえば、Collector の Filelog Receiver を使用してコンテナーログを読み取るなど、すべてのノードからテレメトリーデータをスクレイプする必要がある場合は、DaemonSet デプロイメントモードを使用します。
- サイドカー
コンテナー内のログファイルにアクセスする必要がある場合は、Collector をサイドカーとして注入し、Collector の Filelog Receiver と
emptyDirなどの共有ボリュームを使用します。アプリケーションがテレメトリーデータを
localhost経由で送信するように設定する必要がある場合は、Collector をサイドカーとして注入し、暗号化かつ認証された接続を介してテレメトリーデータを外部サービスに転送するように Collector をセットアップします。サイドカーとして注入されると、Collector はアプリケーションと同じ Pod で実行されます。注記サイドカーデプロイメントモードを選択した場合は、
OpenTelemetryCollectorカスタムリソース CR でspec.mode: sidecarフィールドを設定することに加えて、Pod アノテーションまたは namespace アノテーションとしてsidecar.opentelemetry.io/injectアノテーションも設定する必要があります。このアノテーションを Pod と namespace の両方に設定すると、falseまたはOpenTelemetryCollectorCR 名のいずれかに設定されている場合は、Pod アノテーションが優先されます。Pod アノテーションとして、
sidecar.opentelemetry.io/injectアノテーションはいくつかの値をサポートしています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サポートされる値:
false- Collector を注入しません。アノテーションがない場合、これがデフォルトになります。
true-
同じ namespace 内の
OpenTelemetryCollectorCR の設定を Collector に注入します。 <collector_name>-
同じ namespace 内の
<collector_name>OpenTelemetryCollectorCR の設定を Collector に注入します。 <namespace>/<collector_name>-
<namespace>namespace 内の<collector_name>OpenTelemetryCollectorCR の設定を Collector に注入します。
4.1.2. OpenTelemetry Collector 設定オプション リンクのコピーリンクがクリップボードにコピーされました!
OpenTelemetry Collector は、テレメトリーデータにアクセスする 5 種類のコンポーネントで構成されます。
- レシーバー
- プロセッサー
- エクスポーター
- コネクター
- 拡張機能
カスタムリソース YAML ファイルで、コンポーネントのインスタンスを複数定義できます。コンポーネントは、設定した後に YAML ファイルの spec.config.service セクションで定義されたパイプラインで有効にする必要があります。ベストプラクティスとしては、必要なコンポーネントのみを有効にします。
OpenTelemetry Collector カスタムリソースファイルの例
- 1
- コンポーネントが設定されていても、
serviceセクションで定義されていない場合、そのコンポーネントは有効になりません。
| パラメーター | 説明 | 値 | デフォルト |
|---|---|---|---|
receivers:
| レシーバーは、データが Collector に到達する方法です。デフォルトでは、レシーバーは設定されていません。設定が有効とみなされるためには、少なくとも 1 つの有効なレシーバーが必要です。レシーバーは、パイプラインに追加して有効にされます。 |
| なし |
processors:
| プロセッサーは、受信したデータをエクスポートする前に処理します。デフォルトでは、プロセッサーは有効になっていません。 |
| なし |
exporters:
| エクスポーターは、1 つ以上のバックエンドまたは宛先にデータを送信します。デフォルトでは、エクスポーターは設定されていません。設定が有効とみなされるためには、少なくとも 1 つの有効なエクスポーターが必要です。エクスポーターは、パイプラインに追加して有効にされます。エクスポーターはデフォルト設定で使用できますが、多くの場合、少なくとも宛先およびセキュリティー設定を指定するための設定が必要です。 |
| None |
connectors:
| コネクターはパイプラインのペアを結合します。つまり、パイプラインの終わりのエクスポーターとしてデータを消費し、パイプラインの始まりのレシーバーとしてデータを出力します。コネクターを使用して、消費されたデータを要約、複製、またはルーティングできます。 |
| なし |
extensions:
| テレメトリーデータの処理を含まないタスク用のオプションのコンポーネント。 |
| なし |
service: pipelines:
|
コンポーネントは、それらを | ||
service:
pipelines:
traces:
receivers:
|
レシーバーは、それらを | なし | |
service:
pipelines:
traces:
processors:
|
プロセッサーは、それらを | None | |
service:
pipelines:
traces:
exporters:
|
エクスポーターは、それらを | None | |
service:
pipelines:
metrics:
receivers:
|
メトリクスのレシーバーを有効にするには、 | None | |
service:
pipelines:
metrics:
processors:
|
メトリクスのプロセッサーを有効にするには、 | None | |
service:
pipelines:
metrics:
exporters:
|
メトリクスのエクスポーターを有効にするには、 | None |
4.1.3. profile signal リンクのコピーリンクがクリップボードにコピーされました!
Profile シグナルは、コードの実行とリソース消費を監視するための新しい Telemetry データ形式です。
Profile シグナルはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
プロファイル信号を使用すると、非効率的なコードを特定機能に特定できます。このようなプロファイリングにより、コードの特定の行までパフォーマンスのボトルネックやリソースの効率を正確に特定できます。このような高速プロファイルデータをトレース、メトリック、およびログに関連付けることで、実稼働環境での包括的なパフォーマンス分析とターゲット型コードの最適化が可能になります。
プロファイリングは、アプリケーションまたはオペレーティングシステムをターゲットにできます。
- プロファイリングを使用してアプリケーションを観察すると、開発者がコードのパフォーマンスを検証し、リグレッションを防ぎ、メモリーや CPU 使用率などのリソース消費を監視し、非効率なコードを特定し、改善できます。
- プロファイリングを使用してオペレーティングシステムを監視することで、インフラストラクチャー、システムコール、カーネル操作、および I/O 待機時間に関する洞察が提供されるため、効率とコストを削減するためにインフラストラクチャーを最適化できます。
プロファイルシグナルが有効になっている OpenTelemetry Collector カスタムリソース
4.1.4. 必要な RBAC リソースの自動作成 リンクのコピーリンクがクリップボードにコピーされました!
一部の Collector コンポーネントは、RBAC リソースの設定を必要とします。
手順
Red Hat build of OpenTelemetry Operator が権限を自動的に作成できるように、
opentelemetry-operator-controller-manageサービスアカウントに次の権限を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.5. Target Allocator リンクのコピーリンクがクリップボードにコピーされました!
Target Allocator は、OpenTelemetry Operator のオプションのコンポーネントです。デプロイされた OpenTelemetry Collector インスタンスのフリート全体のスクレイプターゲットをシャード化します。Target Allocator は、Prometheus PodMonitor および ServiceMonitor カスタムリソース (CR) と統合します。Target Allocator が有効な場合、OpenTelemetry Operator が、Target Allocator サービスに接続する有効な Prometheus レシーバーに http_sd_config フィールドを追加します。
Target Allocator はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Target Allocator が有効な OpenTelemetryCollector CR の例
- 1
- Target Allocator が有効な場合、デプロイメントモードを
statefulsetに設定する必要があります。 - 2
- Target Allocator を有効にします。デフォルトは
falseです。 - 3
- Target Allocator デプロイメントのサービスアカウント名。サービスアカウントには、収集されたメトリクスにラベルを適切に設定するために、
ServiceMonitor、PodMonitorカスタムリソース、およびその他のオブジェクトをクラスターから取得するための RBAC が必要です。デフォルトのサービス名は<collector_name>-targetallocatorです。 - 4
- Prometheus
PodMonitorおよびServiceMonitorカスタムリソースとの統合を有効にします。 - 5
- Prometheus
ServiceMonitorカスタムリソースのラベルセレクター。空のままにすると、すべてのサービスモニターが有効になります。 - 6
- Prometheus
PodMonitorカスタムリソースのラベルセレクター。空のままにすると、すべての Pod モニターが有効になります。 - 7
- 最小限の空の
scrape_config: []設定オプションを指定した Prometheus Receiver。
Target Allocator デプロイメントは、Kubernetes API を使用してクラスターから関連オブジェクトを取得します。そのため、カスタム RBAC 設定が必要です。
Target Allocator のサービスアカウントの RBAC 設定