尧图网页设计 
GKE 告警策略遥测前置条件配置指南为 16 个关键告警打通 Cloud Monitoring 数据链路【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本指南聚焦 gke-alert-configuration 技能中定义的 GKE 集群与 Google Cloud 遥测前置条件配置详细说明如何让 16 个关键告警策略所需的指标控制平面指标、kube-state-metrics 状态指标、工作负载 Golden Signals正确流入 Google Cloud Monitoring / Managed Service for PrometheusGMP。读完本文后你将掌握控制平面指标启用命令、KSM 成本优化抓取配置、PodMonitoring 自定义资源编写方法以及一套从 Terraform 校验到 PromQL 检查再到告警策略核查的完整验证 Runbook。一、遥测摄取架构数据从集群到 Cloud Monitoring 的完整链路在配置任何前置条件之前首先要理解 16 个关键告警依赖的指标分别来自哪条采集链路。下面的架构图源自 gke_configuration_prerequisites.md展示了 GKE 集群内三类遥测源如何汇聚到 Google Cloud Monitoring / GMP链路可归纳为三条并行通道控制平面链路Tier 1Google 托管的 Master 节点上的 Kubernetes API Server 暴露apiserver_*、rest_*系列指标由 GKE 控制平面指标采集器直接写入 Cloud Monitoring无需用户部署任何采集组件但必须在集群配置中显式开启。节点与工作负载链路Tier 1Worker 节点上的 Kubelet 内置 cAdvisor 暴露container_*系列Volume 统计暴露kubelet_volume_*系列由 GMP Operator / PodMonitoring 自定义资源抓取。集群状态链路Tier 2kube-state-metricsKSMPod 暴露kube_*系列集群状态指标同样由 GMP Operator / PodMonitoring 抓取——这条链路会带来可计费指标摄入成本是后续所有成本优化措施的核心对象。二、按告警分类的前置条件矩阵16 个关键告警一表通查下表完整继承自原文档按成本层级Cost Tier列出了 16 个关键告警所需的指标、GKE 集群侧要求以及工作负载/资源侧要求。集群运维人员可据此快速判断某条告警当前是否具备触发条件、还缺什么前置配置。Alert NameCost TierRequired MetricsGKE Cluster RequirementWorkload/Resource RequirementKubernetes Node not readyTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Node memory pressureTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Node disk pressureTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Node network unavailableTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Volume full in four daysTier 1 (Native)kubelet_volume_stats_available_bytesSystem Monitoring EnabledPods with attached volumes (CSI Driver supported)Kubernetes API server errorsTier 1 (Native)apiserver_request_totalControl Plane Metrics EnabledGKE Master nodes activeKubernetes API client errorsTier 1 (Native)rest_client_requests_totalControl Plane Metrics EnabledAPI Clients communicating with API ServerKubernetes client certificate expires soonTier 1 (Native)apiserver_client_certificate_expiration_seconds_countControl Plane Metrics EnabledClient certificate authentication enabledKubernetes CronJob failingTier 2 (KSM)kube_cronjob_status_*,kube_cronjob_spec_*kube-state-metricsScrapedActive CronJobs in clusterKubernetes PersistentVolume errorTier 2 (KSM)kube_persistentvolume_status_phasekube-state-metricsScrapedPersistentVolume resources configuredKubernetes StatefulSet downTier 2 (KSM)kube_statefulset_*kube-state-metricsScrapedStatefulSets deployedKubernetes Pod not healthyTier 2 (KSM)kube_pod_status_phasekube-state-metricsScrapedPods running in target namespacesKubernetes Deployment generation mismatchTier 2 (KSM)kube_deployment_*kube-state-metricsScrapedDeployments deployedKubernetes StatefulSet generation mismatchTier 2 (KSM)kube_statefulset_*kube-state-metricsScrapedStatefulSets deployedKubernetes DaemonSet misscheduledTier 2 (KSM)kube_daemonset_*kube_statefulset_*被误写成kube_daemonset_*DaemonSets deployedKubernetes Job slow completionTier 2 (KSM)kube_job_*kube-state-metricsScrapedJobs deployed说明矩阵中Tier 1 (Native)表示由 GKE 内建 / cAdvisor / Kubelet 原生提供的指标零 KSM 成本附加Tier 2 (KSM)表示依赖kube-state-metrics抓取的集群状态指标需要额外的采集部署与成本投入。完整的分级原则与 KSM 成本护栏见 SKILL.md 与 metrics_and_alerts_catalog.md。三、GKE 控制平面指标Tier 1让 API Server 遥测开始流动KubernetesAPIServerErrors、KubernetesAPIClientErrors、KubernetesClientCertificateExpiresSoon三条控制平面告警依赖 API Server 与 API Client 的遥测数据。默认情况下 GKE 不会抓取 Master 指标必须在集群配置中显式启用。3.1 启用控制平面指标使用gcloud更新集群监控配置gcloud container clusters update CLUSTER_NAME \ --zoneCOMPUTE_ZONE \ --monitoringSYSTEM,API_SERVER,CONTROLLER_MANAGER,SCHEDULER各开关的作用SYSTEM基础系统指标节点、Pod、容器层面的系统遥测是 Node 类告警Not ready、Memory/Disk pressure、Network unavailable和 Volume 类告警的前提通常默认开启。API_SERVER暴露 API Server 请求量、错误率与客户端请求指标直接支撑apiserver_request_total、rest_client_requests_total、apiserver_client_certificate_expiration_seconds_count三条告警。CONTROLLER_MANAGER SCHEDULER可选但推荐暴露 Scheduler 队列指标与 Controller Manager 执行状态为控制平面深度排查提供数据。3.2 验证查询启用后可通过 PromQL 验证 API Server 遥测是否已流入 Cloud Monitoringsum(rate(apiserver_request_total[5m])) by (code)该查询按 HTTP 状态码code聚合最近 5 分钟的请求速率。若返回空结果说明控制平面指标尚未开启或开启后仍在采集缓冲期内通常需等待几分钟。四、Kube-State-MetricsKSMTier 2集群状态指标的成本可控采集所有工作负载类、副本数不匹配类与 CronJob 类告警Deployment/StatefulSet/DaemonSet/CronJob/Job/Pod 状态都需要kube_*集群状态指标。KSM 是开源组件部署到 Google Cloud Managed Service for Prometheus 后会产生可计费指标摄入成本因此技能定义了两条强制护栏先询问再部署当告警依赖 Tier 2 KSM 指标时必须先向用户说明成本影响、获得明确许可后才生成配置详见 SKILL.md 的 Mandatory kube-state-metrics (KSM) Cost Guardrail 一节。优先使用非 KSM 原生替代方案能用 Tier 1 cAdvisor / 原生 GKE 指标如container_memory_working_set_bytes/container_spec_memory_limit_bytes替代kube_pod_container_resource_limits就优先使用。4.1 KSM 抓取配置在 GMP 中收集 KSM 指标需要两步将kube-state-metrics部署到kube-system命名空间部署一个 GMPPodMonitoring自定义资源使其指向 KSM Deployment。4.2 过滤式 PodMonitoring 资源成本优化为避免高昂的样本摄入费用使用metricRelabeling丢弃所有未使用的指标只保留告警所需的kube_*系列。以下配置完整继承自原文档即技能推荐的 Tier 2 白名单模板apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: kube-state-metrics-filtered namespace: kube-system spec: selector: matchLabels: app.kubernetes.io/name: kube-state-metrics endpoints: - port: http-metrics interval: 30s metricRelabeling: - action: keep sourceLabels: [__name__] regex: ^(kube_deployment_.*|kube_statefulset_.*|kube_daemonset_.*|kube_cronjob_.*|kube_job_.*|kube_pod_status_phase|kube_pod_info|kube_pod_container_status_.*|kube_persistentvolume_status_phase)$配置要点解析selector.matchLabels通过app.kubernetes.io/name: kube-state-metrics标签精确匹配 KSM Pod避免误抓其他工作负载。port指向 KSM 容器暴露的http-metrics端口标准 KSM 部署通常命名为此端口。interval: 30sKSM 状态指标变化频率低30 秒抓取间隔可有效控制样本量。metricRelabelingkeep白名单正则^(kube_deployment_.*|kube_statefulset_.*|kube_daemonset_.*|kube_cronjob_.*|kube_job_.*|kube_pod_status_phase|kube_pod_info|kube_pod_container_status_.*|kube_persistentvolume_status_phase)$只保留上述前缀/名称的指标其余全部丢弃。对照 metrics_and_alerts_catalog.md 的告警目录可见这些恰好覆盖 16 条告警中全部 Tier 2 指标族Deployment、StatefulSet、DaemonSet、CronJob、Job、Pod 状态、PersistentVolume 状态与矩阵中的 Required Metrics 一一对应。除了 PodMonitoring 白名单KSM 自身还支持--metric-allowlist启动参数做服务端过滤可在部署清单中与metricRelabeling双保险使用进一步降低摄入量。五、工作负载插桩Golden Signals让应用遥测可被 GMP 抓取Latency延迟、Traffic流量、Error Rates错误率、Saturation饱和度四大 Golden Signals 告警依赖目标工作负载暴露的应用级与运行时遥测。这部分前置条件不在 GKE 集群侧而在应用容器本身。5.1 Prometheus 指标导出器应用容器必须暴露标准的 Prometheus 指标端点例如/metrics端口 8080 或 9090并至少输出http_requests_totalTraffic 与 Errors 信号的原始数据源http_request_duration_seconds_bucketLatency 信号的直方图桶供 P95 分位数计算这两类指标是所有 Golden Signals PromQL 查询的根基——例如 promql_queries.md 中的 P95 延迟查询即基于http_request_duration_seconds_bucket错误率 SLO 查询基于http_requests_total的status~5..过滤。若应用采用 OpenTelemetry 语义约定则对应指标名为http_server_request_duration_milliseconds。5.2 工作负载 PodMonitoring 配置在工作负载所在命名空间创建PodMonitoring资源将应用指标纳入 GMP 采集范围apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: app-metrics-monitoring namespace: default spec: selector: matchLabels: app: my-app endpoints: - port: http-metrics path: /metrics interval: 15s要点selector.matchLabels通过app: my-app定位目标工作负载 Pod。path: /metrics显式指定抓取路径应用默认端点即/metrics时可省略。interval: 15s应用指标变化较快采用 15 秒抓取间隔以获得更灵敏的延迟/错误率检测相比 KSM 的 30s权衡点为样本摄入量。六、Google Cloud IAM 与 API 前置条件赋予部署与评估权限要部署和评估 Terraform 告警策略Google Cloud 侧还需满足两项前置条件。6.1 必需 API启用以下 Google Cloud APIgcloud services enable \ monitoring.googleapis.com \ container.googleapis.com \ cloudresourcemanager.googleapis.commonitoring.googleapis.comCloud Monitoring 与告警策略 APIgoogle_monitoring_alert_policy资源依赖它。container.googleapis.comGKE 集群元数据查询 API。cloudresourcemanager.googleapis.com项目与资源管理 APITerraform provider 配置项目信息时常用。6.2 必需 IAM 角色部署 Terraform 配置的服务账号或用户需要以下角色roles/monitoring.alertPolicyEditor或更高权限的roles/monitoring.editor创建与更新告警策略。roles/monitoring.viewer验证已存在的策略。roles/container.viewer查询集群元数据如 cluster 标签、节点信息供 PromQL 查询中的cluster${var.cluster_name}标签匹配使用。七、验证 Runbook部署后的四步核查流程告警策略部署完成后按以下步骤逐项验证。这是原文档给出的标准 Runbook也是该技能 Plan-Validate-Execute 工作流见 SKILL.md的落地点。7.1 校验 Terraform 语法terraform init terraform validateterraform init下载 provider 插件并初始化工作区terraform validate做静态语法与配置合法性检查确保alerts.tf、variables.tf结构正确。7.2 校验 PromQL 规则python3 scripts/validate_config.py --file alerts.tf该命令调用技能仓库中的 validate_config.py 脚本对alerts.tf内所有google_monitoring_alert_policy资源做解析与 PromQL 静态检查。脚本支持三种模式--plan changes.json校验编辑前起草的变更计划含 proposed 策略、查询与 duration。--directory [TARGET_TF_DIR]扫描目录下全部*.tf文件检测重复目标与语法错误。--file [PATH_TO_TF_FILE]校验单个文件如本步骤。7.3 核查 Cloud Monitoring 告警策略gcloud alpha monitoring policies list \ --filterdisplayName ~ ^\[K8s\] \ --formattable(name,displayName,enabled)按[K8s]前缀过滤已部署策略以表格形式输出name、displayName、enabled三列快速确认所有策略均已创建且处于启用状态。八、从源码看验证脚本PromQL 静态检查究竟在查什么要理解第 7.2 步的校验强度可深入 validate_config.py 的PromQLLinter.lint_query方法源码约第 50-122 行它依次执行五类检查括号配平check_balanced_chars分别检查圆括号()与花括号{}是否成对闭合对应check_balanced_chars(query, (, ))与check_balanced_chars(query, {, })可捕获 PromQL 表达式截断、粘贴错误等低级问题。时间窗口合法性用正则\[([^\]])\]提取所有[...]窗口并校验其匹配\dsmhdw?)?格式——即[5m]、[1h]、[6h:5m]合法而[1month]、[5x]之类的非法窗口会直接报错。offset 偏移格式校验offset 1w、offset 1d等写法必须符合\d[smhdw]防止流量掉零检测等场景中写错偏移单位。Kubernetes 标签引用强制检查查询必须引用cluster、namespace、pod、container、service、job、node、instance等标准标签中的至少一个从规则层面落实技能 Dynamic Multi-Resource Alerting (No Hardcoding) 的要求——禁止告警条件硬编码单实例必须按资源动态分组。lookback 窗口与 duration 冗余规则在validate_plan_file与validate_directory_tf_files中若查询使用了[15m|30m|1h|6h|3d]这类聚合回看窗口、而 Terraformduration不是0s/60s会生成 Duration warning提示查询已使用聚合回看窗口却设置长 duration将造成冗余延迟——这正是技能 No Redundant Duration Windows on Lookbacks 规则的机器化执行。此外HCLScanner.extract_alert_policies通过正则解析 HCL 中的resource google_monitoring_alert_policy name {}块、display_name、PromQLquery同时支持 heredocEOT与双引号字符串两种写法以及filter并依据资源名/显示名中的 latency、error、traffic、saturation、memory、crash、ready 等关键词推断信号类型validate_directory_tf_files还会对同一信号类型出现多条策略的情况输出 Duplicate Target Error防止对同一指标信号重复告警造成噪音。从源码结构看该脚本是一个轻量级、无外部依赖仅用标准库argparse/glob/json/os/re/sys的静态校验器适合在 CI 或本地编辑 Terraform 告警文件时快速门禁。九、前置条件到告警的对应速查何时需要做哪一步将全文要点汇总为一张决策速查表便于按场景直接定位操作场景需要的操作需要 Node / Volume 告警Not ready、Pressure、Volume full确认System Monitoring已启用Volume 类还需 CSI 驱动的 PVC 已挂载需要 API Server / 客户端告警执行gcloud container clusters update --monitoring...,API_SERVER,...并验证apiserver_request_total有数据需要 Deployment/StatefulSet/DaemonSet/CronJob/Job/Pod 状态告警部署 kube-state-metrics 过滤式 PodMonitoring必须先向用户说明成本并获许可需要 Latency/Traffic/Error 告警应用暴露/metrics端点http_requests_total、http_request_duration_seconds_bucket 工作负载 PodMonitoring需要部署/评估 Terraform 告警策略启用 3 个 API授予monitoring.alertPolicyEditor等 3 个角色部署完成后依次执行 terraform validate、validate_config.py、gcloud policies list 三步核查十、相关仓库资料本文涉及的核心源码与配套文档均可在此仓库中继续深入研读前置条件原文档gke_configuration_prerequisites.md技能总览与规则KSM 成本护栏、Golden Signals 覆盖要求、Plan-Validate-Execute 工作流SKILL.md指标与告警目录16 条告警的 PromQL 规则、Tier 1/Tier 2 分级、非 KSM 替代实现metrics_and_alerts_catalog.mdPromQL 查询参考Latency/Traffic/Error/Saturation/健康告警完整查询promql_queries.md验证脚本实现validate_config.py【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GKE 告警策略遥测前置条件配置指南：为 16 个关键告警打通 Cloud Monitoring 数据链路
GKE 告警策略遥测前置条件配置指南为 16 个关键告警打通 Cloud Monitoring 数据链路【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本指南聚焦 gke-alert-configuration 技能中定义的 GKE 集群与 Google Cloud 遥测前置条件配置详细说明如何让 16 个关键告警策略所需的指标控制平面指标、kube-state-metrics 状态指标、工作负载 Golden Signals正确流入 Google Cloud Monitoring / Managed Service for PrometheusGMP。读完本文后你将掌握控制平面指标启用命令、KSM 成本优化抓取配置、PodMonitoring 自定义资源编写方法以及一套从 Terraform 校验到 PromQL 检查再到告警策略核查的完整验证 Runbook。一、遥测摄取架构数据从集群到 Cloud Monitoring 的完整链路在配置任何前置条件之前首先要理解 16 个关键告警依赖的指标分别来自哪条采集链路。下面的架构图源自 gke_configuration_prerequisites.md展示了 GKE 集群内三类遥测源如何汇聚到 Google Cloud Monitoring / GMP链路可归纳为三条并行通道控制平面链路Tier 1Google 托管的 Master 节点上的 Kubernetes API Server 暴露apiserver_*、rest_*系列指标由 GKE 控制平面指标采集器直接写入 Cloud Monitoring无需用户部署任何采集组件但必须在集群配置中显式开启。节点与工作负载链路Tier 1Worker 节点上的 Kubelet 内置 cAdvisor 暴露container_*系列Volume 统计暴露kubelet_volume_*系列由 GMP Operator / PodMonitoring 自定义资源抓取。集群状态链路Tier 2kube-state-metricsKSMPod 暴露kube_*系列集群状态指标同样由 GMP Operator / PodMonitoring 抓取——这条链路会带来可计费指标摄入成本是后续所有成本优化措施的核心对象。二、按告警分类的前置条件矩阵16 个关键告警一表通查下表完整继承自原文档按成本层级Cost Tier列出了 16 个关键告警所需的指标、GKE 集群侧要求以及工作负载/资源侧要求。集群运维人员可据此快速判断某条告警当前是否具备触发条件、还缺什么前置配置。Alert NameCost TierRequired MetricsGKE Cluster RequirementWorkload/Resource RequirementKubernetes Node not readyTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Node memory pressureTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Node disk pressureTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Node network unavailableTier 1 (Native)kube_node_status_conditionSystem Monitoring EnabledGKE Nodes running standard KubeletKubernetes Volume full in four daysTier 1 (Native)kubelet_volume_stats_available_bytesSystem Monitoring EnabledPods with attached volumes (CSI Driver supported)Kubernetes API server errorsTier 1 (Native)apiserver_request_totalControl Plane Metrics EnabledGKE Master nodes activeKubernetes API client errorsTier 1 (Native)rest_client_requests_totalControl Plane Metrics EnabledAPI Clients communicating with API ServerKubernetes client certificate expires soonTier 1 (Native)apiserver_client_certificate_expiration_seconds_countControl Plane Metrics EnabledClient certificate authentication enabledKubernetes CronJob failingTier 2 (KSM)kube_cronjob_status_*,kube_cronjob_spec_*kube-state-metricsScrapedActive CronJobs in clusterKubernetes PersistentVolume errorTier 2 (KSM)kube_persistentvolume_status_phasekube-state-metricsScrapedPersistentVolume resources configuredKubernetes StatefulSet downTier 2 (KSM)kube_statefulset_*kube-state-metricsScrapedStatefulSets deployedKubernetes Pod not healthyTier 2 (KSM)kube_pod_status_phasekube-state-metricsScrapedPods running in target namespacesKubernetes Deployment generation mismatchTier 2 (KSM)kube_deployment_*kube-state-metricsScrapedDeployments deployedKubernetes StatefulSet generation mismatchTier 2 (KSM)kube_statefulset_*kube-state-metricsScrapedStatefulSets deployedKubernetes DaemonSet misscheduledTier 2 (KSM)kube_daemonset_*kube_statefulset_*被误写成kube_daemonset_*DaemonSets deployedKubernetes Job slow completionTier 2 (KSM)kube_job_*kube-state-metricsScrapedJobs deployed说明矩阵中Tier 1 (Native)表示由 GKE 内建 / cAdvisor / Kubelet 原生提供的指标零 KSM 成本附加Tier 2 (KSM)表示依赖kube-state-metrics抓取的集群状态指标需要额外的采集部署与成本投入。完整的分级原则与 KSM 成本护栏见 SKILL.md 与 metrics_and_alerts_catalog.md。三、GKE 控制平面指标Tier 1让 API Server 遥测开始流动KubernetesAPIServerErrors、KubernetesAPIClientErrors、KubernetesClientCertificateExpiresSoon三条控制平面告警依赖 API Server 与 API Client 的遥测数据。默认情况下 GKE 不会抓取 Master 指标必须在集群配置中显式启用。3.1 启用控制平面指标使用gcloud更新集群监控配置gcloud container clusters update CLUSTER_NAME \ --zoneCOMPUTE_ZONE \ --monitoringSYSTEM,API_SERVER,CONTROLLER_MANAGER,SCHEDULER各开关的作用SYSTEM基础系统指标节点、Pod、容器层面的系统遥测是 Node 类告警Not ready、Memory/Disk pressure、Network unavailable和 Volume 类告警的前提通常默认开启。API_SERVER暴露 API Server 请求量、错误率与客户端请求指标直接支撑apiserver_request_total、rest_client_requests_total、apiserver_client_certificate_expiration_seconds_count三条告警。CONTROLLER_MANAGER SCHEDULER可选但推荐暴露 Scheduler 队列指标与 Controller Manager 执行状态为控制平面深度排查提供数据。3.2 验证查询启用后可通过 PromQL 验证 API Server 遥测是否已流入 Cloud Monitoringsum(rate(apiserver_request_total[5m])) by (code)该查询按 HTTP 状态码code聚合最近 5 分钟的请求速率。若返回空结果说明控制平面指标尚未开启或开启后仍在采集缓冲期内通常需等待几分钟。四、Kube-State-MetricsKSMTier 2集群状态指标的成本可控采集所有工作负载类、副本数不匹配类与 CronJob 类告警Deployment/StatefulSet/DaemonSet/CronJob/Job/Pod 状态都需要kube_*集群状态指标。KSM 是开源组件部署到 Google Cloud Managed Service for Prometheus 后会产生可计费指标摄入成本因此技能定义了两条强制护栏先询问再部署当告警依赖 Tier 2 KSM 指标时必须先向用户说明成本影响、获得明确许可后才生成配置详见 SKILL.md 的 Mandatory kube-state-metrics (KSM) Cost Guardrail 一节。优先使用非 KSM 原生替代方案能用 Tier 1 cAdvisor / 原生 GKE 指标如container_memory_working_set_bytes/container_spec_memory_limit_bytes替代kube_pod_container_resource_limits就优先使用。4.1 KSM 抓取配置在 GMP 中收集 KSM 指标需要两步将kube-state-metrics部署到kube-system命名空间部署一个 GMPPodMonitoring自定义资源使其指向 KSM Deployment。4.2 过滤式 PodMonitoring 资源成本优化为避免高昂的样本摄入费用使用metricRelabeling丢弃所有未使用的指标只保留告警所需的kube_*系列。以下配置完整继承自原文档即技能推荐的 Tier 2 白名单模板apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: kube-state-metrics-filtered namespace: kube-system spec: selector: matchLabels: app.kubernetes.io/name: kube-state-metrics endpoints: - port: http-metrics interval: 30s metricRelabeling: - action: keep sourceLabels: [__name__] regex: ^(kube_deployment_.*|kube_statefulset_.*|kube_daemonset_.*|kube_cronjob_.*|kube_job_.*|kube_pod_status_phase|kube_pod_info|kube_pod_container_status_.*|kube_persistentvolume_status_phase)$配置要点解析selector.matchLabels通过app.kubernetes.io/name: kube-state-metrics标签精确匹配 KSM Pod避免误抓其他工作负载。port指向 KSM 容器暴露的http-metrics端口标准 KSM 部署通常命名为此端口。interval: 30sKSM 状态指标变化频率低30 秒抓取间隔可有效控制样本量。metricRelabelingkeep白名单正则^(kube_deployment_.*|kube_statefulset_.*|kube_daemonset_.*|kube_cronjob_.*|kube_job_.*|kube_pod_status_phase|kube_pod_info|kube_pod_container_status_.*|kube_persistentvolume_status_phase)$只保留上述前缀/名称的指标其余全部丢弃。对照 metrics_and_alerts_catalog.md 的告警目录可见这些恰好覆盖 16 条告警中全部 Tier 2 指标族Deployment、StatefulSet、DaemonSet、CronJob、Job、Pod 状态、PersistentVolume 状态与矩阵中的 Required Metrics 一一对应。除了 PodMonitoring 白名单KSM 自身还支持--metric-allowlist启动参数做服务端过滤可在部署清单中与metricRelabeling双保险使用进一步降低摄入量。五、工作负载插桩Golden Signals让应用遥测可被 GMP 抓取Latency延迟、Traffic流量、Error Rates错误率、Saturation饱和度四大 Golden Signals 告警依赖目标工作负载暴露的应用级与运行时遥测。这部分前置条件不在 GKE 集群侧而在应用容器本身。5.1 Prometheus 指标导出器应用容器必须暴露标准的 Prometheus 指标端点例如/metrics端口 8080 或 9090并至少输出http_requests_totalTraffic 与 Errors 信号的原始数据源http_request_duration_seconds_bucketLatency 信号的直方图桶供 P95 分位数计算这两类指标是所有 Golden Signals PromQL 查询的根基——例如 promql_queries.md 中的 P95 延迟查询即基于http_request_duration_seconds_bucket错误率 SLO 查询基于http_requests_total的status~5..过滤。若应用采用 OpenTelemetry 语义约定则对应指标名为http_server_request_duration_milliseconds。5.2 工作负载 PodMonitoring 配置在工作负载所在命名空间创建PodMonitoring资源将应用指标纳入 GMP 采集范围apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: app-metrics-monitoring namespace: default spec: selector: matchLabels: app: my-app endpoints: - port: http-metrics path: /metrics interval: 15s要点selector.matchLabels通过app: my-app定位目标工作负载 Pod。path: /metrics显式指定抓取路径应用默认端点即/metrics时可省略。interval: 15s应用指标变化较快采用 15 秒抓取间隔以获得更灵敏的延迟/错误率检测相比 KSM 的 30s权衡点为样本摄入量。六、Google Cloud IAM 与 API 前置条件赋予部署与评估权限要部署和评估 Terraform 告警策略Google Cloud 侧还需满足两项前置条件。6.1 必需 API启用以下 Google Cloud APIgcloud services enable \ monitoring.googleapis.com \ container.googleapis.com \ cloudresourcemanager.googleapis.commonitoring.googleapis.comCloud Monitoring 与告警策略 APIgoogle_monitoring_alert_policy资源依赖它。container.googleapis.comGKE 集群元数据查询 API。cloudresourcemanager.googleapis.com项目与资源管理 APITerraform provider 配置项目信息时常用。6.2 必需 IAM 角色部署 Terraform 配置的服务账号或用户需要以下角色roles/monitoring.alertPolicyEditor或更高权限的roles/monitoring.editor创建与更新告警策略。roles/monitoring.viewer验证已存在的策略。roles/container.viewer查询集群元数据如 cluster 标签、节点信息供 PromQL 查询中的cluster${var.cluster_name}标签匹配使用。七、验证 Runbook部署后的四步核查流程告警策略部署完成后按以下步骤逐项验证。这是原文档给出的标准 Runbook也是该技能 Plan-Validate-Execute 工作流见 SKILL.md的落地点。7.1 校验 Terraform 语法terraform init terraform validateterraform init下载 provider 插件并初始化工作区terraform validate做静态语法与配置合法性检查确保alerts.tf、variables.tf结构正确。7.2 校验 PromQL 规则python3 scripts/validate_config.py --file alerts.tf该命令调用技能仓库中的 validate_config.py 脚本对alerts.tf内所有google_monitoring_alert_policy资源做解析与 PromQL 静态检查。脚本支持三种模式--plan changes.json校验编辑前起草的变更计划含 proposed 策略、查询与 duration。--directory [TARGET_TF_DIR]扫描目录下全部*.tf文件检测重复目标与语法错误。--file [PATH_TO_TF_FILE]校验单个文件如本步骤。7.3 核查 Cloud Monitoring 告警策略gcloud alpha monitoring policies list \ --filterdisplayName ~ ^\[K8s\] \ --formattable(name,displayName,enabled)按[K8s]前缀过滤已部署策略以表格形式输出name、displayName、enabled三列快速确认所有策略均已创建且处于启用状态。八、从源码看验证脚本PromQL 静态检查究竟在查什么要理解第 7.2 步的校验强度可深入 validate_config.py 的PromQLLinter.lint_query方法源码约第 50-122 行它依次执行五类检查括号配平check_balanced_chars分别检查圆括号()与花括号{}是否成对闭合对应check_balanced_chars(query, (, ))与check_balanced_chars(query, {, })可捕获 PromQL 表达式截断、粘贴错误等低级问题。时间窗口合法性用正则\[([^\]])\]提取所有[...]窗口并校验其匹配\dsmhdw?)?格式——即[5m]、[1h]、[6h:5m]合法而[1month]、[5x]之类的非法窗口会直接报错。offset 偏移格式校验offset 1w、offset 1d等写法必须符合\d[smhdw]防止流量掉零检测等场景中写错偏移单位。Kubernetes 标签引用强制检查查询必须引用cluster、namespace、pod、container、service、job、node、instance等标准标签中的至少一个从规则层面落实技能 Dynamic Multi-Resource Alerting (No Hardcoding) 的要求——禁止告警条件硬编码单实例必须按资源动态分组。lookback 窗口与 duration 冗余规则在validate_plan_file与validate_directory_tf_files中若查询使用了[15m|30m|1h|6h|3d]这类聚合回看窗口、而 Terraformduration不是0s/60s会生成 Duration warning提示查询已使用聚合回看窗口却设置长 duration将造成冗余延迟——这正是技能 No Redundant Duration Windows on Lookbacks 规则的机器化执行。此外HCLScanner.extract_alert_policies通过正则解析 HCL 中的resource google_monitoring_alert_policy name {}块、display_name、PromQLquery同时支持 heredocEOT与双引号字符串两种写法以及filter并依据资源名/显示名中的 latency、error、traffic、saturation、memory、crash、ready 等关键词推断信号类型validate_directory_tf_files还会对同一信号类型出现多条策略的情况输出 Duplicate Target Error防止对同一指标信号重复告警造成噪音。从源码结构看该脚本是一个轻量级、无外部依赖仅用标准库argparse/glob/json/os/re/sys的静态校验器适合在 CI 或本地编辑 Terraform 告警文件时快速门禁。九、前置条件到告警的对应速查何时需要做哪一步将全文要点汇总为一张决策速查表便于按场景直接定位操作场景需要的操作需要 Node / Volume 告警Not ready、Pressure、Volume full确认System Monitoring已启用Volume 类还需 CSI 驱动的 PVC 已挂载需要 API Server / 客户端告警执行gcloud container clusters update --monitoring...,API_SERVER,...并验证apiserver_request_total有数据需要 Deployment/StatefulSet/DaemonSet/CronJob/Job/Pod 状态告警部署 kube-state-metrics 过滤式 PodMonitoring必须先向用户说明成本并获许可需要 Latency/Traffic/Error 告警应用暴露/metrics端点http_requests_total、http_request_duration_seconds_bucket 工作负载 PodMonitoring需要部署/评估 Terraform 告警策略启用 3 个 API授予monitoring.alertPolicyEditor等 3 个角色部署完成后依次执行 terraform validate、validate_config.py、gcloud policies list 三步核查十、相关仓库资料本文涉及的核心源码与配套文档均可在此仓库中继续深入研读前置条件原文档gke_configuration_prerequisites.md技能总览与规则KSM 成本护栏、Golden Signals 覆盖要求、Plan-Validate-Execute 工作流SKILL.md指标与告警目录16 条告警的 PromQL 规则、Tier 1/Tier 2 分级、非 KSM 替代实现metrics_and_alerts_catalog.mdPromQL 查询参考Latency/Traffic/Error/Saturation/健康告警完整查询promql_queries.md验证脚本实现validate_config.py【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考