Kubernetesの高度な設定 🔗

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

Helmチャートの基本設定については、Helmで Collector for Kubernetes を設定するを参照してください。ログの設定については、Collect logs and events for 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 🔗

Control plane metrics are available for the following components: coredns, etcd, kube-controller-manager, kubernetes-apiserver, kubernetes-proxy, and kubernetes-scheduler. You can use the Collector Helm agent to obtain control plane metrics from a specific component by setting agent.controlPlaneMetrics.{otel_component} to 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

Activate Kubernetes control plane metrics with the Prometheus receiver 🔗

To activate control plane metrics with the OpenTelemetry Prometheus receiver instead, use the feature flag useControlPlaneMetricsHistogramData:

featureGates:
  useControlPlaneMetricsHistogramData: true

注釈

Out-of-the-box dashboards and navigators for control plane metrics with the Prometheus receiver aren’t supported yet, but are planned for a future release.

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 🔗

If your organization requires custom TLS certificates for secure communication with the Collector, follow these steps:

1. Create a Kubernetes secret containing the Root CA certificate, TLS certificate, and private key files 🔗

Store your custom CA certificate, key, and cert files in a Kubernetes secret in the same namespace as the your Splunk Helm chart.

For example, you can run this command:

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>

注釈

You are responsible for externally managing this secret, which is not part of the Splunk Helm chart deployment.

2. Mount the secret in the Splunk Helm Chart 🔗

Apply this configuration to the agent, clusterReceiver, or gateway using the following Helm values:

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 🔗

Update the TLS configuration for specific Collector components, such as the agent’s kubeletstatsreceiver, to use the mounted certificate, key, and CA files.

例：

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

注釈

To skip certificate checks, you can disable secure TLS checks per component. This option is not recommended for production environments due to security standards.

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チャートへの移行.

While Splunk Observability Cloud fully supports the Network Explorer navigator, the upstream OpenTelemetry eBPF Helm chart is not covered under official Splunk support. Any feature updates, security, or bug fixes to it are not bound by any SLAs.

前提条件 🔗

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

Monitor OpenShift infrastructure nodes 🔗

By default, the Splunk Distribution of OpenTelemetry Collector for Kubernetes doesn’t collect data from OpenShift infrastructure nodes.

You can customize the Collector Helm Chart file to activate data collection from OpenShift infrastructure nodes. To do so, complete the following steps:

Open your values.yaml file for the Helm Chart.

Copy and paste the following YAML snippet into the values.yaml file:

tolerations:
  - key: node-role.kubernetes.io/master
    effect: NoSchedule
  - key: node-role.kubernetes.io/control-plane
    effect: NoSchedule
  - key: node-role.kubernetes.io/infra
    effect: NoSchedule
    operator: Exists

Install the Collector using the Helm Chart:

helm install my-splunk-otel-collector --values values.yaml splunk-otel-collector-chart/splunk-otel-collector

注釈

Monitoring OpenShift infrastructure nodes might pose a security risk depending on which method you used to create the Kubernetes environment.

This page was last updated on 2024年11月06日.

Related Topics

Kubernetesの高度な設定 🔗

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

Configure control plane metrics 🔗

対応バージョン 🔗

Availability 🔗

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

Activate Kubernetes control plane metrics with the Prometheus receiver 🔗

Known issues 🔗

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

Configure custom TLS certificates 🔗

1. Create a Kubernetes secret containing the Root CA certificate, TLS certificate, and private key files 🔗

2. Mount the secret in the Splunk Helm Chart 🔗

3. Override your TLS configuration 🔗

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

前提条件 🔗

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

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

メトリクスの再活性化 🔗

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

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

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

設定例 🔗

ログ 🔗

メトリクス 🔗

トレース 🔗

永続キューのサポート 🔗

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

ゲートウェイサポート 🔗

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

Monitor OpenShift infrastructure nodes 🔗

Was this topic useful?

Splunk

Related Topics

Kubernetesの高度な設定 🔗

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

Configure control plane metrics 🔗

対応バージョン 🔗

Availability 🔗

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

Activate Kubernetes control plane metrics with the Prometheus receiver 🔗

Known issues 🔗

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

Configure custom TLS certificates 🔗

1. Create a Kubernetes secret containing the Root CA certificate, TLS certificate, and private key files 🔗

2. Mount the secret in the Splunk Helm Chart 🔗

3. Override your TLS configuration 🔗

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

前提条件 🔗

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

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

メトリクスの再活性化 🔗

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

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

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

設定例 🔗

ログ 🔗

メトリクス 🔗

トレース 🔗

永続キューのサポート 🔗

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

ゲートウェイサポート 🔗

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

Monitor OpenShift infrastructure nodes 🔗

Was this topic useful?

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