Docs » Splunk Distribution of the OpenTelemetry Collector の利用開始 » Collector for Kubernetesを使い始める » Helmで Collector for Kubernetes を設定する

Helmで Collector for Kubernetes を設定する 🔗

Collector for Kubernetes をインストールした後、どの設定を構成できるかを学ぶには、続けてお読みください。

Additionally, see:

For a practical example of how to configure the Collector for Kubernetes see Tutorial: Configure the Splunk Distribution of the OpenTelemetry Collector on 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ログ収集をサポートしていません。

The Collector agent DaemonSet can have problems scheduling in Autopilot mode. If this happens, do the following to assign the DaemonSet a higher priority class to ensure that the DaemonSet pods are always present on each node:

  1. 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

  1. 作成した優先度クラスを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 の分布と同様に機能するが、次のような違いがあります：

  • The Collector agent DaemonSet is not applied since Fargate does not support DaemonSets. Any desired Collector instances running as agents must be configured manually as sidecar containers in your custom deployments. This includes any application logging services like Fluentd. Set gateway.enabled to true and configure your instrumented applications to report metrics, traces, and logs to the gateway <installed-chart-name>-splunk-otel-collector service address. Any desired agent instances that would run as a DaemonSet should instead run as sidecar containers in your pods.

  • 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

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

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

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

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

AlwaysOn Profilingの有効化 🔗

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

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

Learn more at Automatic discovery of apps and services and Splunk APMのAlwaysOn Profilingの概要.

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

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

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

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

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

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

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

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

Collectorの場合：

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

Operatorのために

operatorcrds:
  install: true
operator:
  enabled: true

さらに、Cert-Managerをまだ導入していない場合は、Operatorに導入します。

certmanager:
  enabled: true

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

  • Collectorはプロファイリングデータを受信するように設定されています。

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

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

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

注意

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

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

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

secret:
  create: false
  name: your-secret

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

このページは 2025年02月04日 に最終更新されました。