オブザーバビリティのトラブルシューティング

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ アプライアンスで発生する可能性のあるデプロイの失敗と運用上のインシデントを特定する方法について説明します。また、ロギング コンポーネントとモニタリング コンポーネントに関する一般的な問題を解決するために、システムに表示されるすべてのアラートの説明も記載しています。

オブザーバビリティ コンポーネントを特定する

オブザーバビリティ プラットフォームは、コンポーネントを組織のインフラストラクチャ クラスタの obs-system Namespace にデプロイします。

Infrastructure Operator（IO）の Grafana インスタンスは、組織レベルの指標へのアクセスを提供し、CPU 使用率やストレージ消費量などのインフラストラクチャ コンポーネントをモニタリングします。運用ログと監査ログへのアクセスも提供します。また、GDC の運用可能なコンポーネントからアラート、ログ、指標にアクセスできます。

GDC のモニタリング スタックとロギング スタックは、オブザーバビリティ プラットフォームの一部としてオープンソース ソリューションを使用します。これらのコンポーネントは、Kubernetes Pod、ベアメタル マシン、ネットワーク スイッチ、ストレージ、マネージド サービスからログと指標を収集します。

次の表に、オブザーバビリティ プラットフォームを統合するすべてのコンポーネントの説明を示します。

コンポーネント 説明
Prometheus Prometheus は、指標の収集と保存、アラートの評価を行う時系列データベースです。Prometheus は、長期保存のために組織インフラストラクチャ クラスタの Cortex インスタンスに指標を保存します。Prometheus はラベルを Key-Value ペアとして追加し、Kubernetes ノード、Pod、ベアメタル マシン、ネットワーク スイッチ、ストレージ アプライアンスから指標を収集します。
Alertmanager Alertmanager は、ログまたは指標がシステム コンポーネントの障害または正常な動作を示していない場合にアラートを送信する、ユーザー定義のマネージャー システムです。Prometheus アラートのルーティング、サイレンシング、集約を管理します。
Loki Loki は、さまざまなソースからログを保存して集計する時系列データベースです。クエリを効率的に実行するためにログのインデックスを作成します。
Grafana Grafana は、Prometheus が収集した指標を表示し、対応する Loki インスタンスから監査ログと運用ログをクエリするためのユーザー インターフェース（UI）を提供します。UI を使用すると、指標とアラートのダッシュボードを可視化できます。
Fluent Bit Fluent Bit は、さまざまなコンポーネントや場所からログを取得して Loki に送信するプロセッサです。すべてのクラスタのすべてのノードで実行されます。

デプロイの失敗を特定する

デプロイが実行されていて正常な場合、コンポーネントは READY 状態で実行されます。

次の手順に沿って、デプロイの失敗を特定します。

  1. コンポーネントの現在の状態を確認します。

    kubectl get -n obs-system TYPE/COMPONENT

    次のように置き換えます。

    • TYPE: コンポーネントのタイプ
    • COMPONENT: コンポーネント名

    次のような出力が表示されます。

    NAME       READY  AGE
COMPONENT  1/1    23h

    コンポーネントが正常な場合、出力の READY 列には値として N/N が表示されます。READY 列に値が表示されない場合でも、必ずしも失敗を示すとは限りません。サービスで処理に時間がかかる場合があります。

  2. 各コンポーネントの Pod を確認します。

    kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'

    COMPONENT は、コンポーネントの名前に置き換えます。

    次のような出力が表示されます。

    NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h

    READY 列の値が N/N であり、STATUS 列の値が Running であり、RESTARTS の数が 2 の値を超えていないことを確認します。

    再起動回数が多い場合は、次の症状が考えられます。

    • Pod が失敗し、Kubernetes が Pod を再起動します。
    • STATUS 列には CrashLoopBackoff 値が表示されます。

    失敗ステータスを解決するには、Pod のログを表示します。

    Pod が PENDING 状態の場合、この状態は次のいずれかの症状を示します。

    • Pod は、必要なコンテナをダウンロードするためのネットワーク アクセスを待機しています。
    • 構成の問題により、Pod が起動しません。たとえば、Pod に必要な Secret 値がありません。
    • Kubernetes クラスタで Pod をスケジュールするリソースが不足しています。これは、クラスタで多くのアプリケーションが実行されている場合に発生します。

  3. PENDING 状態の原因を特定します。

    kubectl describe -n obs-system pod/POD_NAME

    POD_NAME は、PENDING 状態を示す Pod の名前に置き換えます。

    出力に、Pod の詳細が表示されます。

  4. 出力の Events セクションに移動して、Pod の最近のイベントを一覧表示するテーブルと、PENDING 状態の原因に関する概要を表示します。

    次の出力は、Grafana StatefulSet オブジェクトの Events セクションのサンプルを示しています。

    Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

    Pod や他のリソースでイベントが長期間発生していない場合は、次の出力が表示されます。

      Events:         <none>

