Kubernetesの高度な設定 🔗

以下のCollector for Kubernetesの高度な設定オプションを参照してください。

Helmチャートの基本設定については、Helmで Collector for Kubernetes を設定するを参照してください。ログの設定については、Collect logs and events with the Collector for Kubernetes を参照してください。

注釈

values.yaml ファイルには、Helm チャートでサポートされているすべての設定可能なパラメータと、各パラメータの詳細な説明が記載されています。:strong:` このチャートの設定方法を理解するために、このファイルを見てください`。

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

デフォルト設定を上書きする 🔗

デフォルトの設定を上書きして、独自の設定を使用することができます。これを行うには、values.yamlファイルの agent.config、clusterReceiver.config、または gateway.config パラメータを使用してカスタム設定を含めます。values.yaml、エージェント、クラスターレシーバー、ゲートウェイに例があります。

例：

agent:
  config:
    processors:
      # Exclude logs from pods named 'podNameX'
      filter/exclude_logs_from_pod:
        logs:
          exclude:
            match_type: regexp
            resource_attributes:
              - key: k8s.pod.name
                value: '^(podNameX)$'
    # Define the logs pipeline with the default values as well as your new processor component
    service:
      pipelines:
        logs:
          processors:
            - memory_limiter
            - k8sattributes
            - filter/logs
            - batch
            - resourcedetection
            - resource
            - resource/logs
            - filter/exclude_logs_from_pod

このカスタム設定は、デフォルトのエージェント設定にマージされます。

注意

ファイルをマージした後、コンフィギュレーションの一部を完全に再定義する必要があります。例えば、service 、pipelines 、logs 、processors 。

Configure control plane metrics 🔗

制御プレーンメトリクスは、以下のコンポーネントで使用できます： coredns、etcd、kube-controller-manager、kubernetes-apiserver、kubernetes-proxy、kubernetes-scheduler。Collector Helmエージェントを使用して、agent.controlPlaneMetrics.{otel_component} を true に設定することで、特定のコンポーネントから制御プレーンメトリクスを取得できます。

The Helm chart uses the Collector on each node to use the receiver creator to represent control plane receivers at runtime. The receiver creator has a set of discovery rules that know which control plane receivers to create. The default discovery rules can vary depending on the Kubernetes distribution and version. See レシーバークリエーターレシーバー for more information.

コントロールプレーンが非標準の仕様を使用している場合は、Collector が正常に接続できるようにカスタム設定を提供できます。

対応バージョン 🔗

Collectorは、制御プレーンポッドからメトリクスを収集するために、ポッドレベルのネットワークアクセスに依存しています。ほとんどのクラウドKubernetes as a Serviceディストリビューションはエンドユーザーにコントロールプレーンポッドを公開していないため、これらのディストリビューションからのメトリクスの収集はサポートされていません。

次の表は、どのKubernetesディストリビューションが制御プレーンメトリクスの収集をサポートしているかを示しています：

対応	未対応
Kubernetes OpenShift	AKS EKS EKS/Fargate GKE GKE/Autopilot

制御プレーンのレシーバーのデフォルト設定については、エージェントテンプレートを参照してください。

Availability 🔗

The following components provide control plane metrics:

非標準の制御プレーンコンポーネントにカスタム設定を使用します。 🔗

制御プレーンへの接続に使用されるデフォルトの設定値をオーバーライドすることができます。制御プレーンが非標準ポートまたはカスタムTLS設定を使用している場合は、デフォルトの設定をオーバーライドする必要があります。

以下の例は、/etc/myapiserver/ディレクトリに格納された、メトリクスとカスタムTLS証明書のためにポート 3443 を使用する非標準APIサーバーに接続する方法を示しています。

agent:
  config:
    receivers:
      receiver_creator:
        receivers:
          # Template for overriding the discovery rule and configuration.
          # smartagent/{control_plane_receiver}:
          #   rule: {rule_value}
          #   config:
          #     {config_value}
          smartagent/kubernetes-apiserver:
            rule: type == "port" && port == 3443 && pod.labels["k8s-app"] == "kube-apiserver"
            config:
              clientCertPath: /etc/myapiserver/clients-ca.crt
              clientKeyPath: /etc/myapiserver/clients-ca.key
              skipVerify: true
              useHTTPS: true
              useServiceAccount: false

