Docs » Splunk Observability Cloud でサポートされているインテグレーション » オーケストレーションのためにアプリケーション・レシーバーを設定する » Kubernetes APIサーバー

Kubernetes APIサーバー 🔗

Splunk Distribution of OpenTelemetry Collector は、API サーバーの Prometheus メトリクスエンドポイントからメトリクスを取得するために、Kubernetes API サーバーモニタータイプで Smart Agent レシーバー を使用します。

このインテグレーションはKubernetes、Linux、Windowsで利用できます。

このインテグレーションでは、コントロールプレーンの特定のポッドにアクセスできるように、kube-apiserverポッドにアクセスする必要があります。いくつかのKubernetes-as-a-serviceディストリビューションはエンドユーザーにコントロールプレーンのポッドを公開していないため、このようなケースではメトリクスの収集ができない可能性があります。

メリット 🔗

インテグレーションを設定すると、これらの機能にアクセスできるようになります：

インストール 🔗

このインテグレーションを導入するには、以下の手順に従ってください：

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

  2. [設定] セクションの説明に従ってインテグレーションを設定します。

  3. Splunk Distribution of OpenTelemetry Collector を再起動します。

設定 🔗

Smart Agent モニターとCollector のインテグレーションを使用するには、以下の手順に従います：

  1. Smart Agent レシーバーを設定ファイルに含めます。

  2. レシーバーセクションおよびパイプラインセクションの両方で、Collector 構成にモニタータイプを追加します。

例 🔗

このインテグレーションを有効にするには、Collector構成に以下を追加します：

receivers:
  smartagent/kubernetes-apiserver:
    type: kubernetes-apiserver
    ... # Additional config

次に、設定ファイルの service.pipelines.metrics.receivers セクションにモニターを追加します：

service:
  pipelines:
    metrics:
      receivers: [smartagent/kubernetes-apiserver]

エージェントとゲートウェイのYAMLファイルについては、GitHubのkubernetes-yamlの例を参照してください。

例Kubernetesオブザーバー 🔗

以下はYAMLコンフィギュレーションの例です：

receivers:
  smartagent/kubernetes-apiserver:
    type: kubernetes-apiserver
    host: localhost
    port: 443
    extraDimensions:
      metric_source: kubernetes-apiserver

OpenTelemetry Collector には Kubernetes observer ( k8sobserver ) があり、Kubernetes pod のようなネットワーク接続されたエンドポイントを発見するための拡張として実装することができます。このオブザーバーを使用することは、OpenTelemetry Collectorがホストモニタリング（エージェント）モードでデプロイされ、個々のノードやホストインスタンス上で動作していることを想定しています。

オブザーバーを使用するには、関連するルールを持つレシーバークリエーターのインスタンスを作成します。例：

extensions:
  # Configures the Kubernetes observer to watch for pod start and stop events.
  k8s_observer:

receivers:
  receiver_creator/1:
    # Name of the extensions to watch for endpoints to start and stop.
    watch_observers: [k8s_observer]
    receivers:
      smartagent/kubernetes-apiserver:
        rule: type == "pod" && labels["k8s-app"] == "kube-apiserver"
        type: kubernetes-apiserver
        port: 443
        extraDimensions:
          metric_source: kubernetes-apiserver

processors:
  exampleprocessor:

exporters:
  exampleexporter:

service:
  pipelines:
    metrics:
      receivers: [receiver_creator/1]
      processors: [exampleprocessor]
      exporters: [exampleexporter]
  extensions: [k8s_observer]

詳しくは レシーバークリエーター を参照してください。

コンフィギュレーション設定 🔗

次の表に、このモニターの設定オプションを示します：

オプション

必須

タイプ

説明

httpTimeout

いいえ

int64
読み込みと書き込みの両方のHTTPタイムアウト時間。これは

https://golang.org/pkg/time/#ParseDuration が受け付ける継続時間文字列。(デフォルト： 10s )

username

いいえ

string

各リクエストで使用される Basic Auth ユーザー名 (ある場合)。

password

いいえ

string

各リクエストで使用するBasic Authパスワード (ある場合)。

useHTTPS

いいえ

bool
true の場合、エージェントはサーバーへの接続に

プレーン HTTP の代わりに HTTPS を使用します。(デフォルト: false )

httpHeaders

いいえ

map of strings
HTTP ヘッダー名と値のマップ。 同じメッセージ・ヘッダーに対する

カンマ区切りの複数の値もサポートしています。

skipVerify

いいえ

bool
useHTTPS が true で、このオプションも true の場合、

エクスポーターの TLS 証明書は検証されません。(デフォルト： false )

caCertPath

いいえ

string
TLS証明書に署名したCA証明書へのパス。

skipVerify は false に設定されている場合は不要です。

clientCertPath

いいえ

string

TLSが必要な接続に使用するクライアントTLS証明書へのパス。

clientKeyPath

いいえ

string

TLSが必要な接続に使用するクライアントTLSキーへのパス。

host

はい

string

エクスポーターのホスト。

port

はい

integer

エクスポーターのポート。

useServiceAccount

いいえ

bool
認証にポッドサービスアカウントを使用します。(デフォルト:

false )

metricPath

いいえ

string
エクスポーター・サーバー上のメトリクス・エンドポイントへのパス。通常は

/metrics (the default). (default: /metrics)

sendAllMetrics

いいえ

bool
Prometheusエクスポーターから出力されるすべてのメトリクスを

フィルターリングなしで送信します。このオプションは、prometheus exporterモニターを直接使用する場合には、組み込みのフィルターリングがないため、効果がありません。(デフォルト： false )

