Kubelet統計レシーバー

kubelet-stats レシーバーには、この Splunk Observability Cloud 統合を使用してください。メリット、インストール、設定、メトリクスを参照してください

Kubelet 統計レシーバーは、kubelet 上の Kubernetes API サーバーから Pod メトリクスをプルし、さらなる処理のためにメトリクスパイプラインを介してそれらのポッドメトリクスを送信します。サポートされているパイプラインのタイプは metrics です。詳細については「パイプラインでデータを処理する」を参照してください。

注: このレシーバーは、kubelet-statskubelet-metricskubernetes-volumes Smart Agent モニターに代わるものです。

はじめに

以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください:

  1. Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします:

  2. 次のセクションで説明するように、Kubelet 統計レシーバーを設定します。

  3. Collector を再起動します。

サンプル構成

Kubelet 統計レシーバーを有効にするには、設定ファイルの receivers セクションに kubeletstats を追加します:

YAML
receivers:
  kubeletstats:

設定を完了するには、設定ファイルの service セクションの metrics パイプラインに、レシーバーを含めます:

YAML
service:
  pipelines:
    metrics:
      receivers: [kubeletstats]

Kubelet 統計レシーバー接続を認証する

kubelet は Kubernetes ノードで実行され、Kubernetes 統計レシーバーが接続する API サーバーがあります。レシーバーを設定するには、接続と認証の詳細、およびデータを収集して送信する頻度を設定します。

認証には、auth_type フィールドで示されるように、2つの方法があります:

  • tls は、認証に TLS を使うようレシーバーに指示し、ca_filekey_filecert_file フィールドを要求します。詳細については、「TLS を設定する」を参照してください。

  • ServiceAccount は、kubelet API の認証にデフォルトのサービス アカウント トークンを使用するよう、このレシーバーに指示します。

TLS認証を設定する

次の例は、TLS 認証を使用して kubelet stats レシーバーを構成する方法を示しています:

YAML
receivers:
  kubeletstats:
    collection_interval: 20s
    auth_type: "tls"
    ca_file: "/path/to/ca.crt"
    key_file: "/path/to/apiserver.key"
    cert_file: "/path/to/apiserver.crt"
    endpoint: "192.168.64.1:10250"
    insecure_skip_verify: true

exporters:
  file:
    path: "fileexporter.txt"

service:
  pipelines:
    metrics:
      receivers: [kubeletstats]
      exporters: [file]

サービスアカウント認証の設定

次の例は、サービスアカウント認証で kubeletstats レシーバーを設定する方法を示しています。

  1. ポッド仕様でノード名が設定されていることを確認します:

    YAML
    env:
      - name: K8S_NODE_NAME
        valueFrom:
          fieldRef:
            fieldPath: spec.nodeName
  2. Collector をアクティブにして、K8S_NODE_NAME 環境変数を参照します:

YAML
receivers:
  kubeletstats:
    collection_interval: 20s
    auth_type: "serviceAccount"
    endpoint: "${K8S_NODE_NAME}:10250"
    insecure_skip_verify: true
exporters:
  file:
    path: "fileexporter.txt"
service:
  pipelines:
    metrics:
      receivers: [kubeletstats]
      exporters: [file]
注意: endpoint の値が欠落しているか空の場合、Collector が実行されているホスト名がエンドポイントとして使用されます。hostNetwork フラグが設定されていて、Collector が Pod で実行されている場合、ホスト名はノードのネットワーク名前空間に解決されます。

高度なユースケース

デフォルトで除外されているメトリクスを追加する

除外されたメトリクスをインポートするには、次の例のように include_metrics オプションを使用します:

YAML
exporters:
  signalfx:
    include_metrics:
      - metric_names:
          - container.memory.rss.bytes
          - container.memory.available.bytes

メタデータ属性の追加

デフォルトでは、生成されたすべてのメトリクスは、/stats/summary エンドポイントが提供する kubelet に基づくリソース属性を取得します。一部のユースケースでは、他のエンドポイントを使用して追加のメタデータエンティティを取得し、メトリクスリソースの追加属性として設定します。

Kubelet統計レシーバーは、以下のメタデータをサポートします:

  • container.id: /pods を使って公開されたコンテナのステータスから得られるコンテナIDラベルで、メトリクスメタデータを豊かにします。

  • k8s.volume.type/pods を使用して、公開された Pod 仕様からボリュームタイプを収集し、属性としてボリュームメトリクスに追加します。ボリュームタイプよりも多くのメタデータが使用可能な場合、レシーバーは使用可能なフィールドとボリュームタイプに応じてそれを同期します。たとえば、aws.volume.idawsElasticBlockStore から同期され、gcp.pd.namegcePersistentDisk から同期されます。

