Docs » Splunk Distribution of the OpenTelemetry Collector の利用開始 » Collector for Kubernetesを使い始める » Kubernetesの高度な設定

Kubernetesの高度な設定 🔗

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

Helmチャートの基本設定については、Helmで Collector for Kubernetes を設定する を参照してください。ログの設定については、Collector for Kubernetes のログとイベントを収集する を参照してください。

注釈

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

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

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

デフォルトの設定を上書きして、独自の設定を使用することができます。これを行うには、values.yamlファイルの agent.config、clusterReceiver.config、または gateway.config パラメータを使用してカスタム設定を含めます。values.yaml、、agent、cluster receiver および gateway に例があります。

例：

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 。

制御プレーンメトリクスを設定する 🔗

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

Helmチャートは各ノードのCollectorを使用して、実行時に制御プレーンレシーバーを表すレシーバークリエーターを使用します。レシーバークリエーターには、どのコントロールプレーンレシーバーを作成するかを知るための一連の検出ルールがあります。デフォルトの検出ルールは、Kubernetesディストリビューションとバージョンによって異なる場合があります。詳細は レシーバークリエーターレシーバー を参照してください 。

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

対応バージョン 🔗

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

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

対応

未対応

  • Kubernetes

  • OpenShift

  • AKS

  • EKS

  • EKS/Fargate

  • GKE

  • GKE/Autopilot

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

アベイラビリティ 🔗

以下のコンポーネントは、制御プレーンメトリクスの設定を提供しています：

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

制御プレーンへの接続に使用されるデフォルトの設定値をオーバーライドすることができます。制御プレーンが非標準ポートまたはカスタム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レシーバーによる制御プレーンメトリクスのためのすぐに使えるダッシュボードとナビゲーターはまだサポートされていませんが、将来のリリースではサポートされる予定です。

詳細は、Prometheusレシーバー を参照してください。

既知の問題 🔗

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

  1. kopsクラスター仕様で kubeProxy.metricsBindAddress: 0.0.0.0 を設定します。

  2. 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 機能リクエストの問題 を参照してください。

カスタムTLS証明書を設定する 🔗

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. Splunk Helmチャートにシークレットをマウントする 🔗

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

  • agent.extraVolumes、agent.extraVolumeMounts

  • clusterReceiver.extraVolumes、clusterReceiver.extraVolumeMounts

  • gateway.extraVolumes、gateway.extraVolumeMounts

Helmコンポーネントの詳細については、Helmチャートアーキテクチャーとコンポーネント を参照してください。

例：

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設定をオーバーライドする 🔗

エージェントの 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を使用したネットワークテレメトリの収集 🔗

ネットワークメトリクスを収集し、Network ExplorerでOpenTelemetry eBPF Helmチャートを使用して分析できます。詳細については、Network Explorer の概要 を参照してください。eBPF Helmチャートのインストールと設定については、eBPF Helmチャートをインストールする を参照してください。

注釈

Helmチャートのバージョン0.88以降、Splunk OpenTelemetry Collector Helmチャートの networkExplorer 設定は非推奨です。Network Explorerを引き続き使用してSplunk Observability Cloudでデータを確認したい場合は、networkExplorerからeBPF Helmチャートへの移行 で説明されているように、アップストリームのeBPF Helmチャートをゲートウェイとして実行されているOpenTelemetry Collectorに向けます。

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を追加できます：

  1. 以下のコマンドを実行して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

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

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

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

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 を参照してください。

注釈

Data can only be persisted for agent DaemonSets.

設定例 🔗

ログ、メトリクス、トレースのデータ永続化を無効にするには、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イベントには適用されていません。

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