オブザーバビリティ ロギング スタックが実行されていることを確認する

次の手順に沿って、ロギング スタックが実行されていることを確認します。

  1. すべての Loki インスタンスまたは Pod に Istio サイドカーが挿入されていることを確認します。anthos-audit-logs-forwarder-SUFFIX と anthos-log-forwarder-SUFFIX という名前のすべての Fluent Bit Pod に Istio サイドカーが挿入されていることを確認します。

  2. すべての Loki インスタンスが組織のインフラストラクチャ クラスタでエラーなく実行されていることを確認します。

  3. anthos-audit-logs-forwarder オブジェクトと anthos-log-forwarder オブジェクトの DaemonSet ステータスを確認して、すべてのインスタンスがすべてのノードでエラーなく実行されていることを確認します。

  4. すべてのクラスタで、過去 5 分間の kube-apiserver-SUFFIX コンテナのオペレーション ログと Kubernetes API サーバーの監査ログを取得していることを確認します。これを行うには、Grafana インスタンスで次のクエリを実行します。

    • 運用ログ: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
    • 監査ログ: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)

    組織インフラストラクチャ クラスタ内のすべてのコントロール プレーン ノードでゼロ以外の値を取得する必要があります。

オブザーバビリティ モニタリング スタックが実行されていることを確認する

次の手順に沿って、モニタリング スタックが実行されていることを確認します。

  1. Grafana インスタンスが組織のインフラストラクチャ クラスタで実行されていることを確認します。grafana-0 Pod は、次の Namespace でエラーなしで実行されている必要があります。

    • obs-system
    • infra-obs-obs-system
    • platform-obs-obs-system

  2. すべてのモニタリング コンポーネントが Istio サービス メッシュ内にあることを確認します。デプロイの失敗を特定するセクションの手順に沿って操作します。次の各 Pod の READY 列に、すべてのコンテナが準備完了と表示されている必要があります。たとえば、値が 3/3 の場合、3 つのコンテナのうち 3 つが準備完了していることを意味します。また、Pod には istio-proxy コンテナが必要です。Pod がこれらの条件を満たしていない場合は、Pod を再起動します。

    Pod 名 準備完了のコンテナ数
    cortex- 2/2
    cortex-etcd-0 2/2
    cortex-proxy-server- 2/2
    cortex-tenant- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server- 2/2
    meta-prometheus-0 4/4
    cortex-alertmanager- 2/2
    cortex-compactor- 2/2
    cortex-distributor- 2/2
    cortex-etcd-0 2/2
    cortex-ingester- 2/2
    cortex-querier- 2/2
    cortex-query-frontend- 2/2
    cortex-query-scheduler- 2/2
    cortex-ruler- 2/2
    cortex-store-gateway- 2/2
    cortex-tenant- 2/2
    grafana-proxy-server- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server-* 2/2
    meta-prometheus-0 4/4

  3. Cortex がエラーなく実行されていることを確認します。

オブザーバビリティ ログを取得する

次の表に、オブザーバビリティ プラットフォームがデプロイする各コンポーネントのログを取得するために実行する必要があるコマンドを示します。

