gke-observability

GKE のオブザーバビリティ

このリファレンスでは、GKE のモニタリング、ロギング、メトリクスの設定について説明します。 ゴールデンパスでは、コントロールプレーンのメトリクスを含む包括的なオブザーバビリティが有効になります。

MCP ツール： get_cluster、list_k8s_events、get_k8s_logs、 get_k8s_cluster_info、describe_k8s_resource。CLI のみ： gcloud container clusters update --monitoring=...、gcloud logging read

利用状況の帰属情報

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、 利用状況の帰属情報を必ずお読みください。ターミナルで直接実行するコマンド（生成されたスクリプト、Terraform、ユーザーコード内では実行しないでください）では、 gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-observability)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:gke-observability) を追加してください。

ゴールデンパスのオブザーバビリティのデフォルト設定

設定	ゴールデンパスの値	備考
loggingConfig components	SYSTEM_COMPONENTS, WORKLOADS	ワークロードのロギングをすべて有効化
monitoringConfig components	SYSTEM_COMPONENTS, STORAGE, POD, DEPLOYMENT, STATEFULSET, DAEMONSET, HPA, JOBSET, CADVISOR, KUBELET, DCGM, APISERVER, SCHEDULER, CONTROLLER_MANAGER	コントロールプレーンを含むフルスイート
managedPrometheusConfig.enabled	true	Google 管理の Prometheus
advancedDatapathObservabilityConfig.enableMetrics	true	Dataplane V2 のフローメトリクス
loggingService	logging.googleapis.com/kubernetes	Cloud Logging
monitoringService	monitoring.googleapis.com/kubernetes	Cloud Monitoring

コントロールプレーンのメトリクス（ゴールデンパスへの追加）

ゴールデンパスでは、デフォルトのクラスターには含まれない次の3つのコントロールプレーン監視コンポーネントが追加されます。

コンポーネント	監視対象
APISERVER	API サーバーのリクエストレイテンシ、エラー率、アドミッション Webhook のパフォーマンス
SCHEDULER	スケジューリングのレイテンシ、保留中のポッド、スケジューリングの失敗
CONTROLLER_MANAGER	コントローラーの作業キューの深さ、調整のレイテンシ

これらは、クラスター全体の問題（API 応答の遅延、スケジューリングの遅延、停止したコントローラー）を診断するうえで重要です。

以下のコントロールプレーンメトリクスを推奨する場合は、必ず Managed Service for Prometheus（GMP）のメトリクスであり、明示的な有効化（--monitoring=SYSTEM,API_SERVER,... および --enable-managed-prometheus）が必要であることを伝え、次のリンクを記載してください。 https://docs.cloud.google.com/kubernetes-engine/docs/how-to/control-plane-metrics:

• リソース別の API ストレージ使用量 (apiserver_resource_size_estimate_bytes)：apiserver_resource_size_estimate_bytes（group および resource でグループ化）を使用して、etcd 内でどの Kubernetes リソースタイプが最も多くの API サーバーのストレージバイトを消費しているかを特定します。オブジェクト数 (apiserver_storage_objects) とデータベース全体のサイズ (apiserver_storage_size_bytes) を補完するメトリクスです。
• アドミッション Webhook のレイテンシとタイムアウト (apiserver_admission_webhook_admission_duration_seconds)：API 呼び出しがタイムアウトまたは失敗し、変更または検証を行うアドミッション Webhook が疑われる場合は、オプトインの GMP メトリクス apiserver_admission_webhook_admission_duration_seconds（name、 type、operation、rejected でグループ化）をクエリして、遅い、または失敗している Webhook を特定します。また、ValidatingWebhookConfiguration / MutatingWebhookConfiguration の timeoutSeconds、failurePolicy、namespaceSelector の除外（kube-system など）、およびバックエンドの Webhook Service／Pod の健全性も確認してください。

監視をすべて有効にする

--monitoring コマンドを提示するときは、必ず次の点を伝えてください。

