2021 年の State of DevOps アンケートに回答して、ソフトウェア オペレーションの未来を形作り、ご自分の意見を伝えましょう。

GKE ダッシュボードのトラブルシューティング

[リソース] メニューに [GKE] オプションがない場合、GKE 用 Cloud Operations を使用する GKE クラスタがない可能性があります。同様に、Kubernetes Engine がリストにない場合、以前の Logging と Monitoring を使用する GKE クラスタがない可能性があります。

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

GKE 用 Cloud Operations ダッシュボードに Kubernetes リソースが表示されない場合は、次の点を確認してください。

正しい Google Cloud プロジェクトがページの上部で選択されているか。

選択されていない場合は、メニューバーのプルダウン リストからプロジェクトを選択します。データを表示するプロジェクトを選択する必要があります。

プロジェクトにアクティビティがあるかどうか。

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

期間が短すぎるかどうか。

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

ダッシュボードの表示に必要な権限があるかどうか。

サービスのデプロイメントの詳細または 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 へのデータ書き込み権限があるかどうか。

API ダッシュボードでエラー率が高い場合は、サービス アカウントに次のロールがない可能性があります。

  • roles/logging.logWriter: Google Cloud Console では、このロールの名前は、ログ書き込みです。Logging のロールの詳細については、Logging アクセス制御ガイドをご覧ください。

  • roles/monitoring.metricWriter: Google Cloud Console では、このロールの名前は、モニタリング指標の書き込みです。Monitoring のロールの詳細については、Monitoring アクセス制御ガイドをご覧ください。

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

一部のログが表示されない理由

エージェントが過負荷状態になり、ログが破棄されているか。

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

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

  • container_name=fluentd-gcp フィルタを使用して 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 のログボリュームを減らす必要があります。

Logging エージェントの調整パラメータを変更する場合は、Fluentd で GKE の Cloud Logging ログをカスタマイズするを参照して、Logging エージェントのカスタム構成をデプロイします。

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

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

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

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

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

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