コンポーネント ログ取得コマンド
grafana kubectl logs -n obs-system statefulset/grafana
anthos-prometheus-k8s kubectl logs -n obs-system statefulset/anthos-prometheus-k8s
alertmanager kubectl logs -n obs-system statefulset/alertmanager
ops-logs-loki-io kubectl logs -n obs-system statefulset/ops-logs-loki-io
ops-logs-loki-io-read kubectl logs -n obs-system statefulset/ops-logs-loki-io-read
ops-logs-loki-all kubectl logs -n obs-system statefulset/ops-logs-loki-all
ops-logs-loki-all-read kubectl logs -n obs-system statefulset/ops-logs-loki-all-read
audit-logs-loki-io kubectl logs -n obs-system statefulset/audit-logs-loki-io
audit-logs-loki-io-read kubectl logs -n obs-system statefulset/audit-logs-loki-io-read
audit-logs-loki-pa kubectl logs -n obs-system statefulset/audit-logs-loki-pa
audit-logs-loki-pa-read kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read
audit-logs-loki-all kubectl logs -n obs-system statefulset/audit-logs-loki-all
audit-logs-loki-all-read kubectl logs -n obs-system statefulset/audit-logs-loki-all-read
anthos-log-forwarder kubectl logs -n obs-system daemonset/anthos-log-forwarder
anthos-audit-logs-forwarder kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder
oplogs-forwarder kubectl logs -n obs-system daemonset/oplogs-forwarder
logmon-operator kubectl logs -n obs-system deployment/logmon-operator

コンポーネントの以前のインスタンスのログを表示するには、各コマンドの末尾に -p フラグを追加します。-p フラグを追加すると、現在実行中のインスタンスではなく、以前に失敗したインスタンスのログを確認できます。

構成を表示する

オブザーバビリティ スタックは、Kubernetes API カスタム リソースを使用してモニタリングとロギングのパイプラインを構成します。

LoggingPipeline カスタム リソースは組織のインフラストラクチャ クラスタにデプロイされ、Loki インスタンスを構成します。

次のコマンドは、ロギング パイプラインで実行できる使用可能なアクションを示しています。

  • ロギング パイプラインのデプロイの現在の構成を表示します。

    kubectl get loggingpipeline -n obs-system default -o yaml

  • ロギング パイプラインのデプロイの構成を変更します。

    kubectl edit loggingpipeline -n obs-system default

GDC は、logmon-operator というロギングとモニタリングのオペレータを使用して、Prometheus や Fluent Bit などのオブザーバビリティ コンポーネントのデプロイを管理します。logmon-operator コンポーネントの API は logmon カスタム リソース定義です。logmon カスタム リソース定義は、デプロイのオブザーバビリティを構成する方法を logmon-operator に指示します。このカスタム リソース定義には、指標を保存するボリュームのプロパティ、Alertmanager のアラートルール、指標を収集する Prometheus 構成、ダッシュボードの Grafana 構成が含まれています。

次のコマンドは、logmon カスタム リソース定義で実行できる使用可能なアクションを示しています。

  • オブザーバビリティ デプロイの現在の構成を表示します。

    kubectl get logmon -n obs-system logmon-default -o yaml

  • オブザーバビリティ デプロイの構成を変更します。

    kubectl edit logmon -n obs-system logmon-default

いずれかのコマンドを実行した出力で、構成をさらに行うために複数の Kubernetes ConfigMap オブジェクトが参照されることがあります。たとえば、別の ConfigMap オブジェクトで Alertmanager ルールを構成し、logmon カスタム リソース定義で名前で参照できます。Alertmanager の構成は、gpc-alertmanager-config という名前の logmon カスタム リソース定義を使用して変更および表示できます。

Alertmanager の構成を表示するには、次のコマンドを実行します。

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

一般的な問題

このセクションでは、オブザーバビリティ プラットフォームのデプロイ時に発生する可能性のある一般的な問題について説明します。

Grafana にアクセスできない

デフォルトでは、Grafana は Kubernetes クラスタ外部のマシンに公開されません。組織のインフラストラクチャ クラスタの外部から Grafana インターフェースに一時的にアクセスするには、Service を localhost にポート転送します。Service をポート転送するには、次のコマンドを実行します。

kubectl port-forward -n gpc-system service/grafana 33000\:3000

ウェブブラウザで http://localhost:33000 に移動して、デプロイの Grafana ダッシュボードを表示します。プロセスを終了するには、Ctrl+C キーを押します。

Grafana の動作が遅い

Grafana の動作が遅い場合は、次のことを示しています。

  • Prometheus または Loki へのクエリが過剰なデータを返す。
  • クエリが、1 つのグラフに表示するのに適した量を超えるデータを返す。

Grafana 内の速度低下を解決するには、カスタム Grafana ダッシュボードのクエリを確認します。クエリが 1 つのグラフに表示するのに適した量を超えるデータを返す場合は、ダッシュボードのパフォーマンスを向上させるために、表示するデータ量を減らすことを検討してください。

