Collector for Kubernetes コンテナのトラブルシューティング 🔗
注釈
一般的なトラブルシューティングについては、Collector のトラブルシューティング および Collector for Kubernetes のトラブルシューティング を参照してください。
コンテナのメモリ不足を確認する 🔗
Collector コンテナに十分なリソースを提供しなかった場合でも、通常であれば Collector がメモリ不足（OOM）になることはありません。これは、Collector がメモリ使用率を制御できる速度よりも速く成長しているバックエンドとエクスポーターの送信キューによって、Collector が大きくスロットルされている場合にのみ発生します。この場合、メトリクスとトレースの 429 エラー、ログの 503 エラーが表示されます。
例：
2021-11-12T00:22:32.172Z info exporterhelper/queued_retry.go:325 Exporting failed. Will retry the request after interval. {"kind": "exporter", "name": "sapm", "error": "server responded with 429", "interval": "4.4850027s"}
2021-11-12T00:22:38.087Z error exporterhelper/queued_retry.go:190 Dropping data because sending_queue is full. Try increasing queue_size. {"kind": "exporter", "name": "sapm", "dropped_items": 1348}
バックエンドの制限を増やしたり、Collector 経由で送信されるデータ量を減らしたりしてもスロットリングを修正できない場合は、失敗したエクスポーターの送信キューを減らすことで OOM を回避できます。たとえば、sapm エクスポーターの sending_queue を減らすことができます：
agent:
config:
exporters:
sapm:
sending_queue:
queue_size: 512
同じような設定を、他の失敗したエクスポーターにも適用できます。
Kubernetes とコンテナランタイムの互換性 🔗
Kubernetes では、クラスター内の各ノードにコンテナランタイムをインストールし、そこでポッドを実行できるようにする必要があります。Splunk Distribution of the Collector for Kubernetes は、containerd、CRI-O、Docker、Mirantis Kubernetes Engine (旧 Docker Enterprise/UCP) などのコンテナランタイムをサポートしています。
バージョンや構成に互換性のないコンテナランタイムを使用している Kubernetes クラスターでは、次のような問題が発生する可能性があります：
コンテナ、ポッド、またはノードからの統計が存在しないか、不正な形式です。その結果、これらの統計を必要とするCollectorは、望ましい対応するメトリクスを生成しません。
コンテナ、ポッド、ノードが正常に起動しない、またはきれいに停止しません。
ノード上のkubeletプロセスが停止状態にあります。
特定の Kubernetes のバージョンとコンテナランタイムの互換性レベルは異なる可能性があるため、互換性があることが分かっている Kubernetes のバージョンとコンテナランタイムを使用してください。方法については以下を参照してください： コンテナランタイムの互換性のトラブルシューティング。
ランタイムの詳細については、コンテナランタイム を参照してください。
コンテナランタイムの互換性のトラブルシューティング 🔗
Kubernets とコンテナランタイムの互換性に問題があるかどうかを確認するには、以下の手順に従ってください：
kubectl get nodes -o wideを実行して、使用されている Kubernetes とコンテナランタイムのバージョンを確認します。
-o wideフラグを指定すると、追加情報を含むプレーンテキスト形式の出力が出力されます。ポッドの場合は、ノード名が含まれる。以下の例では、node-1は Kubernetes 1.19.6 と containerd 1.4.1を使用しています：kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.19.6 containerd://1.4.1
Kubernetesのバージョンと互換性のあるコンテナランタイムを使用していることを確認します。コンテナランタイムの互換性については、以下のベンダーのドキュメントを参照してください：
コンテナ統計の完全性をチェックします。方法は、コンテナ統計の完全性をチェックする を参照してください。
コンテナ統計の完全性をチェックする 🔗
コンテナ、ポッド、およびノードの統計情報を確認するには、Kubelet Summary API を使用します。Kubelet は、/stats エンドポイントを通じて利用可能なノードごとの要約された統計情報を検出および取得するための Summary API を提供します。
以下の例では、CollectorがKubelet Stats Receiverメトリクスの生成に使用するCPU、メモリ、およびネットワークの統計情報が存在することを確認する方法を示します。これらのテクニックを拡張して、利用可能な他のKubernetes統計を評価することができます。
これらの例で示されている統計情報は、特に断りのない限りすべて存在するはずです。出力に統計値がない、または統計値が異なるフォーマットで表示される場合は、Kubernetesクラスターとコンテナランタイムが完全に互換していない可能性があります。
ノードの統計情報を確認する 🔗
ノードの統計情報を確認します：
以下のコマンドを実行してクラスター内のノード名を取得し、ノードの1つから生のリソース使用統計情報を取り出します：
kubectl get nodes -o wide評価するノードを選び、その名前を環境変数に設定します。以下の例では、ノードの名前は
node-1です：NODE_NAME=node-1ノードが適切な統計情報を持っていることを確認します：
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '{"node": {"name": .node.nodeName, "cpu": .node.cpu, "memory": .node.memory, "network": .node.network}} | del(.node.network.interfaces)' { "node": { "name": "node-1", "cpu": { "time": "2022-05-20T18:12:08Z", "usageNanoCores": 149771849, "usageCoreNanoSeconds": 2962750554249399 }, "memory": { "time": "2022-05-20T18:12:08Z", "availableBytes": 2701385728, # Could be absent if node memory allocations were missing. "usageBytes": 3686178816, "workingSetBytes": 1421492224, "rssBytes": 634343424, "pageFaults": 18632526, "majorPageFaults": 726 }, "network": { "time": "2022-05-20T18:12:08Z", "name": "eth0", "rxBytes": 105517219156, "rxErrors": 0, "txBytes": 98151853779, "txErrors": 0 } } }
参考のため、次の表にノード統計名とCollectorメトリクス名の対応を示します：
ノード統計名 |
Collector のメトリクス名 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ポッドの統計情報を確認する 🔗
注釈
このセクションを完了する前に、ノードの統計情報を確認する のステップ1と2を完了する必要があります。
ポッドの統計情報を確認する
以下のコマンドを実行して、選択したノードのポッド名を取得し、ポッドの1つから生のリソース使用統計を取り出します：
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[].podRef.name'評価するポッドを選択し、その名前を環境変数に設定します。以下の例では、ポッドの名前は
splunk-otel-collector-agent-6llkrです：POD_NAME=splunk-otel-collector-agent-6llkrポッドが適切な統計情報を持っていることを確認します：
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[] | select(.podRef.name=='\"$POD_NAME\"') | {"pod": {"name": .podRef.name, "cpu": .cpu, "memory": .memory, "network": .network}} | del(.pod.network.interfaces)' { "pod": { "name": "splunk-otel-collector-agent-6llkr", "cpu": { "time": "2022-05-20T18:38:47Z", "usageNanoCores": 10774467, "usageCoreNanoSeconds": 1709095026234 }, "memory": { "time": "2022-05-20T18:38:47Z", "availableBytes": 781959168, # Could be absent if pod memory limits were missing. "usageBytes": 267563008, "workingSetBytes": 266616832, "rssBytes": 257036288, "pageFaults": 0, "majorPageFaults": 0 }, "network": { "time": "2022-05-20T18:38:55Z", "name": "eth0", "rxBytes": 105523812442, "rxErrors": 0, "txBytes": 98159696431, "txErrors": 0 } } }
参考のため、次の表にPod stat名とCollectorメトリクス名のマッピングを示します：
ポッド統計名 |
Collector のメトリクス名 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
コンテナの統計情報を確認する 🔗
注釈
このセクションを完了する前に、ノードの統計情報を確認する と ポッドの統計情報を確認する の両方でステップ1と2を実行してください。
コンテナの統計情報を確認します：
以下のコマンドを実行して、選択したポッド内のコンテナ名を取得し、コンテナの1つから生のリソース使用統計情報を取り出します：
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[] | select(.podRef.name=='\"$POD_NAME\"') | .containers[].name'評価するコンテナを選択し、その名前を環境変数に設定します。以下の例では、コンテナの名前は
otel-collectorです：CONTAINER_NAME=otel-collectorコンテナが適切な統計情報を持っていることを確認します：
kubectl get --raw "/api/v1/nodes/"${NODE_NAME}"/proxy/stats/summary" | jq '.pods[] | select(.podRef.name=='\"$POD_NAME\"') | .containers[] | select(.name=='\"$CONTAINER_NAME\"') | {"container": {"name": .name, "cpu": .cpu, "memory": .memory}}' { "container": { "name": "otel-collector", "cpu": { "time": "2022-05-20T18:42:15Z", "usageNanoCores": 6781417, "usageCoreNanoSeconds": 1087899649154 }, "memory": { "time": "2022-05-20T18:42:15Z", "availableBytes": 389480448, # Could be absent if container memory limits were missing. "usageBytes": 135753728, "workingSetBytes": 134807552, "rssBytes": 132923392, "pageFaults": 93390, "majorPageFaults": 0 } } }
参考のため、以下の表に、コンテナ統計名とCollectorメトリクス名のマッピングを示します：
コンテナ統計名 |
Collector のメトリクス名 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
報告された互換性のないKubernetesとコンテナランタイムの問題 🔗
注釈
マネージドKubernetesサービスは、変更されたコンテナランタイムを使用している可能性があり、サービスプロバイダは、変更されていないコンテナランタイムには存在しないカスタムパッチやバグ修正を適用している可能性があります。
このセクションでは、既知の非互換性とコンテナランタイムの問題について説明します。
Kubernetes 1.21.0～1.21.11とcontainerd 🔗
Kubernetes 1.21.0 から 1.21.11 を containerd と一緒に使用すると、メモリとネットワークの統計またはメトリクスが欠落する可能性があります。以下は影響を受けるメトリクスのリストです：
k8s.pod.network.io{direction="receive"}またはpod_network_receive_bytes_totalk8s.pod.network.errors{direction="receive"}またはpod_network_receive_errors_totalk8s.pod.network.io{direction="transmit"}またはpod_network_transmit_bytes_totalk8s.pod.network.error{direction="transmit"}またはpod_network_transmit_errors_totalcontainer.memory.availablecontainer.memory.usagecontainer.memory.rssBytescontainer.memory.page_faultscontainer.memory.major_page_faults
この問題を解決するには、次のいずれかの回避策をお試しください：
Kubernetesをバージョン1.21.12以上にアップグレードします。
containerdをバージョン1.4.xまたは1.5.xにアップグレードします。
Kubernetes 1.22.0～1.22.8とcontainerd 1.4.0～1.4.12 🔗
Kubernetes 1.22.0～1.22.8をcontainerd 1.4.0～1.4.12と共に使用すると、メモリとネットワークの統計またはメトリクスが欠落することがあります。以下は、影響を受けるメトリクスのリストです：
k8s.pod.network.io{direction="receive"}またはpod_network_receive_bytes_totalk8s.pod.network.errors{direction="receive"}またはpod_network_receive_errors_totalk8s.pod.network.io{direction="transmit"}またはpod_network_transmit_bytes_totalk8s.pod.network.error{direction="transmit"}またはpod_network_transmit_errors_totalk8s.pod.memory.availablecontainer.memory.availablecontainer.memory.usagecontainer.memory.rssBytescontainer.memory.page_faultscontainer.memory.major_page_faults
この問題を解決するには、次のいずれかの回避策をお試しください：
Kubernetesを少なくともバージョン1.22.9にアップグレードして、コンテナのメモリとポッドのネットワークメトリクスの欠落を修正します。
containerdを少なくともバージョン1.4.13または1.5.0にアップグレードして、欠落しているポッドメモリメトリクスを修正します。
Kubernetes 1.23.0～1.23.6とcontainerd 🔗
Kubernetesのバージョン1.23.0～1.23.6をcontainerdで使用すると、メモリの統計やメトリクスが欠落することがあります。以下は影響を受けるメトリクスのリストです：
k8s.pod.memory.available
現時点では、この問題の回避策はありません。