1. コントロールプレーンのメトリクスはデフォルトでは有効になっていません。 回答で明言してください。有効化コマンドを提示した事実から暗示するだけにしてはいけません。新しいクラスターでは API_SERVER、SCHEDULER、CONTROLLER_MANAGER はすべてオフで、明示的に有効にするまでデータを収集しません。同様に DCGM、CADVISOR、KUBELET、kube-state（POD、DEPLOYMENT、STATEFULSET、DAEMONSET、HPA、STORAGE、JOBSET）もオフです。デフォルトで有効なのは SYSTEM のみです。「なぜ API サーバーのメトリクスがないのか」と質問するユーザーの大半は、単に一度も有効にしていません。
2. このフラグは追加ではなく、置き換えです。 --monitoring に指定したセットは以前の設定全体を上書きするため、コンポーネントを省略すると、そのコンポーネントは暗黙に無効になります。希望するリスト全体を必ず指定し、常に SYSTEM を含めてください。監視が有効な間は無効にできず、Autopilot でも無効にできません。
3. これらのメトリクスは取り込みサンプルごとに課金されます。 Managed Service for Prometheus を通じて課金されます。大規模クラスターですべてのメトリクスを有効にすると、実際にコストが増加します。リストを無料であるかのように提示せず、その点にも触れてください。

gcloud フラグと API フィールドでは、同じコンポーネント名の表記が異なります。 名前を相互に転記しないでください。

コンポーネント	gcloud --monitoring=	monitoringConfig API enum
システム	SYSTEM	SYSTEM_COMPONENTS
API サーバー	API_SERVER	APISERVER
コントローラーマネージャー	CONTROLLER_MANAGER	CONTROLLER_MANAGER

残りのコンポーネントは同じ表記です。CLI フラグに API enum を使う（またはその逆を行う）と、コマンドは失敗します。これはよくある、わかりにくいエラーです。

# Enable golden path monitoring suite
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,STORAGE,POD,DEPLOYMENT,STATEFULSET,DAEMONSET,HPA,JOBSET,CADVISOR,KUBELET,DCGM \
  --quiet

# Enable Managed Prometheus
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-managed-prometheus \
  --quiet

# Enable Dataplane V2 observability metrics
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-dataplane-v2-flow-observability \
  --quiet

Managed Prometheus

Golden path では、メトリクスの収集とクエリに Google Managed Prometheus を利用できます。

メトリクスのクエリ：

• コンソールで Cloud Monitoring Metrics Explorer を使用します
• Prometheus UI または API 経由で PromQL を使用します
• Managed Grafana 経由で Grafana ダッシュボードを使用します

主な GKE メトリクス：

メトリクス	ソース	用途
container_cpu_usage_seconds_total	cAdvisor	Pod の CPU 使用量
container_memory_working_set_bytes	cAdvisor	Pod のメモリ使用量
kube_pod_status_phase	kube-state-metrics	Pod のライフサイクル
apiserver_request_duration_seconds	API Server	コントロールプレーンのレイテンシ
scheduler_scheduling_attempt_duration_seconds	Scheduler	スケジューリングのパフォーマンス
kubernetes.io/node/cpu/core_usage_time	Cloud Monitoring	ノードの CPU
DCGM_FI_DEV_GPU_UTIL	DCGM	GPU の使用率

ライブのリソース使用量（kubectl のみ）

ライブのリソース使用量を確認する MCP または gcloud の同等機能はありません。kubectl top を使用してください。

kubectl top pods --all-namespaces --sort-by=cpu
kubectl top nodes
kubectl top pods --containers -n <NAMESPACE>  # per-container breakdown

Cloud Logging（gcloud のみ）

クラスターログのクエリ（MCP の同等機能はありません。gcloud logging read を使用してください）：

# System component logs
gcloud logging read \
  'resource.type="k8s_cluster" AND resource.labels.cluster_name="<CLUSTER_NAME>"' \
  --project <PROJECT_ID> --limit 50 \
  --quiet

# Workload logs for a specific namespace
gcloud logging read \
  'resource.type="k8s_container" AND resource.labels.cluster_name="<CLUSTER_NAME>" AND resource.labels.namespace_name="<NAMESPACE>"' \
  --project <PROJECT_ID> --limit 50 \
  --quiet

# Audit logs (who did what)
gcloud logging read \
  'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"' \
  --project <PROJECT_ID> --limit 50 \
  --quiet