メトリクス 🔗

このインテグレーションでは、以下のメトリクスを使用できます：

備考 🔗

  • To learn more about the available in Splunk Observability Cloud see メトリクスタイプ

  • In host-based subscription plans, default metrics are those metrics included in host-based subscriptions in Splunk Observability Cloud, such as host, container, or bundled metrics. Custom metrics are not provided by default and might be subject to charges. See メトリクスカテゴリ for more information.

  • MTSベースのサブスクリプションプランでは、すべてのメトリクスがカスタムです。

  • メトリクスを追加するには、その他のメトリクスの追加 で extraMetrics の設定方法を参照してください。

トラブルシューティング 🔗

「bind：すでに使用されているアドレス」のようなエラーメッセージが表示されます

「bind：すでに使用されているアドレス」のようなエラーメッセージが表示される場合は、現在の構成が必要とするポートを別のリソースがすでに使用しています。このリソースは、他のアプリケーションや、JaegerやZipkinのようなトレースツールである可能性があります。

別のポートを使用するように設定を変更することができます。これらのエンドポイントまたはポートのいずれかを変更できます：

  • レシーバー・エンドポイント

  • 拡張機能のエンドポイント

  • メトリクスアドレス（ポート8888の場合）

Kubernetesでこのエラーメッセージが表示され、Helmチャートを使用している場合は、設定と公開ポートの両方のチャート値を更新して設定を修正してください。

「2021-10-19T20:18:40.556Z info builder/receivers_builder.go:112 どのパイプラインでも使用されていないため、レシーバーを無視しています {”kind”: “receiver”, “name”: “」というエラーメッセージが表示されます

このエラーは、コンポーネント（レシーバー、プロセッサー、エクスポーター）が設定されているにもかかわらず、レシーバー パイプラインで使用されていない場合に発生します。たとえば、次のエラー メッセージは、smartagent/http レシーバーが構成されていますが、どのパイプラインでも使用されていないことを示します：

“2021-10-19T20:18:40.556Z info builder/receivers_builder.go:112 Ignoring receiver as it is not used by any pipeline {"kind": "receiver", "name": "smartagent/http"

一度設定したら、サービスセクションのパイプラインを使用して、すべてのコンポーネントをオンにする必要があります。サービスセクションは、コンフィギュレーションファイルのコンポーネントセクションにあるコンフィギュレーションに基づいて、どのコンポーネントをアクティブにするかを設定するために使用されます。コンポーネントが設定されていても、サービスセクションで定義されていない場合、そのコンポーネントは有効になりません。

以下に設定例を示します：

service:
  pipelines:
  # Pipelines can contain multiple subsections, one per pipeline.
    traces:
    # Traces is the pipeline type.
      receivers: [otlp, jaeger, zipkin]
      processors: [memory_limiter, batch]
      exporters: [otlp, jaeger, zipkin]

詳しくは パイプラインでデータを処理する を参照してください。

Splunk Distribution of OpenTelemetry Collector がメモリ不足です。

メモリ使用量が多い、またはメモリ不足の警告が表示される場合は、サポート・ケースを開く前に次のことを行ってください：

  1. 最新バージョンの OpenTelemetry Collector for Kubernetes の Splunk ディストリビューションがインストールされていることを確認します。

  2. 設定ファイルに memory_limiter プロセッサーを追加または変更します。例：

    processors:
  memory_limiter:
     ballast_size_mib: 2000
     check_interval: 5s
        # Check_interval is the time between measurements of memory usage for the  purposes of avoiding goingover the limits.
        # The default is 0. Values below 1s are not recommended, as this can result in unnecessary CPU consumption.
     limit_mib: 4000
        # ​​Maximum amount of memory, in MiB, targeted to be allocated by the process heap.
        # The total memory usage of the process is typically about 50 MiB higher than this value.
     spike_limit_mib: 500
        # The maximum, in MiB, spike expected between the measurements of memory usage.
     ballast_size_mib: 2000
        # BallastSizeMiB is the size, in MiB, of the ballast size being used by the process.
        # This must match the value of the mem-ballast-size-mib command line option (if used).
        # Otherwise, the memory limiter does not work correctly.

  3. エラーを再現し、メモリキルが発生したポイントの近くでヒープダンプを収集してみます：

    1. 失敗しているコンポーネント構成に、pprof 拡張機能を追加します。サービスセクションのパイプラインでこの拡張機能をオンにしたことを確認してください。

    2. 問題のあるポッドに対する以下のコマンドの出力をキャプチャします：

    curl http://127.0.0.1:1777/debug/pprof/goroutine?debug=2 (http://127.0.0.1:1777/debug/pprof/goroutine?debug=2)
curl http://127.0.0.1:1777/debug/pprof/heap > heap.out

例えば、ポッドが強制終了されるまで5分間経過していることがわかったとします：

  1. ポッドをバウンスさせ、始動後の最初のデータセットを収集します。

  2. 3分待ってから、別のデータを収集します。データには必ず対応するようにラベル付けを行ってください。

  3. 可能であれば、クラッシュ前に別のデータを収集します。

メモリ制限のためにポッドが強制終了されるまで、どれくらいの時間がかかりますか？問題が発生した時点のログをチェックして、明らかな繰り返しエラーがないかどうかを確認してください。

エンドツーエンドのアーキテクチャー情報など、追加で裏付けとなる情報を収集します。サポートリクエストを開くために情報を収集する を参照してください。

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

見込み客および無料トライアルユーザー様

  • Splunk Answers のコミュニティサポートで質問し、回答を得る

  • Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。

This page was last updated on 2024年05月29日.