PrometheusレシーバーでKubernetesの制御プレーンメトリクスを有効にする 🔗

代わりに、OpenTelemetry Prometheusレシーバーで制御プレーンメトリクスを有効にするには、機能フラグ useControlPlaneMetricsHistogramData を使用します：

featureGates:
  useControlPlaneMetricsHistogramData: true

注釈

Prometheusレシーバーによる制御プレーンメトリクスのためのすぐに使えるダッシュボードとナビゲーターはまだサポートされていませんが、将来のリリースではサポートされる予定です。

To learn more see Prometheusレシーバー.

Known issues 🔗

Kubernetesプロキシの制御プレーンレシーバーには既知の制限があります。kopsを使用して作成されたKubernetesクラスターを使用する場合、ネットワーク接続の問題によりプロキシメトリクスが収集されません。この制限は、kopsクラスター仕様のkubeProxyメトリクスバインドアドレスを更新することで対処できます：

kopsクラスター仕様で kubeProxy.metricsBindAddress: 0.0.0.0 を設定します。
kops update cluster {cluster_name} と kops rolling-update cluster {cluster_name} を実行し、変更をデプロイします。

コンテナを非 root ユーザーモードで実行します。 🔗

ログを収集するには、多くの場合、root ユーザーが所有するログファイルを読む必要があります。デフォルトでは、コンテナは securityContext.runAsUser = 0 で実行され、root ユーザーにこれらのファイルを読む権限が与えられています。

コンテナを non-root ユーザーモードで実行するには、agent.securityContext を使用して、ログデータのアクセス許可を securityContext の設定に合わせて調整します。例：

agent:
  securityContext:
    runAsUser: 20000
    runAsGroup: 20000

注釈

非 root モードでのログ収集のためのコレクターエージェントの実行は、現時点では CRI-O および OpenShift 環境ではサポートされていません。詳細については、関連の GitHub 機能リクエストの問題を参照してください。

Configure custom TLS certificates 🔗

Collectorとの安全な通信にカスタムTLS証明書が必要な場合は、以下の手順に従ってください：

1.ルートCA証明書、TLS証明書、秘密鍵ファイルを含むKubernetesシークレットを作成します。 🔗

カスタムCA証明書、キー、および証明書ファイルを、Splunk Helmチャートと同じ名前空間のKubernetesシークレットに保存します。

例えば、このコマンドを実行できます：

kubectl create secret generic my-custom-tls --from-file=ca.crt=/path/to/custom_ca.crt --from-file=apiserver.key=/path/to/custom_key.key --from-file=apiserver.crt=/path/to/custom_cert.crt -n <namespace>

注釈

このシークレットは、Splunk Helmチャートのデプロイには含まれておらず、外部で管理する責任があります。

2. Mount the secret in the Splunk Helm Chart 🔗

以下のHelmの値を使用して、この設定を agent、clusterReceiver、または gateway に適用します：

agent.extraVolumes、agent.extraVolumeMounts
clusterReceiver.extraVolumes、clusterReceiver.extraVolumeMounts
gateway.extraVolumes、gateway.extraVolumeMounts

Learn more about Helm components at Helm chart architecture and components.

例：

agent:
  extraVolumes:
    - name: custom-tls
      secret:
        secretName: my-custom-tls
  extraVolumeMounts:
    - name: custom-tls
      mountPath: /etc/ssl/certs/
      readOnly: true

clusterReceiver:
  extraVolumes:
    - name: custom-tls
      secret:
        secretName: my-custom-tls
  extraVolumeMounts:
    - name: custom-tls
      mountPath: /etc/ssl/certs/
      readOnly: true

