Helmで Collector for Kubernetes を設定する 🔗

After you’ve installed the Collector for Kubernetes, read on to learn which settings you can configure.

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ログ収集をサポートしていません。

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

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

デフォルトでは、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

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年09月26日.

Related Topics