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

デフォルト設定を上書きすることで、独自設定を使用することができます。これを行うには、values.yaml ファイルの agent.config、clusterReceiver.config、または gateway.config パラメータを使用してカスタム構成を含めてください。values.yaml、agent、クラスターレシーバ、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

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

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

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

Helm チャートでは、各ノード上の Collector がレシーバクリエータを使用して、実行時にコントロールプレーンのレシーバを表現します。レシーバクリエータには、どのコントロールプレーン レシーバを作成するかを判別する検出ルールのセットがあります。デフォルトの検出ルールは、Kubernetes のディストリビューションとバージョンによって異なる場合があります。詳しくは「Receiver creator receiver」を参照してください。

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

対応バージョン

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

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

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

アベイラビリティ

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

• CoreDNS

• AWS ECSコンテナメトリクスレシーバー

• Kubernetesコントローラー・マネージャー

• Kubernetes APIサーバー

• Kubernetesプロキシ

• Kubernetesスケジューラー

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

制御プレーンへの接続に使用されるデフォルト設定値を上書きできます。制御プレーンが非標準ポートまたはカスタム 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 受信者」を参照してください。

既知の問題

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

カスタム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>

2. Splunk Helm チャートにシークレットをマウントする

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

• agent.extraVolumes、 agent.extraVolumeMounts

• clusterReceiver.extraVolumes、 clusterReceiver.extraVolumeMounts

• gateway.extraVolumes、 gateway.extraVolumeMounts

Helm コンポーネントについて、詳しくは「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. 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

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

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

前提条件

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 つのポッドです。クラスターに多数のポッド、ノード、サービスが含まれている場合は、割り当てられるリソースを増やすことができます。

レデューサはテレメトリを複数のステージで処理し、各ステージは 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 設定を使用して、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

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

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

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

   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イベントには適用されていません。