診断設定

セキュリティ監視とトラブルシューティングのため、コントロールプレーンの監査ログを有効にしてください。

# View current logging config
gcloud container clusters describe <CLUSTER_NAME> --region <REGION> \
  --format="yaml(loggingConfig)" \
  --quiet

コントロールプレーンコンポーネントのログと遅いリクエストのトレース

kube-apiserver のコンポーネントログ（API_SERVER）は、デフォルトでは有効になっていないオプション機能であり、明示的に有効にする必要があります （--logging=SYSTEM,WORKLOADS,API_SERVER）。apiserver のログ分析を推奨する場合は、必ずこの点に触れ、 https://docs.cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs へのリンクを記載してください。

特定の kube-apiserver リクエストが遅かった原因を診断するには、次の手順に従います。

1. trace または Trace のエントリを検索する：apiserver コンポーネントログ （resource.type="k8s_control_plane_component" AND resource.labels.component_name="apiserver"）を対象に、trace または Trace をクエリします（例： textPayload:"Trace["）。
2. トレースログの解釈方法：kube-apiserver は、上流の k8s.io/utils/trace パッケージ（trace.go）を使用して、レイテンシのしきい値（通常は 500ms）を超えたリクエストをログに記録します。各トレースヘッダーには、操作（"List"、 "Get"、"Create"、"Patch"）、url、user-agent、audit-id、クライアントの IP、開始タイムスタンプ、total time が記録されます。ヘッダーの下には、ネストされたサブトレースが角括弧 [...] で表示され、しきい値を超えた一連のステップは ---"<StepName>" <duration>ms として表示されます。
3. よくある問題のトレースログ例：
   • etcd／ストレージの読み取りまたは書き込みが遅い（List(recursive=true) etcd3 または GuaranteedUpdate etcd3 が total time の大部分を占める）：

     I1015 11:36:56.835120      10 trace.go:236] Trace[123456789]: "List" url:/api/v1/pods,user-agent:my-controller/v1.0.0,audit-id:11111111-2222-3333-4444-555555555555,client:10.0.0.1 (15-Oct-2026 11:36:49.460) (total time: 7374ms):
     Trace[123456789]: ["List(recursive=true) etcd3" 6890ms (11:36:49.461)]
     Trace[123456789]: ---"Objects listed" 6891ms (11:36:56.352)
     Trace[123456789]: ---"SerializeObject" 480ms (11:36:56.832)
     

   • クライアントの処理が遅い／レスポンスストリーミングがボトルネック（"Objects listed" は速いものの、低速または帯域幅が制限されたクライアントが大きなレスポンスペイロードを読み取るのに数秒かかるため、"SerializeObject" と ---"Write call succeeded" または ---"Write call failed" が total time の大部分を占める）：

     I1015 11:40:12.104512      10 trace.go:236] Trace[987654321]: "List" url:/api/v1/pods,user-agent:slow-watcher/v0.1,audit-id:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,client:10.0.0.2 (15-Oct-2026 11:40:01.002) (total time: 11102ms):
     Trace[987654321]: ---"Objects listed" 45ms (11:40:01.047)
     Trace[987654321]: ["SerializeObject" 11055ms (11:40:01.047)]
     Trace[987654321]: ---"Write call succeeded" 11054ms (11:40:12.101)
     

4. 上流のドキュメントと今後の変更（両方とも必ず記載）：trace.go の上流 OSS ドキュメントとして、必ず https://github.com/kubernetes/utils/blob/master/trace/README.md へのリンクを記載してください。また、kube-apiserver のトレース生成方法が将来変更される可能性（OpenTelemetry 経由）として、 https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/647-apiserver-tracing （KEP-647：APIServer Tracing）にも触れてください。

HTTP アクセスログから API サーバーに大きな負荷をかけているクライアントを特定する

kube-apiserver に最も大きな負荷をかけているクライアントを特定するには、apiserver コンポーネントログの httplog.go HTTP アクセスエントリを分析します（明示的に有効化する必要があるオプション機能です。--logging=SYSTEM,WORKLOADS,API_SERVER を指定します。この点を必ず説明し、https://docs.cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs へのリンクを記載してください）。

