Helmで Collector for Kubernetes を設定する 🔗

Collector for Kubernetes をインストールした後、構成可能な設定は以下のとおりです。さらに、高度な設定オプションおよび Kubernetesのログとイベントを設定するも参照してください。

注意

values.yaml ファイルは、Helm チャートコンポーネントでサポートされているすべての設定可能なパラメータを一覧表示し、説明しています。詳細については、Helm chart architecture and components を参照してください。このチャートの設定方法を理解するために、このファイルを確認してください。

Helmチャートは、トレースサンプリングやプロキシサーバー経由でのデータ送信など、さまざまなユースケースをサポートするように設定することもできます。詳しくはチャート設定の例を参照してください。

Kubernetesディストリビューションを設定する 🔗

該当する場合は、distribution パラメータを使用して、基盤となる Kubernetes デプロイメントに関する情報を提供します。このパラメータにより、コネクタは追加のメタデータを自動的にスクレイピングできます。以下のオプションがサポートされています：

Azure AKS 用 aks
Amazon EKS用 eks
Amazon EKS (Fargate プロファイルあり) 用 eks/fargate
Google GKE または標準モード用 gke
Google GKE またはオートパイロットモード用 gke/autopilot
Red Hat OpenShift 用 openshift

以下を適用してディストリビューションを設定してください：

# aks deployment
--set distribution=aks,cloudProvider=azure

# eks deployment
--set distribution=eks,cloudProvider=aws

# eks/fargate deployment (with recommended gateway)
--set distribution=eks/fargate,gateway.enabled=true,cloudProvider=aws

# gke deployment
--set distribution=gke,cloudProvider=gcp

# gke/autopilot deployment
--set distribution=gke/autopilot,cloudProvider=gcp

# openshift deployment (openshift can run on multiple cloud providers, so cloudProvider is excluded here)
--set distribution=openshift

例：

splunkObservability:
  accessToken: xxxxxx
  realm: us0
clusterName: my-k8s-cluster
distribution: gke

Google Kubernetes Engineを設定する 🔗

GKE オートパイロットを設定する 🔗

Collector を GKE オートパイロットモードで実行するには、distribution オプションを gke/autopilot に設定します：

distribution: gke/autopilot

詳細については、Google Cloud ドキュメントサイトで「Autopilot overview」を検索してください。

注釈

GKE Autopilotは、ネイティブのOpenTelemetryログ収集をサポートしていません。

Collectorエージェント・デーモンセットで、Autopilotモードでのスケジューリングに問題が発生することがあります。このような場合は、デーモンセットに高い優先度クラスを割り当てて、デーモンセットのポッドが各ノードに常に存在するようにします：

Collector エージェントに新しい優先クラスを作成します：

cat <<EOF | kubectl apply -f -
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: splunk-otel-agent-priority
value: 1000000
globalDefault: false
description: "Higher priority class for the Splunk Distribution of OpenTelemetry Collector pods."
EOF

作成した優先度クラスをhelm install/upgradeコマンドで --set="priorityClassName=splunk-otel-agent-priority" 引数を使用して使用するか、カスタムvalues.yamlに以下の行を追加します：

priorityClassName: splunk-otel-agent-priority

GKE ARM サポート 🔗

Helmチャートのデフォルト設定は、GKE上のARMワークロードをサポートしています。ディストリビューション値を gke に設定してください：

distribution: gke

Amazon Elastic Kubernetes Service Fargateを設定する 🔗

Amazon EKSでFargateプロファイルを使用してCollectorを実行するには、次の例に示すように、必要な distribution 値を eks/fargate に設定します：

distribution: eks/fargate

注釈

FluentdとネイティブのOpenTelemetryログ収集は、Fargateプロファイルを持つEKSでは自動的に設定されません。

この分布は、eks の分布と同様に機能するが、次のような違いがあります：