Grafana ダッシュボードに指標やログが表示されない

Grafana に指標やログが表示されない原因としては、次のことが考えられます。

  • Grafana データソースが正しく設定されていません。
  • システムでモニタリング データソースまたはロギング データソースへの接続に関する問題が発生している。
  • システムで指標やログが収集されていません。

ログと指標を表示する手順は次のとおりです。

  1. Grafana ユーザー インターフェースで、 [ダッシュボードの設定] をクリックします。
  2. [データソース] を選択します。
  3. [データソース] ページに、次のソースが表示されていることを確認します。
名前 組織 URL
Audit Logs All http://audit-logs-loki-io-read.obs-system.svc:3100
Operational Logs Root http://ops-logs-loki-io-read.obs-system.svc:3100
Operational Logs Org http://ops-logs-loki-all-read.obs-system.svc:3100
prometheus http://anthos-prometheus-k8s.obs-system.svc:9090

これらのデータソースがない場合は、オブザーバビリティ スタックが Grafana を正しく構成できなかったことを示します。

データソースを正しく構成してもデータが表示されない場合は、Prometheus または Loki にフィードする指標またはログを収集する Service オブジェクトに問題がある可能性があります。

Prometheus は指標を収集するときに、pull モデルに従って Service オブジェクトの指標を定期的にクエリし、検出された値を保存します。Prometheus が指標収集用の Service オブジェクトを検出するには、次の条件を満たしている必要があります。

  • Service オブジェクトのすべての Pod に 'monitoring.gke.io/scrape: "true"' のアノテーションが付けられます。

  • Prometheus 指標形式は、HTTP 経由で Pod 指標を公開します。デフォルトでは、Prometheus はエンドポイント http://POD_NAME:80/metrics でこれらの指標を検索します。必要に応じて、アノテーションを使用してポート、エンドポイント、スキーマをオーバーライドできます。

Fluent Bit はログを収集し、Kubernetes クラスタのすべてのノードで実行されるように設計されています。Fluent Bit は、長期保存のためにログを Loki に送信します。

Grafana にログが表示されない場合は、次の回避策をお試しください。

  • Loki インスタンスのログを調べて、エラーなく実行されていることを確認します。

  • Loki インスタンスが正常に実行されているのにログが表示されない場合は、Fluent Bit のログを調べて、サービスが想定どおりに動作していることを確認します。ログを pull する方法については、オブザーバビリティ ログを取得するをご覧ください。

Alertmanager がアラートを開かない

Alertmanager がアラートを開けない場合は、次の手順を行います。

  1. gpc-system 名前空間内の configMap オブジェクトで、ラベル logmon: system_metrics が存在することを確認します。
  2. configMap データ セクションに alertmanager.yml という名前のキーが含まれていることを確認します。alertmanager.yml キーの値は、有効な Alertmanager 構成ファイルに含まれるアラートルールである必要があります。

  3. gpc-system Namespace の logmon-default という名前の logmon カスタム リソース定義に configMap オブジェクトへの参照が含まれていることを確認します。logmon-default カスタム リソース定義には、次の例に示すように、configMap オブジェクトの名前を含める必要があります。

    apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config

    例の alerts-config の値は、configMap オブジェクトの名前です。

Alertmanager が構成された通知チャンネルにアラートを送信しない

構成エラーが発生すると、Alertmanager が Grafana インスタンスでアラートを生成しても、Slack などの通知チャンネルとして構成した外部ソフトウェアで通知を受信できないことがあります。

外部ソフトウェアでアラートを受け取る手順は次のとおりです。

  1. Alertmanager 構成ファイルの値が正しくフォーマットされていることを確認します。Alertmanager がアラートをトリガーすると、外部ソフトウェアの Webhook にクエリが送信されます。

  2. 外部ソフトウェアに接続する Webhook URL が正しいことを確認します。URL が正しい場合は、Webhook を受け入れるようにソフトウェアが構成されていることを確認します。外部サービス API にアクセスするために API キーを生成する必要があるか、現在の API キーが期限切れで、更新する必要がある可能性があります。

  3. 外部サービスが GDC のエアギャップ アプライアンスのデプロイの外にある場合は、組織インフラストラクチャ クラスタに下り（外向き）ルールが構成されていることを確認します。この構成により、Alertmanager は内部 Kubernetes ネットワークの外部にあるサービスにリクエストを送信できます。下り（外向き）ルールを検証できないと、Alertmanager が外部ソフトウェアを見つけられない可能性があります。