1. 非常に安定した httplog.go のログ構造（この安定性を必ず説明し、ログ行の例を示してください）：kube-apiserver の httplog.go ログ構造は Kubernetes のリリース間で非常に安定しているため、正規表現による抽出や Log Analytics のクエリを信頼性高く実行できることを明示的に説明し、次のログ行の例を記載してください。

   I1015 11:36:56.835535      10 httplog.go:137] "HTTP" verb="GET" URI="/api/v1/namespaces/default/pods" latency="7.374935s" userAgent="my-controller/v1.0.0 (linux/amd64)" audit-ID="11111111-2222-3333-4444-555555555555" srcIP="10.0.0.1:12345" apf_pl="workload-low" apf_fs="everybody" apf_iseats=1 apf_fseats=0 apf_additionalLatency="0s" apf_execution_time="7.374765s" resp=200
   

2. クライアントの負荷分析に重要なフィールド：
   • user_agent（生ログテキストでは userAgent）：リクエストを発行したクライアントのバイナリ、コントローラー、またはオペレーターを識別します。
   • verb：クラスタ全体に対する LIST や変更を伴う PATCH／UPDATE などの負荷が高いリクエストと、軽量な GET リクエストを区別します。
   • apf_iseats（apf_fseats および apf_execution_time と併せて使用）：リクエストが占有した API Priority and Fairness（APF）の初期同時実行シート数を示します。user_agent と verb ごとに apf_iseats * apf_execution_time を重み付けまたは合計すると、どのクライアントが API サーバーの同時実行容量を最も消費しているかがわかります。

アラート

重要な条件に対するアラートを設定します。

条件	メトリクス	しきい値
API サーバーの高レイテンシ	apiserver_request_duration_seconds	P99 > 5s
Pod のクラッシュループ	kube_pod_container_status_restarts_total	10 分間に > 5
ノードが Ready ではない	kube_node_status_condition	condition=Ready、status!=True
GPU 使用率が高い	DCGM_FI_DEV_GPU_UTIL	> 95% が継続
PVC の容量がひっ迫	kubelet_volume_stats_used_bytes / capacity	> 85%
スケジューリングの失敗	scheduler_schedule_attempts_total{result="error"}	> 0

前提条件： 上記の kube_* 系列（例：kube_pod_status_phase、 kube_pod_container_status_restarts_total、kube_node_status_condition） は kube-state-metrics から取得されます。GKE はデフォルトでは収集しません。 先に Managed Prometheus の kube-state-metrics パッケージをデプロイしてください。

ダッシュボードとアラートの提案（本番環境向けルール）

GKE のアラートとダッシュボードの戦略を設計または提案する際は、次の点に従ってください。

1. これらのアラートとダッシュボードを実装するプラットフォームとして、Google Cloud Monitoring を必ず明記します。
2. ノードの CPU／メモリや Pod のクラッシュループと併せて、コントロールプレーンの健全性を示す重要な指標として、apiserver_request_duration_seconds メトリクスを使った API サーバーのレイテンシを必ずダッシュボードに含めます。

ノードの健全性（本番環境向けルール）

ノードの健全性を包括的に評価するには、次の 2 つの指標を併せて分析します。

1. kubernetes.io/node/status_condition（status_condition="Ready" でフィルタリング）：正常なノードの追跡に使用します。正常にブートストラップされたノードの値のみが報告される点に注意してください。
2. compute.googleapis.com/instance_group/size（instance_group_name="gke-<cluster_name>-.*" でフィルタリング）：特定のクラスター内のノード総数の追跡に使用します。正常なノードと異常なノードは区別されない点に注意してください。

コントロールプレーンの健全性（本番環境向けルール）

Google が GKE クラスターのコントロールプレーンを正常と見なしているかどうかを確認するには、 kubernetes.io/cluster/kcp_healthchecks システム指標を使用します（k8s_cluster 監視対象リソース上にあり、デフォルトの SYSTEM 指標パッケージに含まれています）。

