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:
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
の分布と同様に機能するが、次のような違いがあります:
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
totrue
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コンテナが指定された自己監視のためにこのノードラベルを追加できるようにします。
- FargateノードはVMバウンダリーを使用して他のPodが使用するホストベースのリソースへのアクセスを防ぐため、Podは自分のkubeletに到達することができません。Fargateディストリビューションのクラスター・レシーバーには、この制限を回避するために、通常の
クラスター名の設定 🔗
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 Platformazure
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