プロジェクト スコープのワークロードの指標が表示されない

次の手順に沿って、回避策を適用し、ワークロードから指標を取得します。

  1. MonitoringTarget カスタム リソースのステータスが Ready であることを確認します。
  2. ワークロードをスクレイピングするには、ワークロードの Pod 仕様で MonitoringTarget に指定されたすべてのターゲット情報を宣言する必要があります。たとえば、指標がポート 8080 で使用可能であることを宣言する場合、ワークロード Pod は Kubernetes に対してポート 8080 が開いていることを宣言する必要があります。それ以外の場合、Prometheus はワークロードを無視します。
  3. Prometheus は複数のシャードを実行します。つまり、すべての Prometheus Pod が Pod をスクレイピングするとは限りません。各 Prometheus Pod の名前でシャード番号を確認できます。たとえば、primary-prometheus-shard0-replica0-0 はシャード 0 の一部です。各 Prometheus シャードからスクレイピングする Pod を確認します。
    1. obs-system Namespace の Prometheus の primary-prometheus-shardSHARD_NUMBER-replica0-0 Pod をポート転送して、Prometheus UI にアクセスします。新しいシャードを確認するたびに、Pod 名の SHARD_NUMBER を増分する数値に置き換えます。
    2. ウェブブラウザで Prometheus UI に移動し、次の操作を行います。
      1. [ステータス] > [ターゲット] の順にクリックします。
      2. スクレイピングする Pod がリストに含まれていることを確認します。そうでない場合は、次のシャードを確認します。確認するシャードがなくなったら、Prometheus が検出するのに十分な情報があることを再検証します。
    3. Prometheus の primary-prometheus-shardSHARD_NUMBER-replica0-0 Pod が obs-system Namespace でエラーをログに記録していることを確認します。
  4. cortex-tenant Pod が obs-system Namespace でエラーをログに記録していることを確認します。

ダッシュボードが作成されなかった

次の手順に沿って、回避策を適用し、ダッシュボードが作成されない理由を確認します。

  1. Dashboard カスタム リソースのステータスを確認して、エラーがないか確認します。カスタム リソースには Ready ステータスが必要です。
  2. 正しい Grafana インスタンスを確認していることを確認します。たとえば、my-namespace という名前のプロジェクト Namespace にダッシュボードをデプロイした場合、ダッシュボードは https://GDCH_URL/my-namespace/grafana エンドポイントの Grafana インスタンスに存在する必要があります。
  3. gpc-system Namespace の fleet-admin-controller のログを確認します。ログでダッシュボード名を検索して、ダッシュボードに関連するエラーを探します。エラーが見つかった場合は、configMap オブジェクトの JSON ファイルの形式が正しくないため、修正する必要があります。
  4. PROJECT_NAME-obs-system Namespace の Grafana ログを調べて、エラーがないか確認します。ダッシュボードは Grafana REST API をクエリするため、ダッシュボードを作成するには Grafana が動作している必要があります。

アラートが開かない

次の手順に沿って、回避策を適用し、アラートが開かない理由を特定します。

  1. Cortex と Loki の両方がバケット ストレージ モードになっていることを確認します。バックエンドがバケット ストレージでバックアップされていない場合、ルールは機能しません。
  2. MonitoringRule カスタム リソースと LoggingRule カスタム リソースのステータスが Ready であることを確認します。
  3. 次のアラート条件を確認します。
    • PromQL 式と LogQL 式: 使用しているすべての関数をアラート ルールの作成に関するドキュメントと比較して、ルールが意図したとおりに構成されていることを確認します。式が true 値または false 値を返すことを確認します。
    • 期間: カスタム リソースの for フィールドは、条件が true である必要がある期間を定義します。interval フィールドは、条件を評価する頻度を定義します。これらのフィールドの値を相互に照合し、条件が論理的であることを確認します。
  4. Grafana UI の [アラート] ページで、アラートが開いているかどうかを確認します。
  5. Grafana でアラートが開いていることが示されている場合は、通知チャネルを確認し、Alertmanager がアラートを生成するために通知チャネルにアクセスできることを確認します。