1. 指標の仕様：kubernetes.io/cluster/kcp_healthchecks は、 60 秒ごとにサンプリングされる増分（DELTA / CUMULATIVE カウンター）指標です。success（"true" または "false"）というブール値ラベルが付いた、Google 内部のコントロールプレーンプローブ数をカウントします。
2. 健全性の比率をグラフ化する：この指標はブール値のゲージではなく増分カウンターであるため、成功したチェック（success="true"）のレートを、すべての success 値にわたるチェック全体のレートで割って、コントロールプレーンの可用性をグラフ化します。

sum by (project_id, location, cluster_name) (
  rate(
    kubernetes_io:cluster_kcp_healthchecks{
      monitored_resource="k8s_cluster", success="true"
    }[5m]
  )
)
/
sum by (project_id, location, cluster_name) (
  rate(
    kubernetes_io:cluster_kcp_healthchecks{
      monitored_resource="k8s_cluster"
    }[5m]
  )
)

コストに関する考慮事項

モニタリングとロギングには次のコストがかかります。

• Cloud Logging：無料枠（プロジェクトあたり月 50 GiB）を超えて取り込んだデータ 1 GiB ごとに課金されます
• Cloud Monitoring：GKE システム指標は無料です。カスタム指標は時系列ごとに課金されます
• Managed Prometheus：取り込んだサンプル数に応じて課金されます

本番環境以外でコストを削減するには：

# Reduce to system-only monitoring
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --monitoring=SYSTEM \
  --quiet

分散トレーシングと継続的プロファイリング（推奨）

ゴールデンパスのデフォルト設定には含まれません — 本番環境のマイクロサービスアーキテクチャと、パフォーマンスが重要なワークロードに推奨されます。

• Cloud Trace：opentelemetry-operations-go（または同等の）エクスポーターを使用して、OpenTelemetry SDK をアプリに追加します。トレースは Cloud Trace コンソールに表示されます。サービス間のレイテンシーのボトルネックを特定できます。
• Cloud Profiler：Cloud Profiler エージェントをアプリに追加します。本番環境でオーバーヘッドを抑えながら、CPU とメモリの使用状況をプロファイリングします。ホットスポットを特定し、バージョン間で比較できます。

最近の追加機能：

• GKE 向け Managed OpenTelemetry（プレビュー）：マネージドのクラスター内 OTLP エンドポイントに加え、トレース、指標、ログの自動インストルメンテーションを提供します。GKE 1.34.1-gke.2178000+ が必要です。gcloud beta container clusters update ... --managed-otel-scope=COLLECTION_AND_INSTRUMENTATION_COMPONENTS で有効にします。
• PSI（Pressure Stall Information）指標：cAdvisor の container_pressure_{cpu,memory,io}_{waiting,stalled}_seconds_total 系列 （Kubernetes 1.34 でベータ版）は、Managed Prometheus の ClusterNodeMonitoring リソースを通じて収集できます。GKE のドキュメントに記載された収集方法には GKE 1.35+ が必要です。

LQL クエリの例

GKE のトラブルシューティングでよく使われる Logging Query Language のパターン：

# Error logs for a specific container
resource.type="k8s_container" AND resource.labels.container_name="my-app" AND severity>=ERROR

# OOMKilled events
resource.type="k8s_event" AND jsonPayload.reason="OOMKilling"

# Pod scheduling failures
resource.type="k8s_event" AND jsonPayload.reason="FailedScheduling"

# Audit logs (who did what)
resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"

Managed Prometheus（GMP）のトラブルシューティング

GMP の取り込み、ルール、クエリに関する問題を診断します。読み取り専用操作（kubectl get ／describe／logs）にとどめ、設定変更を提案してください。稼働中のリソースを直接変更しないでください。

まず、取り込み側とクエリ側を切り分ける

何よりも先に、Cloud Monitoring の Metrics Explorer の PromQL タブで up 指標をクエリします。up がデータを返す場合、取り込みは機能しており、問題はクエリ側（Grafana ／ PromQL ／権限）にあります。up が空の場合、問題は取り込み側（コレクター、スクレイプ設定、または書き込み権限）にあります。

取り込み側

