Kubernetes APIサーバー 🔗

The Splunk Distribution of OpenTelemetry Collector uses the Smart Agent receiver with the Kubernetes API server monitor type to retrieve metrics from the API server’s Prometheus metric endpoint.

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

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

メリット 🔗

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

メトリクスを表示します。独自のカスタム・ダッシュボードを作成することができ、ほとんどのモニターは組み込みのダッシュボードも提供しています。ダッシュボードについては、Splunk Observability Cloudでダッシュボードを表示するを参照してください。
Infrastructure Monitoring に表示される環境内の物理サーバー、仮想マシン、AWS インスタンス、およびその他のリソースのデータ駆動型の視覚化を表示します。ナビゲーターについては、Splunk Infrastructure Monitoring でナビゲーターを使用するを参照してください。
Metric Finder にアクセスして、モニターから送信されたメトリクスを検索します。詳細については、Search the Metric Finder and Metadata Catalog を参照してください。

インストール 🔗

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

Splunk Distribution of the OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：
[設定] セクションの説明に従ってインテグレーションを設定します。
Splunk Distribution of OpenTelemetry Collector を再起動します。

設定 🔗

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

Smart Agent レシーバーを設定ファイルに含めます。
レシーバーセクションおよびパイプラインセクションの両方で、Collector 構成にモニタータイプを追加します。

Collector でSmart Agent モニターを使用するの方法を参照してください。
Smart Agent レシーバーの設定方法を参照してください。
一般的な設定オプションのリストについては、モニターの共通設定を参照してください。
Collectorの詳細は、はじめに：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 がメモリ不足です。

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

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

設定ファイルに 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.

エラーを再現し、メモリキルが発生したポイントの近くでヒープダンプを収集してみます：
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分間経過していることがわかったとします：

ポッドをバウンスさせ、始動後の最初のデータセットを収集します。
3分待ってから、別のデータを収集します。データには必ず対応するようにラベル付けを行ってください。
可能であれば、クラッシュ前に別のデータを収集します。

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

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

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

Splunk Observability Cloudをご利用のお客様

Submit a case in the Splunk Support Portal .
Contact Splunk Support .

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

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

このページは 2024年12月09日に最終更新されました。

Related Topics