想定されるログが使用できない

コンポーネントのオペレーション ログが表示されない場合は、次の手順を行います。

  1. コンポーネントが実行され、ログが生成されているかどうかを確認します。
  2. コンポーネント ログを組み込み機能として収集する必要があるかどうかを確認します。そうでない場合は、有効な仕様と Ready ステータスで LoggingTarget カスタム リソースがデプロイされていることを確認します。

コンポーネントの監査ログが表示されない場合は、次の手順を行います。

  1. コンポーネントがファイルにログを書き込む場合は、パス /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log のノードのファイル システムにファイルが実際に存在することを確認します。
  2. 同じノードの anthos-audit-logs-forwarder-SUFFIX Pod にエラーがないことを確認します。
  3. コンポーネントが syslog エンドポイントを使用してログを受信する場合は、有効な仕様と Ready ステータスで AuditLoggingTarget カスタム リソースがデプロイされていることを確認します。

事前定義のアラートルールを特定する

このセクションでは、システム障害を通知するためにオブザーバビリティ コンポーネントに存在する事前定義のアラートルールについて説明します。

Loki の事前定義アラートルール

次の表に、監査ロギングの失敗に関する Loki のプリインストールされたアラート ルールを示します。

監査ロギングの失敗に関する Loki の事前インストール済みアラート ルール
名前 型 説明
FluentBitAuditLoggingWriteFailure 重大 Fluent Bit が過去 5 分間に監査ログを転送できませんでした。
LokiAuditLoggingWriteFailure 重大 Loki が監査ログをバックエンド ストレージに書き込めませんでした。

これらのアラートが 1 つ以上表示された場合、システムは 1 つ以上の監査レコードを失っています。

Prometheus の事前定義アラートルール

次の表に、Kubernetes コンポーネントの Prometheus にプリインストールされているアラートルールを示します。

Prometheus にプリインストールされているアラートルール
名前 型 説明
KubeAPIDown 重大 Kube API が Prometheus ターゲットの検出から 15 分間、表示されなくなりました。
KubeClientErrors 警告 Kubernetes API サーバー クライアントのエラー率が 15 分間 0.01 を超えています。
KubeClientErrors 重大 Kubernetes API サーバー クライアントのエラー率が 15 分間 0.1 を超えています。
KubePodCrashLooping 警告 Pod がクラッシュ ループ状態のまま 15 分以上経過しています。
KubePodNotReady 警告 Pod が 15 分以上準備されていない状態です。
KubePersistentVolumeFillingUp 重大 要求された PersistentVolume オブジェクトのフリーバイトが 0.03 未満です。
KubePersistentVolumeFillingUp 警告 要求された PersistentVolume オブジェクトのフリーバイトが 0.15 未満です。
KubePersistentVolumeErrors 重大 永続ボリュームが 5 分間 Failed または Pending フェーズにあります。
KubeNodeNotReady 警告 ノードが 15 分以上準備できていません。
KubeNodeCPUUsageHigh 重大 ノードの CPU 使用率が 80% を超えています。
KubeNodeMemoryUsageHigh 重大 ノードのメモリ使用率が 80% を超えている。
NodeFilesystemSpaceFillingUp 警告 ノードのファイル システムの使用率が 60% を超えています。
NodeFilesystemSpaceFillingUp 重大 ノードのファイル システムの使用率が 85% を超えています。
CertManagerCertExpirySoon 警告 証明書の有効期限が 21 日後に切れます。
CertManagerCertNotReady 重大 10 分後にトラフィックを処理するための証明書が準備ができていません。
CertManagerHittingRateLimits 重大 5 分間にわたり、証明書の作成または更新のレート制限に達しました。
DeploymentNotReady 重大 組織のインフラストラクチャ クラスタの Deployment が 15 分以上準備されていない状態です。
StatefulSetNotReady 重大 組織インフラストラクチャ クラスタの StatefulSet オブジェクトが 15 分以上準備されていない状態です。
AuditLogsForwarderDown 重大 anthos-audit-logs-forwarder DaemonSet が 15 分以上ダウンしています。
AuditLogsLokiDown 重大 audit-logs-loki StatefulSet が 15 分以上準備されていない状態です。