モニタリングダッシュボードのトラブルシューティング

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）のモニタリングダッシュボードに関連する問題を解決する方法について説明します。

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

デフォルトでは、クラスタを作成すると Monitoring が有効になります。Monitoring で提供された Google Cloud ダッシュボードを表示したときに GKE ダッシュボードが表示されない場合は、選択した Google Cloud プロジェクトのクラスタに対して Monitoring が有効になっていません。これらのダッシュボードを表示するには、Monitoring を有効にします。

Kubernetes リソースがダッシュボードに表示されない

GKE ダッシュボードに Kubernetes リソースが表示されない場合は、以下の点を確認します。

選択した Google Cloud プロジェクト

Google Cloud コンソールのメニューバーのプルダウンリストから正しい Google Cloud プロジェクトを選択していることを確認します。データを表示するプロジェクトを選択する必要があります。

クラスタアクティビティ

クラスタを作成したばかりの場合は、データが入力されるまで数分間かかります。詳細については、GKE のロギングとモニタリングの構成をご覧ください。

期間

選択した期間が狭すぎる場合があります。ダッシュボードツールバーの [時間] メニューを使用して、他の期間を選択するか、カスタム範囲を定義します。

ダッシュボードを表示する権限

サービスのデプロイメントの詳細または Google Cloud プロジェクトの指標を表示するときに、次のいずれかの権限拒否エラーメッセージが表示された場合は、Identity and Access Management のロールを更新し、roles/monitoring.viewer または roles/viewer を含める必要があります。

You do not have sufficient permissions to view this page
You don't have permissions to perform the action on the selected resources

詳しくは、事前定義ロールをご覧ください。

Monitoring と Logging にデータを書き込むために必要なクラスタとノードのサービスアカウントの権限

Google Cloud コンソールの [有効な API とサービス] ページでエラー率が高い場合は、サービスアカウントに次のロールがない可能性があります。

roles/logging.logWriter: Google Cloud コンソールでは、このロールの名前は、ログ書き込みです。Logging のロールの詳細については、Logging アクセス制御ガイドをご覧ください。
roles/monitoring.metricWriter: Google Cloud Console では、このロールの名前は、モニタリング指標の書き込みです。Monitoring のロールの詳細については、Monitoring アクセス制御ガイドをご覧ください。
roles/stackdriver.resourceMetadata.writer: Google Cloud Console では、このロールの名前は、Stackdriver リソースメタデータ書き込みです。このロールは、リソースメタデータへの書き込み専用アクセスを許可し、エージェントがメタデータを送信するのに必要な権限を提供します。Monitoring のロールの詳細については、Monitoring アクセス制御ガイドをご覧ください。

サービスアカウントを一覧表示するには、Google Cloud コンソールで [IAM と管理] に移動し、[サービスアカウント] を選択します。

ログが表示されない

ダッシュボードにログが表示されない場合は、次の点を確認してください。

エージェントが稼働中で正常な状態である

GKE バージョン 1.17 以降では、Fluent Bit を使用してログを取得します。Fluent Bit は、Kubernetes ノードで動作する Logging エージェントです。エージェントが正しく動作しているかどうかを確認するには、以下の手順を行います。

次のコマンドを実行して、エージェントが再起動しているかどうかを確認します。

kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

再起動していない場合、出力は次のようになります。

NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

次のコマンドを実行して、Pod の status.conditions を確認します。

JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

デプロイメントが正常な場合は、次のような形の出力が得られます。

fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

次のコマンドを実行して Pod のステータスを確認します。これにより、デプロイメントが正常かどうかを判断できます。
```
kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system
```
デプロイメントが正常な場合は、次のような形の出力が得られます。
```
NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h
```
この出力例では、DESIRED 状態が CURRENT 状態と一致しています。

また、エージェントが動作しており正常な状態であっても、すべてのログが表示されない場合は、エージェントが過負荷状態で、ログが破棄されている可能性があります。

エージェントが過負荷状態でログが破棄される

ログが表示されない理由の 1 つとして、ノードのログボリュームが多く、エージェントが過負荷状態になっていることが考えられます。GKE のデフォルトの Logging エージェント構成では、ノードあたり 100 KiB/秒の速度が設定されています。ボリュームがこの上限を超えると、ログの削除が開始することがあります。

この上限に達しているかどうかを確認するには、次のいずれかのインジケーターを探します。

container_name=fluentbit-gke フィルタを使用して kubernetes.io/container/cpu/core_usage_time 指標を表示し、Logging エージェントの CPU 使用量が 100% に近くになっていないか確認します。
metadata.system_labels.node_name でグループ化して logging.googleapis.com/byte_count の指標を表示して、いずれかのノードが 100 KiB/秒に達しているかどうか確認します。

いずれかの条件に該当する場合は、クラスタにノードを追加して、ノードのログボリュームを減らすことができます。すべてのログボリュームが 1 つの Pod から発生している場合は、その Pod のログボリュームを減らす必要があります。

GKE のロギング関連の問題の調査と解決については、GKE でのロギングのトラブルシューティングをご覧ください。

インシデントが GKE リソースと一致しない場合

複数の GKE リソースから指標を集約するアラートポリシー条件がある場合、インシデントを特定のエンティティに関連付けるため、ポリシー条件を編集して GKE 階層ラベルを追加しなければならない場合があります。

たとえば、本番環境用とステージング用の GKE クラスタがあり、それぞれにサービス lilbuddy-2 の独自のコピーがあるとします。アラートポリシーの条件で両方のクラスタのコンテナ間で指標が集計されると、GKE Monitoring ダッシュボードで、このインシデントを本番環境のサービスまたはステージングのサービスと一意に関連付けることができません。

この状況を解決するには、ポリシーの [グループ条件] フィールドに namespace、cluster、location を追加して、アラートポリシーを特定のサービスに関連付けます。アラートのイベントカードで、[Update alert policy] リンクをクリックして、関連するアラートポリシーの [アラートポリシーの編集] ページを開きます。ここで、アラートポリシーの情報を更新し、ダッシュボードに関連リソースが表示されるようにします。

アラートポリシーを更新すると、GKE Monitoring ダッシュボードで新たに発生したインシデントを特定のクラスタ内の一意のサービスに関連付け、問題の診断に役立つ追加情報を得ることができます。

ユースケースによっては、[グループ条件] フィールドに追加するときに、一部のラベルをフィルタリングできます。たとえば、本番環境のクラスタに対するアラートのみが必要な場合は、cluster_name でフィルタできます。

次のステップ