gateway:
  extraVolumes:
    - name: custom-tls
      secret:
        secretName: my-custom-tls
  extraVolumeMounts:
    - name: custom-tls
      mountPath: /etc/ssl/certs/
      readOnly: true

3. Override your TLS configuration 🔗

エージェントの kubeletstatsreceiver など、特定のCollectorコンポーネントのTLS構成を更新して、マウントされた証明書、キー、およびCAファイルを使用します。

例：

agent:
  config:
    receivers:
      kubeletstats:
        auth_type: "tls"
        ca_file: "/etc/ssl/certs/custom_ca.crt"
        key_file: "/etc/ssl/certs/custom_key.key"
        cert_file: "/etc/ssl/certs/custom_cert.crt"
        insecure_skip_verify: true

注釈

証明書のチェックをスキップするには、コンポーネントごとにセキュアTLSチェックを無効にすることができます。このオプションは、セキュリティ標準のため、本番環境では推奨されません。

eBPFを使用したネットワークテレメトリの収集 🔗

You can collect network metrics and analyze them in Network Explorer using the OpenTelemetry eBPF Helm chart. See Network Explorer の概要 for more information. To install and configure the eBPF Helm chart, see eBPF Helmチャートをインストールする.

注釈

Starting from version 0.88 of the Helm chart, the networkExplorer setting of the Splunk OpenTelemetry Collector Helm chart is deprecated. If you wish to continue using Network Explorer to see data in Splunk Observability Cloud, point the upstream eBPF Helm chart to the OpenTelemetry Collector running as a gateway as explained in networkExplorerからeBPF Helmチャートへの移行.

Splunk Observability CloudはNetwork Explorerナビゲーターを完全にサポートしていますが、アップストリームのOpenTelemetry eBPF HelmチャートはSplunk公式サポートの対象外です。このチャートの機能アップデート、セキュリティ、バグフィックスは、いかなるSLAにも拘束されません。

前提条件 🔗

OpenTelemetryのeBPF Helmチャートが必要です：

Kubernetes 1.24以上
Helm 3.9以上

ネットワークメトリクス収集は、Linuxホスト上の以下のKubernetesベースの環境でのみサポートされています：

Red Hat Linux 7.6以上
Ubuntu 16.04以上
Debian Stretch以上
Amazon Linux 2
Google COS

レデューサーのフットプリントを変更する 🔗

レデューサーは、Kubernetesクラスターごとに単一のポッドです。クラスターに多数のポッド、ノード、サービスが含まれている場合は、割り当てられるリソースを増やすことができます。

レデューサーはテレメトリを複数のステージで処理し、各ステージは1つ以上のシャードに分割され、各シャードは独立したスレッドです。各ステージのシャードの数を増やすと、レデューサーの容量が拡大します。ステージは3つあります：インジェスト、マッチング、アグリゲーション。各ステージに1～32のシャードを設定できます。デフォルトでは、レデューサーのステージごとに1つのシャードがあります。

以下の例では、レデューサーがステージごとに4つのシャードを使用するように設定しています：

reducer:
  ingestShards: 4
  matchingShards: 4
  aggregationShards: 4

eBPFが生成するネットワークテレメトリのカスタマイズ 🔗

Helmチャートの設定から、個別に、またはカテゴリ全体で、メトリクスを無効にできます。カテゴリとメトリクスの完全なリストは values.yaml を参照してください。

カテゴリ全体を非アクティブにするには、カテゴリ名の後に .all を続けます：

reducer:
  disableMetrics:
    - tcp.all

個々のメトリクスをその名前で非アクティブにします：

reducer:
  disableMetrics:
    - tcp.bytes

カテゴリと名前を混在させることができます。例えば、すべてのHTTPメトリクスと udp.bytes メトリクスをオフにするには、次のようにします：

reducer:
  disableMetrics:
    - http.all
    - udp.bytes

メトリクスの再活性化 🔗

以前に非アクティブにしたメトリクスをアクティブにするには、enableMetrics を使用します。

enableMetrics の前に disableMetrics フラグが評価されるので、カテゴリ全体を非アクティブにしてから、そのカテゴリの中で関心のある個々のメトリクスを再びアクティブにすることができます。