メトリクスに container.id ラベルを追加するには、extra_metadata_labels フィールドを設定します。例:

YAML
receivers:
  kubeletstats:
    collection_interval: 10s
    auth_type: "serviceAccount"
    endpoint: "${K8S_NODE_NAME}:10250"
    insecure_skip_verify: true
    extra_metadata_labels:
      - container.id

extra_metadata_labels が設定されていない場合、メタデータを受け取るための追加の API コールは行われません。

追加のボリューム・メタデータを収集する

永続的なボリューム要求を扱う場合、基礎となるストレージリソースからメタデータを同期できます。例:

YAML
receivers:
  kubeletstats:
    collection_interval: 10s
    auth_type: "serviceAccount"
    endpoint: "${K8S_NODE_NAME}:10250"
    insecure_skip_verify: true
    extra_metadata_labels:
      - k8s.volume.type
    k8s_api_config:
      auth_type: serviceAccount

k8s_api_config が設定されている場合、レシーバーは永続的なボリューム要求の基礎となるストレージリソースからメタデータの収集を試みます。たとえば、Pod が AWS 上の Elastic Block Store(EBS)インスタンスに裏付けされた永続的なボリューム要求を使用している場合、レシーバーは persistentVolumeClaim ではなく awsElasticBlockStorek8s.volume.type ラベルを設定します。

メトリクス・グループの設定

メトリクスグループは、コンポーネントタイプごとのメトリクスの集合です。デフォルトでは、コンテナ、Pod、ノードからメトリクスが収集されます。metric_groups が設定されている場合、リストされているグループのメトリクスのみが収集されます。有効なグループは、containerpodnodevolume です。

例えば、レシーバーからノードとポッドのメトリクスだけを収集します:

YAML
receivers:
  kubeletstats:
    collection_interval: 10s
    auth_type: "serviceAccount"
    endpoint: "${K8S_NODE_NAME}:10250"
    insecure_skip_verify: true
    metric_groups:
      - node
      - pod

オプションパラメーターの設定

また、以下のオプション・パラメーターも設定できます:

  • collection_interval、これはデータを収集する間隔です。デフォルト値は 10s です。

  • insecure_skip_verify、これはサーバー証明書チェーンとホスト名の検証を省略するかどうかを指定します。デフォルト値は false です。

設定

次の表に、Kubelet 統計レシーバーの構成オプションを示します:

同梱

https://raw.githubusercontent.com/splunk/collector-config-tools/main/cfg-metadata/receiver/kubeletstats.yaml

メトリクス

以下のメトリクス、リソース属性、および属性が使用できます。

注: SignalFx エクスポータは、デフォルトでいくつかの利用可能なメトリクスを除外します。デフォルトのメトリクスフィルタの詳細については、「List of metrics excluded by default」を参照してください。

同梱

https://raw.githubusercontent.com/splunk/collector-config-tools/main/metric-metadata/kubeletstatsreceiver.yaml

特定のメトリクスをアクティブまたは非アクティブにする

各メトリクスの metrics セクションの enabled フィールドを設定することで、特定のメトリクスをアクティブまたは非アクティブにできます。例:

YAML
receivers:
  samplereceiver:
    metrics:
      metric-one:
        enabled: true
      metric-two:
        enabled: false

以下は、アクティブ化されたメトリクスを持つホスト・メトリクス・レシーバーの構成例です:

YAML
receivers:
  hostmetrics:
    scrapers:
      process:
        metrics:
          process.cpu.utilization:
            enabled: true
注: 非アクティブ化されたメトリックは Splunk Observability Cloud に送信されません。
請求
  • MTS ベースのサブスクリプションの場合、すべてのメトリックがメトリックの使用にカウントされます。

  • ホストベースのプランを使用している場合、このドキュメントでアクティブ(アクティブ:はい)としてリストされているメトリックはデフォルトと見なされ、無料で含まれています。

詳細については、「Infrastructure Monitoringのサブスクリプション使用状況(ホストとメトリクスのプラン)」を参照してください。

トラブルシューティング

If you are a Splunk Observability Cloud customer and are not able to see your data in Splunk Observability Cloud, you can get help in the following ways.

Available to Splunk Observability Cloud customers

Available to prospective customers and free trial users

  • Ask a question and get answers through community support at Splunk Answers.

  • Join the Splunk community #observability Slack channel to communicate with customers, partners, and Splunk employees worldwide.