システム指標のトラブルシューティング

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）クラスタでシステム指標関連の問題を解決する方法について説明します。

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

クラスタの指標が Cloud Monitoring に表示されない

プロジェクトで Monitoring API と Logging API が有効になっていることを確認します。また、Google Cloud コンソールの Cloud Monitoring の概要でプロジェクトを表示できることを確認する必要があります。

問題が解決しない場合は、次の原因が考えられます。

クラスタでモニタリングが有効になっていますか？

Google Cloud コンソールと Google Cloud CLI で作成したクラスタでは、モニタリングがデフォルトで有効になります。これを確認するには、Google Cloud コンソールでクラスタの詳細情報をクリックするか、次のコマンドを実行します。
```
gcloud container clusters describe CLUSTER_NAME
```
このコマンドの出力では、次のように、monitoringConfig セクションの enableComponents のリストに SYSTEM_COMPONENTS が含まれているはずです。
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
モニタリングが有効になっていない場合は、次のコマンドを実行して有効にします。
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
クラスタを作成してから、またはモニタリングを有効にしてからどれくらいの時間が経過していますか？

新しいクラスタの指標が Cloud Monitoring に表示されるまでに最長で 1 時間かかります。
heapster または gke-metrics-agent（OpenTelemetry Collector）がクラスタの kube-system Namespace で実行されていますか？

クラスタのリソースが不足しているため、ポッドがワークロードのスケジュールに失敗している可能性があります。kubectl get pods --namespace=kube-system を実行し、名前に heapster または gke-metrics-agent が含まれる Pod があるか調べて、Heapster または OpenTelemetry が実行されているかどうかを確認してください。
クラスタのコントロールプレーンはノードと通信できますか？

Cloud Monitoring はこの通信に依存しています。コントロールプレーンがノードと通信しているかどうかを確認するには、次のコマンドを実行します。
```
kubectl logs POD_NAME
```
このコマンドがエラーを返した場合は、SSH トンネルで問題が発生している可能性があります。トラブルシューティングの手順については、SSH の問題のトラブルシューティングをご覧ください。

指標エージェントに十分なメモリがあることを確認する

上記のトラブルシューティングの手順を試しても指標が表示されない場合は、指標エージェントにメモリが不足している可能性があります。

ほとんどの場合、GKE 指標エージェントのリソースはデフォルトの割り当てで十分です。ただし、DaemonSet が頻繁にクラッシュする場合は、次の手順で終了の理由を確認できます。

GKE 指標エージェントの Pod の名前を取得します。

kubectl get pods -n kube-system -l component=gke-metrics-agent

ステータスが CrashLoopBackOff の Pod を見つけます。

出力は次のようになります。

NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

ステータスが CrashLoopBackOff の Pod の説明を取得します。
```
kubectl describe pod POD_NAME -n kube-system
```
POD_NAME は、前の手順の Pod の名前に置き換えます。

Pod の終了の理由が OOMKilled の場合、エージェントに追加のメモリが必要です。

出力は次のようになります。
```
  containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"
```
失敗した指標エージェントを含むノードにノードラベルを追加します。永続的または一時的なノードラベルを使用できます。20 MB を追加してみることをおすすめします。それでもエージェントがクラッシュし続ける場合は、より大容量の追加メモリをリクエストするノードラベルに置き換えて、もう一度このコマンドを実行します。

永続ラベルを持つノードプールを更新するには、次のコマンドを実行します。
```
gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
    --location=COMPUTE_LOCATION
```
次のように置き換えます。
- NODEPOOL_NAME: ノードプールの名前。
- CLUSTER_NAME: 既存のクラスタの名前。
- ADDITIONAL_MEMORY_NODE_LABEL: 追加するメモリのノードラベル。次のいずれかの値を使用します。
  - 10 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=10
  - 20 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=20
  - 50 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=50
  - 100 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=100
  - 200 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=200
  - 500 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=500
- COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。
または、次のコマンドを使用して、アップグレード後に保持されない一時的なノードラベルを追加することもできます。
```
kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite
```
次のように置き換えます。
- NODE_NAME: 影響を受ける指標エージェントのノードの名前。
- ADDITIONAL_MEMORY_NODE_LABEL: 追加するメモリのノードラベル。上記の例のいずれかの値を使用します。

次のステップ

Cloud Logging エージェントに関連する問題が発生している場合は、エージェントのトラブルシューティングのドキュメントをご覧ください。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。