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 にアクセスして、モニターから送信されたメトリクスを検索します。詳細については、メトリクス・ファインダーとメタデータ・カタログを検索する を参照してください。
インストール 🔗
このインテグレーションを導入するには、以下の手順に従ってください:
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]
詳しくは レシーバークリエーター を参照してください。
コンフィギュレーション設定 🔗
次の表に、このモニターの設定オプションを示します:
オプション |
必須 |
タイプ |
説明 |
---|---|---|---|
|
いいえ |
|
|
|
いいえ |
|
各リクエストで使用される Basic Auth ユーザー名 (ある場合)。 |
|
いいえ |
|
各リクエストで使用するBasic Authパスワード (ある場合)。 |
|
いいえ |
|
|
|
いいえ |
|
|
|
いいえ |
|
|
|
いいえ |
|
|
|
いいえ |
|
TLSが必要な接続に使用するクライアントTLS証明書へのパス。 |
|
いいえ |
|
TLSが必要な接続に使用するクライアントTLSキーへのパス。 |
|
はい |
|
エクスポーターのホスト。 |
|
はい |
|
エクスポーターのポート。 |
|
いいえ |
|
|
|
いいえ |
|
|
|
いいえ |
|
|
メトリクス 🔗
このインテグレーションでは、以下のメトリクスを使用できます:
備考 🔗
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.
エラーを再現し、メモリキルが発生したポイントの近くでヒープダンプを収集してみます:
失敗しているコンポーネント構成に、
pprof
拡張機能を追加します。サービスセクションのパイプラインでこの拡張機能をオンにしたことを確認してください。問題のあるポッドに対する以下のコマンドの出力をキャプチャします:
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 マニュアルの チャットグループ を参照してください。