Fargateはデーモンセットをサポートしていないため、Collectorエージェントのデーモンセットは適用されません。エージェントとして実行するCollectorインスタンスは、カスタムデプロイメントのサイドカーコンテナとして手動で設定する必要があります。これには、Fluentdのようなアプリケーション・ロギング・サービスも含まれます。gateway.enabled を true に設定し、メトリクス、トレース、およびログをゲートウェイ <installed-chart-name>-splunk-otel-collector サービスアドレスに報告するように、インストルメンテーションされたアプリケーションを構成します。デーモンセットとして実行するエージェントインスタンスは、ポッド内のサイドカーコンテナとして実行します。
FargateノードはVMバウンダリーを使用して他のPodが使用するホストベースのリソースへのアクセスを防ぐため、Podは自分のkubeletに到達することができません。Fargateディストリビューションのクラスター・レシーバーには、この制限を回避するために、通常の eks との主な違いが2つあります：
- 構成されたクラスターレシーバーは、Deploymentの代わりに2レプリカのStatefulSetとしてデプロイされ、Kubernetes Observerエクステンションを使用して、クラスターのノードと、2つ目のレプリカで、ユーザー設定可能なレシーバークリエーターの追加のためにそのポッドを検出します。このオブザーバーを使用すると、観測されたすべてのFargateノードのキューブレットメトリクスをレポートするKubelet Statsレシーバーインスタンスが動的に作成されます。最初のレプリカは、k8s_cluster レシーバーでクラスターを監視し、2 番目のクラスターは、（EKS/Fargate ネットワーキングの制限により）自分自身を除くすべての kubelet を監視します。
- 最初のレプリカのCollectorは、2番目のレプリカのkubeletを監視します。これはFargate固有の splunk-otel-eks-fargate-kubeletstats-receiver-node ノードラベルによって可能になります。eks/fargate のCollector ClusterRoleは、デフォルトのAPIグループの nodes リソースで patch 動詞を許可し、クラスターレシーバーのinitコンテナが指定された自己監視のためにこのノードラベルを追加できるようにします。

クラスター名の設定 🔗

Kubernetesクラスターの名前を指定するには、clusterName パラメータを使用します。このパラメータは、eks、eks/fargate、gke、gke/autopilot のディストリビューションではオプションですが、その他のディストリビューションでは必須です。

以下を適用してクラスター名を設定します：

--set clusterName=my-k8s-cluster

例：

clusterName: my-k8s-cluster

デプロイ環境を設定する 🔗

該当する場合は、environment パラメータを使用して、すべてのテレメトリデータに追加する追加の deployment.environment 属性を指定します。この属性は、Splunk Observability Cloud ユーザーが異なるソースからのデータを個別に調査するのに役立ちます。値の例としては、development 、staging 、production などがあります。

splunkObservability:
  accessToken: xxxxxx
  realm: us0
environment: production

クラウドプロバイダーを設定する 🔗

該当する場合は、cloudProvider パラメータを使用して、クラウドプロバイダに関する情報を提供します。以下のオプションがサポートされています：

aws アマゾンウェブサービス
gcp for Google Cloud Platform
azure for Microsoft Azure

クラウド・プロバイダーを設定し、リソース検出プロセッサーに cloud.platform を構成するには、次を使用します：

--set cloudProvider={azure|gcp|eks|openshift}

例：

splunkObservability:
  accessToken: xxxxxx
  realm: us0
clusterName: my-k8s-cluster
cloudProvider: aws

設定にその他のコンポーネントを追加する 🔗

追加の OTel コンポーネント、インテグレーション、またはレガシーモニターを使用するには、設定ファイルの関連セクションに追加します。要件によっては、設定の agent または clusterReceiver コンポーネントセクションに追加します。詳細については、Helm chart architecture and components を参照してください。

利用可能なコンポーネントの全リストと設定方法については、Collector コンポーネントを参照してください。利用可能なアプリケーション統合のリストについては、Splunk Observability Cloud でサポートされているインテグレーションを参照してください。

データ収集方法: エージェントかクラスターレシーバーか？ 🔗

次の表を読んで、データを収集するためにどのオプションを選ぶかを決めます：

	Collector エージェント経由で収集する	Collector クラスターレシーバー経由で収集する
データはどこで収集されますか？	ノードレベルで。	Kubernetes のサービスレベルで、単一のポイントを通じて。
メリット	粒度：このオプションにより、クラスターのパフォーマンスと健全性の全体像を確実に把握できます。フォールトトレランス：ノードが孤立したり問題が発生したりしても、そのノードのメトリクスは独立して収集されます。これにより、個々のノードに影響する問題を可視化できます。	簡潔さ：このオプションは、セットアップと管理を簡素化します。
考慮事項	複雑さ：各ノードでエージェントを管理設定することは、特にエージェント設定ファイルの管理など、運用の複雑さを増す可能性があります。	不完全なデータ：このオプションを選択すると、クラスターの健全性とパフォーマンスが部分的に表示される場合があります。サービスがノードのサブセットからのみメトリクスを収集する場合、クラスターの一部から重要なメトリクスを見逃す可能性があります。
ユースケース	各ノードの操作に関する詳細な洞察が必要な環境で使用します。これにより、より良い問題診断とパフォーマンスの最適化が可能になります。複数のノードで実行可能な複数のレプリカを持つアプリケーションポッドからメトリクスを収集する場合に使用します。	運用のシンプルさが優先される環境や、クラスターがすでにシンプルでノードが 1つしかない場合に使用します。

例: MySQLレシーバーを追加する 🔗

この例では、MySQL レシーバーを設定ファイルに追加する方法を示します。

`agent` セクションに MySQL レシーバーを追加する 🔗

