Kubernetesの高度な設定 🔗

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

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

制御プレーン設定を上書きする 🔗

agent.controlPlaneMetrics 構成セクションで制御プレーンのメトリクス・レシーバーのいずれかがアクティブになっている場合、Helm チャートは、アクティブになったレシーバーを使用して制御プレーンからメトリクスを収集するように Collector を構成します。

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

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

可用性と設定手順 🔗

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

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

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

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

各制御プレーンレシーバーの設定オプションとサポートされるメトリクスについては、以下のドキュメントを参照してください：

CoreDNS。
etcd サーバー。etcd メトリクスを取得するには、etcd メトリクスの設定を参照してください。
Kubernetes コントローラーマネージャー。
Kubernetes API サーバー。
Kubernetes プロキシ。
Kubernetes スケジューラー。

Known issue 🔗

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

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

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

制御プレーンへの接続に使用されるデフォルトの設定値をオーバーライドすることができます。制御プレーンが非標準ポートまたはカスタム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

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

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

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

agent:
  securityContext:
    runAsUser: 20000
    runAsGroup: 20000

注釈

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

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

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

eBPF Helm チャートのインストールと設定については、eBPF Helmチャートをインストールするを参照してください。

注釈

Helm チャートのバージョン 0.88 以降、Splunk OpenTelemetry Collector Helm チャートの networkExplorer 設定は非推奨です。 networkExplorer 設定から eBPF Helm チャートへの移行方法については、networkExplorerからeBPF Helmチャートへの移行を参照してください。

前提条件 🔗

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

This page was last updated on 2024年04月16日.

Related Topics

Kubernetesの高度な設定 🔗

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

制御プレーン設定を上書きする 🔗

可用性と設定手順 🔗

Known issue 🔗

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

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

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

前提条件 🔗

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

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

メトリクスの再活性化 🔗

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

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

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

設定例 🔗

ログ 🔗

メトリクス 🔗

トレース 🔗

永続キューのサポート 🔗

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

ゲートウェイサポート 🔗

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

Was this topic useful?

Splunk

Related Topics

Kubernetesの高度な設定 🔗

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

制御プレーン設定を上書きする 🔗

可用性と設定手順 🔗

Known issue 🔗

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

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

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

前提条件 🔗

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

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

メトリクスの再活性化 🔗

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

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

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

設定例 🔗

ログ 🔗

メトリクス 🔗

トレース 🔗

永続キューのサポート 🔗

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

ゲートウェイサポート 🔗

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

Was this topic useful?

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