例えば、すべての内部およびhttpメトリクススを無効にし、ebpf_net.collector_health を維持するには、次のようにします：

reducer:
  disableMetrics:
    - http.all
    - ebpf_net.all
  enableMetrics:
    - ebpf_net.collector_health

ゲートを使用して機能を構成する 🔗

agent.featureGates、clusterReceiver.featureGates、gateway.featureGates configs を使用して、それぞれ otel-collector エージェント、clusterReceiver、ゲートウェイの機能を有効または無効にします。これらのコンフィグは、otelcolバイナリのスタートアップ引数 -feature-gates に入力するために使用されます。

例えば、エージェントで feature1 をアクティブにし、clusterReceiver で feature2 をアクティブにし、ゲートウェイで feature2 を非アクティブにするには、以下を実行します：

helm install {name} --set agent.featureGates=+feature1 --set clusterReceiver.featureGates=feature2 --set gateway.featureGates=-feature2 {other_flags}

ポッドセキュリティポリシーを手動で設定する 🔗

Pod Security Policies（PSP）のサポートはKubernetes 1.25で削除されました。古いクラスターでまだPSPに依存している場合は、手動でPSPを追加できます：

以下のコマンドを実行してPSPをインストールします。必要であれば、--namespace kubectl 引数を追加することを忘れないでください：

cat <<EOF | kubectl apply -f -
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: splunk-otel-collector-psp
  labels:
    app: splunk-otel-collector-psp
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'runtime/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'runtime/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
spec:
  privileged: false
  allowPrivilegeEscalation: false
  hostNetwork: true
  hostIPC: false
  hostPID: false
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'hostPath'
  - 'secret'
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
EOF

以下のカスタムClusterRoleルールをvalues.yamlファイルに、clusterName 、splunkObservability 、splunkPlatform のような他のすべての必須フィールドと一緒に追加します：

rbac:
  customRules:
    - apiGroups:     [extensions]
      resources:     [podsecuritypolicies]
      verbs:         [use]
      resourceNames: [splunk-otel-collector-psp]

ヘルムチャートを取り付けます：

helm install my-splunk-otel-collector -f my_values.yaml splunk-otel-collector-chart/splunk-otel-collector

データ永続化キューを設定する 🔗

何も設定しなければ、データはメモリ上にのみキューイングされます。データが送信できない場合、デフォルトでは最大5分間、数回再試行され、その後ドロップされます。何らかの理由でこの間にCollectorが再起動されると、キューに入れられたデータは破棄されます。

Collectorが再起動したときにキューをディスクに永続化したい場合は、splunkPlatform.sendingQueue.persistentQueue.enabled=true を設定して、ログ、メトリクス、およびトレースのサポートを有効にします。

デフォルトでは、データは /var/addon/splunk/exporter_queue ディレクトリに永続化されます。このパスを上書きするには、splunkPlatform.sendingQueue.persistentQueue.storagePath オプションを使用します。

詳しい説明は、OpenTelemetry Collector のData Persistence を参照してください。

注釈

データを永続化できるのは、エージェントデーモンセットだけです。

設定例 🔗

ログ、メトリクス、トレースのデータ永続化を無効にするには、values.yamlで以下を使用します：

ログ 🔗

agent:
  config:
    exporters:
        splunk_hec/platform_logs:
          sending_queue:
            storage: null

メトリクス 🔗

agent:
  config:
    exporters:
      splunk_hec/platform_metrics:
        sending_queue:
          storage: null

トレース 🔗

agent:
  config:
    exporters:
      splunk_hec/platform_traces:
        sending_queue:
          storage: null

永続キューのサポート 🔗

以下のサポートを提供します：

`GKE/Autopilot` および `EKS/Fargate` のサポート 🔗

永続的バッファリングは、GKE/Autopilot および EKS/Fargate ではサポートされていません。これは、ディレクトリを hostPath 経由でマウントする必要があるためです。