1. GMP システムの Pod を確認します。 Standard クラスターでは gmp-system、Autopilot では gke-gmp-system で実行されています。gmp-operator、collector （DaemonSet）、rule-evaluator の状態が Running 以外になっていないか、再起動回数が多くないかを確認します。

   kubectl get pods -n gmp-system            # Autopilot では gke-gmp-system
   kubectl logs -n gmp-system -l app.kubernetes.io/name=collector -c prometheus
   

   OOMKilled によって CrashLoopBackOff になっている collector は、通常、メトリクスのカーディナリティが高いことを示します。不要な系列やラベルを削除する（下記のコストに関するセクションを参照）か、collector に VPA を適用してください。

2. PodMonitoring／ClusterPodMonitoring を確認します。 よくある間違いは次の 3 つです。

   • spec.selector.matchLabels が対象 Pod のラベルと一致していません。
   • PodMonitoring が検出するのは自身の名前空間内のターゲットだけです。クラスター全体を対象とするには ClusterPodMonitoring を使用します。
   • spec.endpoints.port では、ポート番号ではなく、名前付きのコンテナーポート（例：port: web）を指定する必要があります。

3. スクレイプエラーのターゲットステータスを有効にします。 gmp-public の OperatorConfig に features.targetStatus.enabled: true を適用するよう提案してください。 適用後、kubectl describe podmonitoring <name> を実行し、Active Targets、 Unhealthy Targets、Last Error（例：connection refused、HTTP 404、 context deadline exceeded）を確認します。確認が終わったら無効に戻してください。大規模なクラスターでは、operator が OOM になる可能性があります。

権限（403／データが書き込まれない）

GMP コンポーネントはノードのサービスアカウントを継承します。取り込みには roles/monitoring.metricWriter が必要です（collector のログに Permission monitoring.timeSeries.create denied エラーが表示されます）。rule-evaluator とクエリパスには roles/monitoring.viewer が必要です（403／PermissionDenied）。Grafana などのクエリアプリが Workload Identity を使用する場合、紐付けられた Google サービスアカウントにも roles/monitoring.viewer が必要です。

ルールとアラートの評価

ルールのスコープはリソースの種類によって決まります。Rules（単一の名前空間）、 ClusterRules（クラスター全体）、GlobalRules（メトリクススコープ内のすべてのデータ）です。Cloud Monitoring のメトリクスに対するルールを作成するには、必ず GlobalRules を使用してください。Rules／ClusterRules リソースでは、それらのメトリクスに対してデータが返されず、エラーも表示されません。構文解析エラーや権限エラーについては、rule-evaluator のログ（-c evaluator）を確認してください。

クエリ側（Grafana／PromQL）

• データソースは localhost:9090 ではなく、GMP フロントエンドのクエリプロキシを指定する必要があります。また、HTTP Method は GET にする必要があります。POST では no match[] parameter provided が発生します。
• Grafana のテンプレート変数： 2 引数形式の label_values(<metric>, <label>) を使用してください。1 引数形式の label_values(<label>) は GMP API ではサポートされていません。
• 複数のリソースタイプに存在する Cloud Monitoring メトリクスでは、 monitored_resource ラベルのマッチャーが必要です。指定しないとクエリで series selector must specify a label matcher on monitored resource name が発生します。

コスト、カーディナリティ、割り当て量

Cloud Monitoring のメトリクス管理ページで、課金対象のサンプル数や高いカーディナリティの要因となっているメトリクスを特定します。PodMonitoring の metricRelabeling（メトリクス全体を対象とする action: drop、user_id／request_id などの上限のないラベルを対象とする action: labeldrop）を使うか、スクレイプの interval を長くして、これらを削減してください。429／RESOURCE_EXHAUSTED エラーは、Cloud Monitoring API の取り込みまたはクエリの割り当て量に達したことを意味します。まず最適化を行い、その後、割り当て量の引き上げをリクエストしてください。

参考リンク

• GKE のシステム指標
• GKE のオブザーバビリティに関するドキュメント
• Google Cloud Managed Service for Prometheus
• Managed Service for Prometheus のトラブルシューティング
• ルールの評価（Rules / ClusterRules / GlobalRules）
• Cloud Logging クエリ言語（LQL）
• Google Cloud Monitoring のアラート