HelmでCollector for Kubernetesを設定します：コンポーネントとデータソースを追加する 🔗
Read on to learn how to add additional components or data sources to your Collector for Kubernetes config. To create new receivers at runtime see レシーバークリエーターレシーバー.
その他の設定オプションについては、こちらを参照してください：
Collector for Kubernetesの設定方法の実用的な例は、チュートリアル：Kubernetes上でのSplunk Distribution of OpenTelemetry Collectorの設定 を参照してください。
設定にその他のコンポーネントを追加する 🔗
追加のOTelコンポーネント、インテグレーション、またはレガシーモニターを使用するには、設定ファイルの関連セクションに追加します。要件によっては、values.yamlの agent.config または clusterReceiver.config セクションに含めることもできます。詳細については、Helmチャートアーキテクチャーとコンポーネント を参照してください。
利用可能なコンポーネントの全リストと設定方法については、Collector コンポーネント を参照してください。利用可能なアプリケーション統合のリストについては、Splunk Observability Cloud でサポートされているインテグレーション を参照してください。
データ収集方法: エージェントかクラスターレシーバーか？ 🔗
次の表を読んで、データを収集するためにどのオプションを選ぶかを決めます：
Collector エージェント経由で収集する |
Collector クラスターレシーバー経由で収集する |
|
|---|---|---|
データはどこで収集されますか？ |
ノードレベルで。 |
Kubernetes のサービスレベルで、単一のポイントを通じて。 |
メリット |
|
簡潔さ：このオプションは、セットアップと管理を簡素化します。 |
考慮事項 |
複雑さ：各ノードでエージェントを管理設定することは、特にエージェント設定ファイルの管理など、運用の複雑さを増す可能性があります。 |
不完全なデータ：このオプションを選択すると、クラスターの健全性とパフォーマンスが部分的に表示される場合があります。サービスがノードのサブセットからのみメトリクスを収集する場合、クラスターの一部から重要なメトリクスを見逃す可能性があります。 |
ユースケース |
|
運用のシンプルさが優先される環境や、クラスターがすでにシンプルでノードが 1つしかない場合に使用します。 |
例: MySQLレシーバーを追加する 🔗
この例では、MySQL レシーバー を設定ファイルに追加する方法を示します。
agent セクションに MySQL レシーバーを追加する 🔗
To use the Collector agent DaemonSet to collect mysql metrics from every node the agent is deployed to, add this to your configuration:
agent:
config:
receivers:
mysql:
endpoint: localhost:3306
...
clusterReceiver セクションに MySQL レシーバーを追加する 🔗
Collector クラスターレシーバのデプロイを使用して、単一のエンドポイントから mysql メトリクスを収集するには、これを設定に追加します：
clusterReceiver:
config:
receivers:
mysql:
endpoint: mysql-k8s-service:3306
...
例: Rabbit MQ モニターを追加する 🔗
この例では、RabbitMQ のインテグレーションを設定ファイルに追加する方法を示します。
agent セクションに RabbitMQ を追加します。 🔗
If you want to activate the RabbitMQ monitor in the Collector agent DaemonSet, add mysql to the receivers section of your agent section in the configuration file:
agent:
config:
receivers:
smartagent/rabbitmq:
type: collectd/rabbitmq
host: localhost
port: 5672
username: otel
password: ${env:RABBITMQ_PASSWORD}
次に、設定ファイルの service セクションの metrics パイプラインに、レシーバーを含めます：
service:
pipelines:
metrics:
receivers:
- smartagent/rabbitmq
clusterReceiver セクションに RabbitMQ を追加します。 🔗
同様に、クラスターレシーバーで RabbitMQ モニターを有効にしたい場合は、設定ファイルのクラスターレシーバーセクションの receivers セクションに mysql を追加します：
clusterReceiver:
config:
receivers:
smartagent/rabbitmq:
type: collectd/rabbitmq
host: rabbitmq-service
port: 5672
username: otel
password: ${env:RABBITMQ_PASSWORD}
次に、設定ファイルの service セクションの metrics パイプラインに、レシーバーを含めます：
service:
pipelines:
metrics:
receivers:
- smartagent/rabbitmq
Collectorでディスカバリーモードを有効にします。 🔗
Splunk Distribution of OpenTelemetry Collector の検出モードを使用してメトリクスソースを検出し、その結果に基づいて設定を作成します。
Helm チャートでディスカバリーモードを有効にする方法については、自動ディスカバリーによるCollectorのデプロイ を参照してください。
テレメトリ・ソースの追加 🔗
追加のテレメトリ・ソースを有効にするには、autodetect 設定オプションを使用します。
一般的な Prometheus スタイルのアノテーションを持つポッドから、Collector に Prometheus メトリクスをスクレイピングさせたい場合は、autodetect.prometheus=true を設定します。以下のアノテーションをポッドに追加して、スクレイピング処理を細かく制御できるようにします：
prometheus.io/scrape: true: デフォルトの設定はすべてのポッドをスクレイピングします。falseに設定すると、このアノテーションはスクレイピング処理からポッドを除外します。prometheus.io/path: メトリクスを取得するパス。デフォルト値は/metricsです。prometheus.io/port: メトリクスをスクレイピングするポート。デフォルト値は9090です。
CollectorがIstio環境で実行されている場合は、autodetect.istio=true を Istioによって報告されるすべてのトレース、メトリクス、およびログが統一された方法で収集されるように設定します。
例えば、以下の設定を使用して、Prometheus と Istio の両方のテレメトリ・ソースの自動検出を有効にします：
splunkObservability:
accessToken: xxxxxx
realm: us0
clusterName: my-k8s-cluster
autodetect:
istio: true
prometheus: true
特定の種類のテレメトリを無効にする 🔗
デフォルトでは、OpenTelemetry はメトリクスとトレースのみを Splunk Observability Cloud に送信し、ログのみを Splunk Platform に送信します。特定の送信先に対して、あらゆる種類のテレメトリデータ収集を有効化または無効化できます。
たとえば、以下の設定により、適切に設定されていれば、Collector は収集したすべてのテレメトリデータを Splunk Observability Cloud と Splunk Platform に送信できます：
splunkObservability:
metricsEnabled: true
tracesEnabled: true
logsEnabled: true
splunkPlatform:
metricsEnabled: true
logsEnabled: true