Collector エージェントデーモンセットを使用して、エージェントがデプロイされているすべてのノードから mysql メトリクスを収集するには、次の設定を追加します：

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 を追加します。 🔗

Collector エージェントのデーモンセットで RabbitMQ モニターを有効にする場合は、設定ファイルのエージェントセクションの receivers セクションに mysql を追加します：

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

エージェントのホストネットワークの使用を設定する 🔗

デフォルトでは、agent.hostNetwork は、true に設定されています。これにより、エージェントのDaemonSetポッドがノードのホストネットワークにアクセスできるようになり、特定の要素を監視できるようになります。ホストネットワークアクセスを必要とする特定の制御プレーンコンポーネントとインテグレーションを監視するには、この設定を有効にします。

ホストのネットワークアクセスをオフにするには、agent.hostNetwork を false に設定します。これは、特定の組織のセキュリティポリシーに準拠するために必要な場合があります。ホストネットワークアクセスを無効にすると、エージェントの監視機能が制限される場合があります。

Windowsではこの値は無視されます。

AlwaysOn Profilingの有効化 🔗

Splunk APM の AlwaysOn Profiling は、スタックトレースを継続的にキャプチャし、コードのパフォーマンスボトルネックや問題を特定するのに役立ちます。プロファイリングを有効にすると、Kubernetes アプリケーションがこのデータを生成し、Splunk Observability Cloud に転送して可視化できるようになります。

Collectorは、logs パイプラインを使用してプロファイリングデータをインジェストします。

Learn more at Discover telemetry sources automatically and Splunk APMのAlwaysOn Profilingの概要.

プロファイリングのセットアップ 🔗

UIウィザードを使用して Collector for Kubernetes をインストールする際、または設定ファイルを変更することで、プロファイリングを有効にできます。

プロファイリングには2つの主要コンポーネントが使用されます: プロファイリングデータの受信と Splunk Observability Cloud へのエクスポートを担当する Collector と、プロファイリングデータとともにトレースを生成および出力できるようにアプリケーションを自動インストルメンテーションする Operator です。

主に2つのシナリオがあります：

CollectorとOperatorの両方を使用したプロファイリング：Operatorはアプリケーションを自動インストルメンテーションし、プロファイリングデータをCollectorに送信します。
Collectorのみを使用したプロファイリング：アプリケーションを手動でインストルメンテーションしてプロファイリングデータを生成し、Collectorに直接送信します。

Collectorとオペレーターでプロファイリングを有効にする 🔗

CollectorとOperatorでプロファイリングを有効にするには、UIで Profiling オプションを有効にするか、次の設定でHelmチャートをデプロイします：

Collectorの場合：

splunkObservability:
  accessToken: CHANGEME
  realm: us0
  logsEnabled: true
  profilingEnabled: true

オペレーターのために

operator:
  enabled: true

さらに、Cert-Managerをまだ導入していない場合は、オペレーターに導入します。

certmanager:
  enabled: true

以上のような設定により：

Collectorはプロファイリングデータを受信するように設定されています。
Operatorはデプロイされ、ターゲットポッドのアノテーションに基づいてアプリケーションを自動インストルメンテーションし、これらのアプリケーションがプロファイリングデータを生成できるようにします。

Collectorでのみプロファイリングを有効にする 🔗

Collectorのみを使用し、アプリケーションを手動でインストルメンテーションする場合は、splunkObservability.logsEnabled=true および splunkObservability.profilingEnabled=true が設定されていることを確認してください。

注意

このオプションを使用すると、インストルメンテーションされたアプリケーションを手動でセットアップして、プロファイリングデータをCollectorに直接送信する必要があります。

トークンをシークレットとして提供する 🔗

トークンを設定ファイルにクリアテキストとして持つ代わりに、チャートをデプロイする前に作成されたシークレットとして提供することができます。必要なフィールドは secret-splunk.yaml を参照してください。

secret:
  create: false
  name: your-secret

テレメトリ・ソースの追加 🔗

追加のテレメトリ・ソースを有効にするには、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

Collectorでディスカバリーモードを有効にします。 🔗

Splunk Distribution of OpenTelemetry Collector の検出モードを使用してメトリクスソースを検出し、その結果に基づいて設定を作成します。

Helm チャートでディスカバリーモードを有効にする方法については、Deploy the Collector with automatic discovery を参照してください。

特定の種類のテレメトリを無効にする 🔗

デフォルトでは、OpenTelemetry はメトリクスとトレースのみを Splunk Observability Cloud に送信し、ログのみを Splunk Platform に送信します。特定の送信先に対して、あらゆる種類のテレメトリデータ収集を有効化または無効化できます。

たとえば、以下の設定により、適切に設定されていれば、Collector は収集したすべてのテレメトリデータを Splunk Observability Cloud と Splunk Platform に送信できます：

