容器平台的监控指标需要覆盖资源、应用、网络、存储、安全以及Kubernetes核心组件运行状态这六大类关键数据，缺一不可。只有把这六类数据吃到嘴里、嚼碎了，监控体系才算真正落地，而不是光看个CPU曲线图自欺欺人。
容器平台监控指标有哪些？这六类数据是核心骨架
很多团队刚上手容器监控,习惯性盯着Pod的CPU和内存不放，觉得看到数字跳就放心了，但这种做法在真实生产环境里，隐患极大，行业共识认为，一个成熟的容器平台监控体系，至少要吃到以下几层数据，才能保证系统不“裸奔”。
资源监控：CPU与内存的“实时体检”
资源监控是你最先应该抓起来的东西,但它不是简单看个使用率就完事。
- CPU指标：不仅要看Pod的CPU使用率，还要看CPU Throttling（限流）比例，一个Pod如果频繁被限流，说明它的CPU Request和Limit设置不合理，业务延迟会莫名其妙飙升，很多排查慢请求的案例，最后都栽在这个细节上。
- 内存指标：重点看RSS（常驻内存）和Working Set，而不是简单的“已用内存”，容器内存回收机制复杂，只盯着Mem Usage会让你误判内存泄漏，同时监控OOM Kill事件，这是容器被驱逐的前兆。
- 磁盘与网络：容器磁盘I/O等待时间（iowait）和网络丢包率，这两个指标往往被忽视，但在日志型或数据型应用里，它们才是真正的瓶颈，用
iostat和iftop配合Prometheus exporter，可以抓取到Pod级别的细粒度数据。
应用监控：从Pod到业务的“体检报告”
资源够用不代表业务正常。应用监控是很多团队头疼的地方，因为它跳出了“容器”这个壳，直接针对业务代码。
- 接口响应时间与错误率：用APM工具（如SkyWalking、Pinpoint）或Prometheus自带的Histogram埋点，监控每个API的P99、P95延迟。错误率超过1%就要触发告警，这是行业通用红线。
- JVM/GC等运行时指标：如果你的业务跑在Java或Go上，建议把GC停顿时间、堆内存使用率、Goroutine数量等指标拉入监控，这些运行时数据能帮你提前发现代码层面的内存泄漏或协程泄露。
- 业务自定义指标：比如订单系统的订单量、支付成功率、用户登录失败次数，这些指标直接反映业务健康度，建议用Micrometer或Prometheus SDK直接暴露，然后通过ServiceMonitor自动抓取。
容器监控指标的“第二层”：网络与存储，别让它们成为盲区
很多人在容器监控指标有哪些的讨论中,网络和存储往往被一笔带过，但在实际生产中，这两块是导致故障的“隐形杀手”。
网络监控：东西流量的“显微镜”
Kubernetes的网络模型让东西流量（Pod间通信）变得复杂，传统的网络监控工具很难直接套用。
- Pod间网络延迟与丢包：使用eBPF技术（如Cilium、Hubble）可以无侵入地监控Pod间的TCP连接状态、RTT（往返时间）、重传率。重传率超过5%基本就说明网络链路有问题，可能是DNS解析慢、Service Mesh代理过载或物理网卡出故障。
- DNS解析成功率：这是最容易被忽视的指标，Kubernetes里Pod频繁启停，DNS解析请求量大，CoreDNS很容易成为瓶颈，监控DNS查询失败率和解析延迟，建议设置告警阈值：失败率超过1%或P99延迟超过1秒。
- ingress/egress流量：关注Ingress Controller的流量分布和带宽使用率，避免某个节点因流量倾斜被打满，用
kubectl top pods -n ingress-nginx可以快速查看，但更推荐用Grafana画标准仪表盘。
存储监控：持久化数据的“保障线”
有状态应用（数据库、缓存、消息队列）正在向Kubernetes迁移，存储监控变得至关重要。
- PV/PVC使用率：监控PersistentVolume的剩余容量，使用率超过80%时触发预警告警，用
kubectl get pv和Prometheus的kubelet_volume_stats_available_bytes指标可以实现。 - 存储I/O性能：关注IOPS和吞吐量，特别是高并发写入场景（如日志采集、数据库），如果存储后端是NFS，还要监控NFS服务端的响应延迟，避免因存储抖动导致Pod挂载卡死。
- CSI插件状态：监控CSI（容器存储接口）驱动的健康状况，比如
csi-attacher、csi-provisioner
的Pod运行状态和错误日志，CSI插件挂掉，会导致Pods无法创建或挂载卷。
不同场景下容器监控指标怎么选？按需定制，别一刀切
很多新手会问：“容器平台监控指标有哪些标准答案？”其实没有万能模板，关键看你的业务场景，下面给出三个典型场景的选型建议。
微服务架构（高流量、高动态）
- 核心指标：除了基础资源，重点抓Pod副本数变化、HPA扩缩容事件、Service Mesh sidecar的Envoy状态（连接数、请求数、错误码）。
- 告警规则：关注错误日志增长率，而不是绝对值，一个服务突然错误日志暴增10倍，说明代码变更有问题，用
rate(log_entries_total[5m])计算。 - 工具推荐：Prometheus + Grafana + Loki + Alertmanager，这是目前最成熟的开源方案，如果你的业务量在日均百万级别，这套组合完全够用，不需要强上商业APM。
大数据与AI训练（高计算、长任务）
- 核心指标：GPU利用率和GPU显存占用是刚需，用
dcgm-exporter（NVIDIA官方工具）导出GPU指标，监控GPU温度和功耗，防止训练任务因过热降频。 - 特殊指标：Job完成时间和任务失败率，大数据任务跑在Kubernetes里，Spark Operator或Airflow Operator的调度延迟、重试次数都要拉进监控，如果任务平均完成时间突然增加50%，可能是集群资源碎片化严重。
- 存储考量：关注临时存储（Ephemeral Storage）使用率，训练任务通常需要大量临时空间，Pod的
ephemeral-storage限制设置不当会导致Pod被驱逐，用kubelet_ephemeral_storage_usage_bytes监控。
数据库与中间件集群（高可靠、低延迟）
- 核心指标：Leader选举状态、主从同步延迟、连接数，对于MySQL Operator、Redis Cluster、Kafka Operator，这些指标必须从中间件本身暴露出来，而非从容器层面推测。
- 告警机制：同步延迟超过5秒触发P0级告警，不要等到主从切换失败才去查，那已经晚了。
- 网络与存储：Pod间网络延迟必须低于1毫秒，否则会影响分布式共识协议（如Raft）的稳定性，同时监控存储IOPS，确保数据落盘速度。
容器平台监控指标有哪些常见问题？Q&A帮你理清思路
Q1：监控指标太多，怎么筛选出最关键的几个？
建议从“故障影响面”出发筛选。优先监控那些一旦出问题，会直接导致业务不可用或用户投诉的指标，P99延迟、Pod重启次数、错误日志率、磁盘使用率，先抓这些，再逐步扩展，不要试图一次性监控所有东西，那会导致告警疲劳，业内专家建议，一个团队初期只要把Kubernetes核心组件状态、Pod资源使用率、应用错误日志这三个维度监控到位，就能覆盖80%的线上故障场景。
Q2：Prometheus存储压力大，如何降低容器监控指标的数据量？
核心思路是降采样与聚合，针对高频变化指标（如CPU使用率），设置采集间隔为15秒，存储保留7天原始数据，然后降采样为1分钟和5分钟粒度的数据，保留30天，对于Pod级别的细粒度指标，在Record Rules中先聚合为Deployment或Namespace级别，业务团队查看时优先使用聚合数据，只有排查问题时才下钻到Pod，限制kube-state-metrics和kubelet的指标采集白名单，只保留kube_前缀中关键字段，比如kube_pod_status_phase、kube_deployment_status_replicas_available，其他不常用的指标可以关掉，能显著降低Prometheus的TPS和内存占用。
Q3：多集群场景下，容器平台的监控指标应该怎么统一管理？
建议采用中心化采集+租户隔离的架构，选择一个集群作为“监控中心”，部署Thanos或VictoriaMetrics，然后将其他集群的Prometheus作为数据源，通过Remote Write方式将数据汇聚到中心集群，每个业务团队通过Grafana的Organization功能或文件夹权限，只看自己负责的Namespace和集群，你的告警规则和仪表盘模板可以统一存放在Git仓库，通过ArgoCD或FluxCD自动同步到各个集群，这样能保证不同集群的监控口径一致，避免因配置差异导致的误判。