凌晨两点十七分手机连续震了三次。PagerDuty 上挂了一条 P1钉钉群里运维同事已经炸锅“生产环境某节点 NotReady 了上面十几个 Pod 全在重启。”我打开 Grafana先看节点总览面板再切到 kubelet 状态最后拉出这段时间的 CPU、内存和磁盘 IO 曲线。说实话这种场景我经历了不止一次。真正让我头疼的不是节点挂了这件事本身而是每次都要在一堆散落的指标里翻找根因或者在告警风暴里分辨哪些是真问题、哪些是监控自身产生了噪音。后来我把整套 K8s 节点监控与告警体系重新梳理了一遍从指标采集、阈值设定、告警路由到报告生成形成了一套基本可以“抄作业”的方案。这篇文章就把这套方案完整地拆开讲清楚包括当时踩过的坑、调参的经验和最后沉淀下来的分析模板希望能给正在做 K8s 监控的运维或平台同学一些参考。1. 整体设计与思路拆解K8s 节点监控到底要解决什么问题1.1 为什么单独把“节点监控”拎出来做K8s 集群的监控对象很多API Server、etcd、Controller Manager 这些控制面组件需要盯Deployment、StatefulSet 这些工作负载资源需要盯Pod 里的业务容器也需要盯。但节点这一层往往是最容易被忽略、却又最容易出大事的。节点是承载一切的基础。节点挂了上面跑的 Pod 全部受影响节点磁盘满了kubelet 会开始驱逐 Pod节点内存压力大系统可能直接触发 OOM Killer 随机杀进程节点时钟漂移会导致整个集群的证书校验、日志时间戳全部错乱。我见过一个最典型的案例某次故障排查到最后发现是节点时间慢了五分钟导致 Prometheus 拉取的指标时间戳错位、告警全部失效——这种问题光看应用层的监控根本发现不了。所以我的思路是将监控体系按“底座 → 编排层 → 应用层”三层拆分而节点监控是底座的核心。底座不稳上层做再多监控都是白搭。这一点需要先想清楚再去设计指标和告警。1.2 整体监控架构与技术选型先把技术选型说清楚。目前主流的开源监控方案无非是 Prometheus 生态、Zabbix、夜莺Nightingale这几类。我自己在多个集群里都试过混合方案最后沉淀下来的核心组合是 Prometheus node_exporter kube-state-metrics Alertmanager Grafana。选择 Prometheus 生态的原因很简单K8s 原生集成度最高指标采集用服务发现告警规则直接用 PromQL 写不用额外造数据模型。Zabbix 在传统物理机、虚拟机监控上确实很强但对于容器动态调度、Pod 生命周期变化这种场景模板和自动发现的模型会显得笨重。夜莺在告警分组和通知编排上做得不错如果团队已经重度使用夜莺也可以作为告警层的替代但底层指标采集我还是推荐 Prometheus 体系。在这个组合里各组件分工是组件职责采集目标node_exporter采集节点的基础资源指标CPU、内存、磁盘、网络、文件系统kube-state-metrics将 K8s 对象状态转为指标Pod、Deployment、Node 的状态与数量cAdvisorkubelet 内置采集容器运行指标容器 CPU、内存、网络、磁盘Alertmanager接收 Prometheus 告警并处理路由、分组、去重、静默Grafana可视化与报告输出仪表盘、日志关联、PDF 报告这套架构从采集到告警到可视化是一条完整链路。Prometheus 通过 service discovery 拿到节点列表后定期去 scrape node_exporter 暴露的 9100 端口拿到指标后存储到 TSDB。告警规则在 Prometheus 里评估命中就推给 Alertmanager由它根据路由树决定怎么通知人。Grafana 负责把指标变成人能一眼看懂的图同时兼顾周报、月报的生成。1.3 监控设计里最容易犯的三个错误这个架构看起来简单但真正把“节点综合监控”做扎实需要避免几个常见问题。第一个误区是只盯资源使用率不盯节点状态。很多团队的节点监控面板上只有 CPU、内存、磁盘几个图但 kubelet 健康状态、容器运行时状态、节点 Ready 状态这些真正决定集群是否可用的信号反而没有。资源指标只能告诉你“现在紧不紧张”状态指标才能告诉你“还能不能继续承载业务”。第二个误区是指标粒度过粗。整个集群的平均 CPU、平均内存意义不大需要做到按节点维度、按 Pod 维度、按容器维度多级下钻。否则节点内存被某个容器吃满你在集群平均值上根本看不出来。我的建议是所有关键面板都必须支持按节点、按命名空间、按 Pod 筛选。第三个误区是告警规则拍脑袋没有基于容量规划反推阈值。很多团队把 CPU 阈值设成 90%然后三天两头被误报骚扰。实际上阈值应该结合节点规格、业务流量模型、混部情况来定。比如同样一台 8C16G 的节点跑的是在线业务和跑的是离线任务CPU 告警阈值就应该不一样。2. 核心细节解析与实操要点从指标采集到 PromQL 实战2.1 节点层核心指标拆解节点层指标是整套监控的地基。我按照“信号价值”从高到低整理了以下指标清单整套体系都是围绕这些指标展开的。CPU 方向核心指标是node_cpu_seconds_total。这个是计数器类型不能直接看原始值要用 rate 函数算速率。常用的 PromQL 是这样1 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)这条语句的意思是把 CPU 的空闲时间速率算出来然后用 1 减掉得到的是 CPU 使用率。mode 还可以换成iowait单独看 CPU 等待 IO 的比例。如果 iowait 长期超过 10%多半是磁盘或存储链路出现了瓶颈。内存方向需要特别说明一点node_memory_MemTotal_bytes减node_memory_MemAvailable_bytes得到的内存使用量比直接用MemFree更准确。因为 Linux 的 free 内存不包含可回收的 page cache用 MemAvailable 才能反映真实可用内存。我用的核心指标是(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100这条语句是内存使用率的常用写法它把 page cache 等可回收内存也算进了可用部分排除了“明明 free 很少但系统并不慌”的误报场景。磁盘方向除了使用率还要盯 inode。实践中有个很经典的坑磁盘使用率才 60%但应用报“No space left on device”最后发现是 inode 耗尽。node_exporter 提供了node_filesystem_avail_bytes和node_filesystem_files_free两组指标前者管容量、后者管 inode都要纳入监控。另外要记得过滤掉 tmpfs、overlay 等虚拟文件系统不然会有大量无用数据。网络方向流量吞吐和连接数都要看。node_network_receive_bytes_total和node_network_transmit_bytes_total用来算网卡速率node_sockstat_TCP_alloc这类指标用来盯 TCP 连接分配情况。对于高并发业务节点TCP 连接数暴涨往往比带宽跑满更早暴露问题。2.2 K8s 专属指标kubelet 与容器运行时节点层面的指标再全也覆盖不了 K8s 的场景。有一类故障是节点本身一切正常资源也充足但 kubelet 和容器运行时之间的通信出了问题导致 Pod 调度后起不来。这时候必须看 K8s 专属指标。kubelet 的健康状态可以从两个维度看一是 Prometheus 拉取 kubelet 指标接口是否正常二是 kubelet 上报的节点状态。kube-state-metrics 暴露的kube_node_status_condition指标可以直接反映节点 Ready、MemoryPressure、DiskPressure、PIDPressure 等状态配合 condition 的 status 字段筛选kube_node_status_condition{conditionReady, statustrue} 0这条规则表示节点 Ready 状态不为 true。注意这里可能出现 status 为 unknown 的情况也属于异常需要单独加规则覆盖。容器运行时侧重点盯两类指标容器重启次数和 OOMKilled。容器频繁重启通常意味着应用有问题而 OOMKilled 则表示内存配额设置不合理或者确实有内存泄漏。kube-state-metrics 里kube_pod_container_status_restarts_total是容器重启的计数器kube_pod_container_status_waiting_reason可以过滤 Waiting 状态的原因是 CrashLoopBackOff 或 OOMKilled。我见过太多团队直到业务侧反馈“Pod 一直在重启”才开始排查其实这些指标在监控里早就有信号了。所以这两类容器状态指标是节点监控里不可省略的一环——它们反映的是节点上的“住户”是否住得安稳。2.3 指标采集落地node_exporter 部署细节指标设计完之后落地采集反而是坑最多的地方。node_exporter 的部署方式我推荐用 DaemonSet保证每个节点都跑一个实例。如果节点有 taint需要加上对应的 tolerations。采集精确度方面node_exporter 默认的采集器已经覆盖了绝大多数场景不需要额外开太多。需要注意的是一个指标过滤项--collector.filesystem.mount-points-exclude。建议把/dev/sd*、/run、/var/lib/docker等系统虚拟路径排除掉否则node_filesystem_*系列指标会非常庞杂不仅拖累 Prometheus 存储还会在告警规则里造成误匹配。还有一个高频问题是端口冲突。node_exporter 默认监听 9100但在一些管控严格的集群里主机上可能有其他 agent 也占了 9100。我习惯在 DaemonSet 里显式声明端口并加上 ServiceMonitor 的 label这样 Prometheus 的 service discovery 会自动找到目标省去手工维护 targets 的麻烦。Prometheus 侧的采集配置也比较关键。scrape_interval 我设为 15 秒这个频率在大多数场景下足够同时不会给 TSDB 带来太大压力。如果业务对实时性要求很高可以缩到 10 秒但要注意评估存储膨胀和查询变慢的问题。2.4 PromQL 实战常用节点监控查询语句PromQL 是 Prometheus 的查询语言很多人看到一堆函数就发怵其实节点监控常用的就那几类写法。我把高频使用的查询语句整理成了一份速查表直接复制改一改就能用。CPU 使用率按节点维度5 分钟平均100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance) * 100)内存使用率100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)磁盘使用率过滤掉 tmpfs 和 overlay100 * (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})磁盘 IO 读写速率rate(node_disk_read_bytes_total[5m])网络接收速率rate(node_network_receive_bytes_total[5m])节点文件描述符使用率100 * node_filefd_allocated / node_filefd_maximum这些查询语句建议在 Grafana 里先逐个验证正确性再放进告警规则避免因为 PromQL 本身的括号或聚合维度写错导致告警规则一直在 pending 或者反复触发。2.5 阈值设定参考值与背后的逻辑阈值的设定是监控系统里最考验经验的部分。定低了告警轰炸运维同学很快会“狼来了”麻木掉定高了真正出问题时收不到通知监控形同虚设。我先给出自己常用的参考阈值再解释为什么这么定。指标告警阈值持续时长级别CPU 使用率 85%5 分钟WarningCPU 使用率 95%5 分钟Critical内存使用率 90%5 分钟Warning内存可用量 512MB5 分钟Critical磁盘使用率 80%10 分钟Warning磁盘使用率 90%10 分钟Criticalinode 使用率 90%10 分钟Critical节点 Ready 状态! true1 分钟Criticalkubelet 采集失败持续 5 分钟5 分钟CriticalCPU 阈值 85% 的 Warning、95% 的 Critical 是很多团队的经验值但一定要结合节点规格调。如果节点是 32 核的大规格85% 意味着还有约 5 核的余量可以适当放宽如果是 4 核的小规格85% 时只剩不到 1 核业务早就开始抖动了。内存的 Critical 条件我习惯增加“可用量”这个绝对值判断因为 90% 使用率在 128G 的大内存节点上还有 12G 可用而在 4G 的小节点上只剩 400M不可同日而语。磁盘阈值要按数据盘和系统盘分开设。系统盘猛涨通常是日志或 docker 目录写满数据盘则是业务数据。如果磁盘容量大比如 2T80% 的阈值意味着有 400G 余量看起来安全但要注意写入速率如果每日写入量很大要给足前置预警时间。3. 实操过程与核心环节实现告警体系搭建与告警规则调优3.1 告警规则的编写技巧与常见坑Prometheus 的告警规则写在 rules 配置里格式是 YAML。一个完整的规则包含 alert 名称、expr 表达式、for 持续时长、labels 和 annotations。下面是我常用的一条节点内存告警规则groups: - name: node_alerts rules: - alert: NodeMemoryUsageHigh expr: | (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 90 for: 5m labels: severity: warning team: ops annotations: summary: 节点 {{ $labels.instance }} 内存使用率超过 90% description: 当前使用率 {{ $value | printf \%.2f\ }}%请及时排查是否有内存泄漏或容量不足。编写规则时最容易踩的坑有三个。第一个是忘记加for导致瞬时抖动也能触发告警一晚上能收到几十条“假警”。第二个是 PromQL 里正则表达式写错比如fstype~tmpfs|overlay和fstype!~tmpfs|overlay很容易搞反导致把系统关键分区排除在监控外。第三个是 annotations 里的模板语法写错$labels.instance取不到值告警内容变成一长串无效字符。还需要特别提醒规处的告警一定要保留最近变化的历史方便复盘。我一般会给 rules 文件加版本注释每次调整都记录原因不然三个月后回来看根本想不起某个阈值为什么从 80% 改成了 85%。3.2 Alertmanager 配置路由树、分组与静默告警规则定义了“什么时候该报警”Alertmanager 则决定“报给谁、怎么报、要不要合并”。这部分配置直接决定了团队对告警的体感。路由树是我优先设计的部分。我的做法是按告警级别和团队两个维度做路由分流确保关键告警能以最高优先级触达对应负责人。下面是一个典型的路由配置route: group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: default routes: - matchers: - severity critical receiver: page-ops continue: false - matchers: - severity warning receiver: alert-group其中 group_wait 是同一组告警首次通知的等待时间group_interval 是组内新增告警的通知间隔repeat_interval 是相同告警的重复发送间隔。这些参数直接影响告警打扰程度。我建议 group_wait 设短一些30 秒左右让告警尽快出去repeat_interval 设长一些比如 4 到 8 小时避免同一问题反复轰炸。静默silence是告警治理的好工具。节点主动维护、计划内扩容这类场景提前给对应的 instance 加一条静默规则可以有效避免维护期间产生误报。但静默规则一定要设置过期时间我见过有人建了一条永久静默最后忘记清理节点挂了一整天都没人收到告警。所以静默必须带 schedule 和 expires宁可到期重新建也不要留永久静默。3.3 告警通知渠道统一 Webhook 接入钉钉/企微通知渠道的建设我强烈建议不要直接对接 Prometheus 的 email 或者 Slack 原生集成而是走统一 Webhook 网关。这样以后更换通知工具只需要改网关一侧不用动 Alertmanager 配置。Alertmanager 配置一个 webhook receiver 非常简单receivers: - name: webhook webhook_configs: - url: http://alert-gateway:8080/k8s/alert send_resolved: true http_config: bearer_token: your-token接着在网关里做一次告警内容的标准化把 Alertmanager 推送过来的 JSON 转换成钉钉或企业微信的卡片消息格式再按告警级别打上不同颜色标签。这样团队成员在手机上就能快速区分红色是 Critical橙色是 Warning绿色是恢复通知。这里有个实践细节send_resolved一定要设为 true。很多人只配置了告警触发通知恢复通知没开导致下一个值班同学不知道问题已经解决还要在群里反复问“现在恢复了吗”。恢复通知不仅是给值班人吃定心丸也是给整个团队留一份闭环记录。3.4 告警噪音治理方法论告警噪音是监控体系里最影响体验的问题。噪音多了团队成员会逐渐忽略所有告警真正的 P1 反而没人响应。我治理噪音的方式核心是“每个告警必须回答三个问题”影响面多大、需要谁处理、应该多快处理。按照这个原则我通常先将告警分 P0/P1/P2 三级。P0 是指节点宕机、API Server 不可用、大面积 Pod 驱逐要求立即响应直接打值班人电话P1 是指某节点磁盘即将写满、内存持续高位需要 30 分钟内紧急确认P2 是指资源使用率较高但尚能自愈进入日常工单池即可。![告警分级参考]级别典型场景响应要求通知方式P0节点 NotReady、kubelet 挂掉、大面积容器 OOM立即响应电话 语音通知P1磁盘使用率超 90%、内存可用不足30 分钟内钉钉/企微卡片P2CPU 使用率持续超 85%、inode 偏高2 小时内工单池/邮件然后要定期回顾告警历史统计哪些告警触发了但最后确认是误报或无需处理把这类告警的阈值调高或直接下线。我在实际过程中发现一套新的监控系统上线后的头一个月至少有 30% 的告警规则是需要调整的。这不是规则写得不好而是因为实际业务负载模式还没被完全摸清。还有一个值得注意的点不要为了告警而告警。有些团队把所有指标都配上告警结果告警列表一眼望不到头。我更推荐的做法是每条告警规则都对应一个明确的运维动作——收到告警后应该去执行什么操作如果动作不明确这条告警就不应该存在。4. 监控分析报告与故障复盘从 Grafana 仪表盘到 PDF 报告4.1 Grafana 仪表盘设计节点总览与明细下钻监控不只有告警还有日常巡检和分析。Grafana 是这套体系里负责把人眼跟数据连接起来的环节。节点监控的仪表盘我分成了三个层级总览、明细、趋势。总览盘面向值班人员要求一眼看清整个集群的节点健康状态。我把核心面板设计成一个表格每个节点一行列为节点名称、CPU 使用率、内存使用率、磁盘使用率、网络速率、Pod 数量、节点状态。这个表格就是日常巡检的第一落点任何异常都能在这里被发现。明细盘面向故障排查按单节点下钻。点击总览盘的某个节点进入该节点的详细面板包含 CPU 各核心分布、内存组成used/buffers/cache、磁盘 IO 读写、网络连接数、关键容器状态。这套下钻路径非常关键它能帮助你在 5 分钟内定位到“节点磁盘 IO 高是因为哪个 Pod 在大量读写”这种级别的问题。趋势盘面向容量规划。我看的是 7 天和 30 天的资源使用趋势用于回答“下个月需不需要扩容”这类问题。趋势数据不能只看平均值要看峰值和 95 分位值因为平均值掩盖了流量毛刺。4.2 生成 PDF 监控报告的两种方案很多团队除了实时看板还需要定期输出监控报告给管理层或客户这就用到了 Grafana 的“生成 PDF 监控报告”能力。这里有两种方案我都实测过分享下各自的注意事项。方案一是利用 Grafana 自带的报表插件。装好 grafana-image-renderer 插件后可以在 Grafana 的 Reporting 功能里配置定时任务按天/周/月生成当前仪表盘的截图然后推送到邮箱或企业微信。这个方案上手最快但输出内容是图片拼接如果仪表盘面板太多PDF 会很长而且不能对每个面板单独加文字说明。方案二是调用 Grafana HTTP API 按需渲染再配合脚本做数据汇总。我写过一个简单的 Python 脚本先通过 API 获取指定时间范围的节点指标然后用 pandas 做统计汇总生成资源使用率 Top 10 节点、告警数量分布、持续时长这些结构化数据最后调用 Grafana 渲染图表合并成一份完整 PDF。这个方案灵活度高适合要做深入分析报告的场景。4.3 从指标到结论监控分析报告应该包含什么报告是给决策者看的不是给监控系统看的。所以一份好的监控分析报告应该包含结论、数据支撑、风险提示三个部分而不是简单贴几张图。我通常的章节结构是先说本月集群整体运行情况可用性、最大告警数、主要事件再给节点资源使用趋势分析和 Top 节点清单然后是告警分类统计哪类告警最多、平均响应时长、重复告警占比最后给出容量规划建议哪些节点需要扩容、哪些资源可回收。这里要特别强调一点报告里的每一个结论都要有数据支撑。比如写“集群存在容量风险”就要附上内存使用率连续 7 天超过 85% 的节点列表和趋势图。如果没有数据链支撑这样的报告没有任何说服力。我还会在报告中加一个“上期问题跟进”章节把上个月提出的风险项逐条列出当前状态。这个习惯让监控报告从一个静态文档变成了持续迭代的运维闭环管理层能明显感受到监控体系的价值。4.4 故障复盘怎么让监控数据变成经验故障复盘是监控数据分析价值最大化的场景。每次 P1 以上故障结束后我都会强制团队输出一份复盘文档里面必须包含几个部分故障时间线从最先出现的异常指标开始、监控盲区总结哪些指标没有覆盖到、告警有效性回顾告警是否及时触发、是否被噪音淹没、改进项清单。时间线的还原主要依赖 Prometheus 的历史数据。比如某次故障时间线写着“14:00 内存使用率开始爬升14:20 触发内存告警14:35 节点 NotReady14:50 告警升级到 P1”。有了这条时间线就能清楚地看到从异常出现到告警触发的间隔是否合理是阈值设太高导致告警晚了 20 分钟还是告警规则本身有缺陷。监控盲区总结是最有价值的内容。每次复盘都可能发现新的监控盲区比如“这次发现我们竟然没有盯节点时钟偏移”“fs.inotify 上限告警缺失导致应用无法创建文件”。每发现一个盲区就补一条对应的监控规则整套体系就是这样一轮一轮迭代完善的。5. 常见问题与排查技巧实录5.1 高频问题速查表整理了一份我在实际运维中常遇到的问题速查表按症状列出可能原因和排查建议。症状可能原因排查建议节点状态显示 NotReadykubelet 与 API Server 通信异常检查 kubelet 日志、网络策略、证书是否过期告警规则不触发PromQL 语法错误或 for 时长过长在 Prometheus 的 Alerts 页面查看规则状态确认是否 Pending告警重复轰炸缺少 Alertmanager 分组配置设置合理的 group_by 和 repeat_interval磁盘有空间但报 No spaceinode 耗尽用 df -i 查看 inode 使用率清理无效小文件scrape 目标显示 DOWNnode_exporter 挂掉或网络不通检查 Pod 状态和网络策略确认 9100 端口可达Grafana 图表无数据数据源时间范围或标签不匹配检查 Prometheus 数据源查询是否命中标签名是否一致告警内容变量不显示模板语法错误检查 {{ $labels.xxx }} 中的标签名是否在表达式中存在节点时钟漂移导致告警异常NTP 同步失效检查 chrony/systemd-timesyncd 状态强制同步并监控时钟偏移这张表不是标准文档的搬运而是我一次次处理事故后沉淀出来的浓缩经验。特别是 inode 耗尽和时钟漂移这两个问题搜索频率极低、但一旦发生就是大事。5.2 一个完整的告警排查实例拿一次真实的磁盘告警来演示整体排查思路。某天下午团队收到一条 P1 告警某节点数据盘使用率超过 85%持续 10 分钟。第一步不是直接连上服务器清日志而是先在 Grafana 上看这个节点的磁盘使用趋势确认是“缓慢爬升”还是“突然跳变”。结果发现曲线从三天前开始持续向上斜率比较陡说明是持续写入不是一次性爆发。第二步是在 Prometheus 里查这个节点上所有容器和宿主机的写入速率用rate(node_disk_writes_bytes_total[5m])按 device 分组再用容器侧的container_fs_writes_bytes_total按 Pod 分组。交叉对比后发现某个日志采集组件的 Pod 在大量写宿主机的/var/log。第三步是登录节点核实。du -sh /var/log确认日志目录已经占了几十个 G再进到该组件的容器配置里检查日志输出路径和轮转策略发现它的日志文件没有配置轮转。最后加上 logrotate 配置清理历史大文件磁盘使用率恢复正常。整个排查过程不到二十分钟核心不是运气而是监控数据让每一步研判都有据可依。这个例子说明节点监控的最终价值不是“能收到告警”而是拿到告警之后你能用监控数据把问题边界迅速缩小不让排查过程变成翻山越岭找线索。5.3 避坑经验合集最后分享几个我在实际部署和调优过程中踩过的坑都属于“不上一次当永远记不住”的那种。第一个坑是关于 node_exporter 的版本升级。某些 node_exporter 版本升级后指标命名发生了变化比如node_cpu变成了node_cpu_seconds_total旧版 Grafana 面板和告警规则里的 PromQL 全部失效。所以升级前一定要先查阅官方 CHANGELOG先在测试环境升级、校验所有面板和规则再灰度更新到生产。第二个坑是关于 Prometheus 的存储时长。很多人忽略了 TSDB 的默认保留时间默认只有 15 天。做容量规划时想翻历史数据发现早就被清理了。我在生产环境把--storage.tsdb.retention.time设成了 60 天并评估了存储容量避免报告需要数据时无数据可用。第三个坑是关于标签的高基数问题。比如在告警规则里用 Pod 名称做标签Pod 重建后标签会不断变化Prometheus 的指标数量会指数级膨胀最终拖垮 TSDB 查询性能。标签的设计一定要控制基数能用标签归类就尽量归纳不要把唯一的实体名当标签用。第四个坑是关于 Grafana 的时区。默认时区是 UTC国内团队直接看图会发现所有时间都偏移了 8 小时。首次部署 Grafana 时就把默认时区改为 Asia/Shanghai并统一所有看板的时区设置避免看告警时间还要在心里默默加八小时。5.4 监控体系上线后的持续运营最后想聊聊监控体系上线后的运营。很多人以为监控搭好就结束了其实真正的维护工作才刚刚开始。我建议每个月抽半天时间做一次“告警规则健康检查”拉出 Prometheus 的告警历史统计每条规则在过去 30 天的触发次数、平均持续时长、最终是否演变成真实故障。如果一条规则触发了 20 次但只有 2 次是真实问题那这条规则要调。如果一条规则从未触发过但对应的指标确实发生过严重故障那说明规则有盲区要补。持续做这项工作告警系统的信噪比才会越来越高。另外监控数据也是容量规划的重要输入。每季度根据节点使用趋势做一次资源水位评估提前识别出哪些节点会在未来一两个月内触达容量上限提前扩容或迁移业务把被动救火变成主动规划。根据我个人的经验真正可靠的 K8s 节点监控体系不是在搭建完成那一刻“上线”的而是在一次次告警、一次次复盘、一次次规则调优中逐步“长”出来的。现在每次看到告警消息我心里不再是“又出事了”的烦躁而是“监控没白做”的踏实。也希望这篇文章能帮你少踩一些坑把节点监控这件事做得更扎实。