splunkObservability:
  metricsEnabled: true
  tracesEnabled: true
  logsEnabled: true
splunkPlatform:
  metricsEnabled: true
  logsEnabled: true

Windowsワーカーノードを設定する 🔗

OpenTelemetry Collector for Kubernetes の Splunk ディストリビューションは、Windows ノードからのメトリクス、トレース、ログ (OpenTelemetry ネイティブログ収集のみを使用) の収集をサポートしています。すべての Windows イメージは quay.io/signalfx/splunk-otel-collector-windows リポジトリで入手できます。

以下の設定を使用して、WindowsワーカーノードにHelmチャートをインストールします：

isWindows: true
image:
  otelcol:
    repository: quay.io/signalfx/splunk-otel-collector-windows
logsEngine: otel
readinessProbe:
  initialDelaySeconds: 60
livenessProbe:
  initialDelaySeconds: 60

KubernetesクラスターにWindowsとLinuxの両方のワーカーノードがある場合、Helmチャートを2回インストールする必要があります。デフォルトの設定を isWindows: false に設定したインストールの1つは、Linuxノードに適用されます。values.yaml設定（前の例で示した）を使用した2つ目のインストールは、Windowsノードに適用されます。

クラスター全体のメトリクスの重複を避けるために、インストールの 1つで clusterReceiver を非アクティブにします。これを行うには、インストールの1つの構成に以下の行を追加します：

clusterReceiver:
  enabled: false

This page was last updated on 2024年04月24日.

Related Topics

Helmで Collector for Kubernetes を設定する 🔗

Kubernetesディストリビューションを設定する 🔗

Google Kubernetes Engineを設定する 🔗

GKE オートパイロットを設定する 🔗

GKE ARM サポート 🔗

Amazon Elastic Kubernetes Service Fargateを設定する 🔗

クラスター名の設定 🔗

デプロイ環境を設定する 🔗

クラウドプロバイダーを設定する 🔗

設定にその他のコンポーネントを追加する 🔗

データ収集方法: エージェントかクラスターレシーバーか？ 🔗

例: MySQLレシーバーを追加する 🔗

`agent` セクションに MySQL レシーバーを追加する 🔗

`clusterReceiver` セクションに MySQL レシーバーを追加する 🔗

例: Rabbit MQ モニターを追加する 🔗

`agent` セクションに RabbitMQ を追加します。 🔗

`clusterReceiver` セクションに RabbitMQ を追加します。 🔗

エージェントのホストネットワークの使用を設定する 🔗

AlwaysOn Profilingの有効化 🔗

プロファイリングのセットアップ 🔗

Collectorとオペレーターでプロファイリングを有効にする 🔗

Collectorでのみプロファイリングを有効にする 🔗

トークンをシークレットとして提供する 🔗

テレメトリ・ソースの追加 🔗

Collectorでディスカバリーモードを有効にします。 🔗

特定の種類のテレメトリを無効にする 🔗

Windowsワーカーノードを設定する 🔗

Was this topic useful?

Splunk

Related Topics

Helmで Collector for Kubernetes を設定する 🔗

Kubernetesディストリビューションを設定する 🔗

Google Kubernetes Engineを設定する 🔗

GKE オートパイロットを設定する 🔗

GKE ARM サポート 🔗

Amazon Elastic Kubernetes Service Fargateを設定する 🔗

クラスター名の設定 🔗

デプロイ環境を設定する 🔗

クラウドプロバイダーを設定する 🔗

設定にその他のコンポーネントを追加する 🔗

データ収集方法: エージェントかクラスターレシーバーか？ 🔗

例: MySQLレシーバーを追加する 🔗

agent セクションに MySQL レシーバーを追加する 🔗

clusterReceiver セクションに MySQL レシーバーを追加する 🔗

例: Rabbit MQ モニターを追加する 🔗

agent セクションに RabbitMQ を追加します。 🔗

clusterReceiver セクションに RabbitMQ を追加します。 🔗

エージェントのホストネットワークの使用を設定する 🔗

AlwaysOn Profilingの有効化 🔗

プロファイリングのセットアップ 🔗

Collectorとオペレーターでプロファイリングを有効にする 🔗

Collectorでのみプロファイリングを有効にする 🔗

トークンをシークレットとして提供する 🔗

テレメトリ・ソースの追加 🔗

Collectorでディスカバリーモードを有効にします。 🔗

特定の種類のテレメトリを無効にする 🔗

Windowsワーカーノードを設定する 🔗

Was this topic useful?

`agent` セクションに MySQL レシーバーを追加する 🔗

`clusterReceiver` セクションに MySQL レシーバーを追加する 🔗

`agent` セクションに RabbitMQ を追加します。 🔗

`clusterReceiver` セクションに RabbitMQ を追加します。 🔗