また、GKE/Autopilot と EKS/Fargate は、Splunk Observability Cloud が基盤となるインフラストラクチャを管理していないため、ボリュームマウントを許可していません。

詳細は aws/fargate および gke/autopilot を参照してください。

ゲートウェイサポート 🔗

filestorageエクステンションがキューディレクトリの排他ロックを取得します。

ポッドのレプリカが複数ある場合、持続的バッファリングを実行することはできません。たとえサポートを提供できたとしても、ロックを取得して実行できるのは1つのポッドだけで、他のポッドはブロックされて操作できなくなります。

クラスターレシーバーのサポート 🔗

クラスターレシーバーはOpenTelemetry Collectorの1レプリカのデプロイメントです。Kubernetes制御プレーンは、クラスターレシーバーポッドを実行するために利用可能な任意のノードを選択できるため（ポッドを特定のノードに固定するように clusterReceiver.nodeSelector が明示的に設定されていない限り）、hostPath または local ボリュームマウントはこのような環境では機能しません。

データの永続化は現在、KubernetesクラスターメトリクスとKubernetesイベントには適用されていません。

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

Related Topics

Kubernetesの高度な設定 🔗

デフォルト設定を上書きする 🔗

Configure control plane metrics 🔗

対応バージョン 🔗

Availability 🔗

非標準の制御プレーンコンポーネントにカスタム設定を使用します。 🔗

PrometheusレシーバーでKubernetesの制御プレーンメトリクスを有効にする 🔗

Known issues 🔗

コンテナを非 root ユーザーモードで実行します。 🔗

Configure custom TLS certificates 🔗

1.ルートCA証明書、TLS証明書、秘密鍵ファイルを含むKubernetesシークレットを作成します。 🔗

2. Mount the secret in the Splunk Helm Chart 🔗

3. Override your TLS configuration 🔗

eBPFを使用したネットワークテレメトリの収集 🔗

前提条件 🔗

レデューサーのフットプリントを変更する 🔗

eBPFが生成するネットワークテレメトリのカスタマイズ 🔗

メトリクスの再活性化 🔗

ゲートを使用して機能を構成する 🔗

ポッドセキュリティポリシーを手動で設定する 🔗

データ永続化キューを設定する 🔗

設定例 🔗

ログ 🔗

メトリクス 🔗

トレース 🔗

永続キューのサポート 🔗

`GKE/Autopilot` および `EKS/Fargate` のサポート 🔗

ゲートウェイサポート 🔗

クラスターレシーバーのサポート 🔗

Was this topic useful?

Splunk

Related Topics

Kubernetesの高度な設定 🔗

デフォルト設定を上書きする 🔗

Configure control plane metrics 🔗

対応バージョン 🔗

Availability 🔗

非標準の制御プレーンコンポーネントにカスタム設定を使用します。 🔗

PrometheusレシーバーでKubernetesの制御プレーンメトリクスを有効にする 🔗

Known issues 🔗

コンテナを非 root ユーザーモードで実行します。 🔗

Configure custom TLS certificates 🔗

1.ルートCA証明書、TLS証明書、秘密鍵ファイルを含むKubernetesシークレットを作成します。 🔗

2. Mount the secret in the Splunk Helm Chart 🔗

3. Override your TLS configuration 🔗

eBPFを使用したネットワークテレメトリの収集 🔗

前提条件 🔗

レデューサーのフットプリントを変更する 🔗

eBPFが生成するネットワークテレメトリのカスタマイズ 🔗

メトリクスの再活性化 🔗

ゲートを使用して機能を構成する 🔗

ポッドセキュリティポリシーを手動で設定する 🔗

データ永続化キューを設定する 🔗

設定例 🔗

ログ 🔗

メトリクス 🔗

トレース 🔗

永続キューのサポート 🔗

GKE/Autopilot および EKS/Fargate のサポート 🔗

ゲートウェイサポート 🔗

クラスターレシーバーのサポート 🔗

Was this topic useful?

`GKE/Autopilot` および `EKS/Fargate` のサポート 🔗