基础资源、应用性能、集群状态和成本，只看CPU和内存就是典型瞎看。
容器监控指标选不对，运维天天在添乱
很多人上手容器监控,第一反应就是把CPU、内存、磁盘、网络全部拉满，恨不得每个指标都画个大盘，结果呢？告警深夜轰炸，要么是阈值设得太死，要么是毛刺导致误报，真正出问题的时候反而被淹没在噪音里，业内专家指出，超过七成的容器监控团队都经历过“指标太多但不知道看哪个”的困境，要跳出这个坑，就得先搞清楚：容器监控到底看哪些指标才算有得放矢。
基础指标只是及格线，别当核心KPI
CPU使用率、内存占用、磁盘I/O、网络流量，这些是死命令，但只能反映容器“活着”，不能说明它“干得好”，比如一个容器CPU跑满，但可能是业务高峰的正常波动，也可能是代码死循环，只看平均值等于掩耳盗铃，必须结合百分位值（P99、P95）和变化趋势，磁盘和网络也一样，IOPS和带宽是基础，但真正要盯的是等待队列长度和丢包率，这些才是容器响应慢的元凶。
应用性能指标才是容器监控的终点
容器化的意义在于快速交付和弹性扩缩,如果监控只盯着资源层，那和传统虚拟机监控没区别。业务层面的事，必须用业务指标说话，比如请求延迟、错误率、吞吐量，这些才是容器监控的“北极星”，很多团队在容器监控方案里不接入APM，结果就是资源指标正常，但用户反馈卡顿，排查半天才发现是应用代码的锅。容器的应用监控指标，优先级应该高于所有基础设施指标。
容器监控必须死磕的四个维度
资源利用率别只看“用了多少”，要看“够不够用”
CPU和内存是基础,但核心是看资源利用率是否合理，以及是否存在浪费，一个容器长期CPU使用率低于10%，但内存占用居高不下，说明资源分配不合理，行业共识认为，容器资源利用率目标应设定在60%-80%之间，过高会引发争抢，过低则是浪费，不要只看瞬时值，要关注
平均负载和请求数关系，比如每秒请求量（RPS）与CPU使用率的曲线，才能判断性能瓶颈到底在哪。
实操：用PromQL计算资源利用率拐点
rate(container_cpu_usage_seconds_total[5m]) / container_spec_cpu_quota当这个比值接近1时,说明容器处于饱和状态，需要扩容，这个指标比单纯看CPU使用率更精准，因为它关联了配额限制。
网络与存储最容易忽略的暗坑
容器网络比传统虚拟化复杂得多,网络延迟、重传率和连接数比带宽更有价值，一个微服务调用链上，Pod之间的网络延迟超过50ms，就应该作为告警指标，存储方面，容器日志采集和持久化卷的IOPS是常见瓶颈，尤其是使用本地存储时，IOPS的竞争会直接影响应用响应。容器监控报警指标中，网络重传率和存储IO等待时间必须单独配置阈值，不能和通用系统监控混用。
集群调度与状态脚手架稳不稳，得看它
对于Kubernetes环境,集群级别的指标比单一容器重要得多，需要盯Pod启动失败率、节点资源分配率、待调度Pod数量、以及OOMKilled次数，这些指标直接反映集群健康度，比如Pod启动失败率超过5%，说明可能镜像拉取有问题或资源不足。k8s容器监控指标中，调度延迟和Pod重启率是判断集群稳定性的关键，很多团队忽略了这一点，结果节点宕机导致大面积服务不可用。
命令：快速查看集群Pod状态
kubectl get events --sort-by='.lastTimestamp' | grep -i fail节点CPU和内存的预留余量也要关注，预留太少会导致节点过载，预留太多则是浪费。容器监控成本优化往往从这里开始，通过调整资源请求和限制，可以节省大量云资源费用。
成本与效率监控的终极目标是省钱
容器监控如果不和成本挂钩,就是瞎忙。统计每个容器或命名空间的资源消耗，并与业务产出关联，每核CPU处理多少请求”或“每GB内存承载多少用户”。容器监控工具对比时，要看是否具备成本分析能力
，比如Prometheus+Grafana搭配开源组件，还是直接购买商业APM方案，选择时不仅要看功能，还要考虑容器监控费用，尤其是数据存储和查询的开销，很多团队的监控数据量超过业务数据量，导致存储成本飙升，所以必须设定指标保留策略，热数据保留7天，冷数据压缩归档。
容器监控报警指标怎么设才不“狼来了”
报警指标不能简单照搬传统阈值,容器是动态的，报警也要动态，比如CPU使用率，不能用一个固定值，要结合历史波动和周期特性，推荐使用基于百分位的动态基线，例如P99响应时间超过过去7天均值的2倍时才触发告警。必须做降噪处理，比如容器启动瞬间的CPU飙升，需要排除。容器监控报警指标设置时，要区分“严重”和“警告”，严重级别只留给业务中断或资源耗尽，警告级别才用于性能抖动。
哪些指标容易产生误报，必须单独处理
- 容器CPU使用率短期突刺（<1分钟），通常不影响业务，建议用持续超过阈值条件过滤。
- 磁盘使用率接近100%，但写操作量很小，应联合IOPS和写入延迟一起判断。
- 网络延迟升高,但可能是目标服务本身的问题，最好结合应用错误率联动报警。
容器监控工具对比：选对方案，少花冤枉钱
市面上的容器监控工具主要分三类：开源免费（Prometheus+Alertmanager+Grafana）、商业SaaS（Datadog、New Relic）、云厂商内置（AWS CloudWatch、简米云ARMS）。容器监控工具对比时，重点看数据采集灵活度、告警规则复杂度和存储成本，Prometheus虽然免费，但存储和查询水平扩展需要自己维护，如果集群规模超过1000个Pod，建议考虑收费方案。容器监控方案选择还要考虑团队技术栈，如果团队熟悉Kubernetes，Prometheus是性价比最高的选择；如果追求开箱即用且预算充足，商业工具能节省大量运维时间。
费用对比要点
- 开源方案：基础设施成本（服务器、磁盘）、人力成本（维护Prometheus集群、配置告警）。
- 商业方案：按数据量（时间序列数）和用户数收费，月均费用从几百到几万不等。容器监控费用在规划时就要算清楚，很多团队低估了数据量，导致账单超支，建议先估算Pod数和预期的指标数，再乘以保留时间，大概能算出每月存储的数据量，然后对比各家定价。
Q&A：容器监控常见问题解答
容器监控看哪些指标才能快速定位问题？
核心是应用性能指标加上资源利用率异常的关联性，先看应用延迟和错误率，再看容器CPU和内存是否饱和，最后看集群调度和网络状态。不要单独看任何一个指标，要组合成“黄金信号”：延迟、流量、错误、饱和度，这四类指标能覆盖90%的故障场景。
容器监控报警指标太多，怎么梳理优先级？
按业务影响程度分级，第一优先级：服务不可用、错误率剧增、Pod持续重启；第二优先级：资源使用率接近上限、延迟升高；第三优先级：磁盘空间不足、非关键组件异常。每个级别对应不同的响应时间和通知方式，比如P0报警直接电话，P3只发邮件。定期回顾报警规则，删除那些从来不会触发的死规则，避免干扰。
容器监控成本怎么控制，同时又不影响关键数据？
控制数据粒度和保留时间，短时间跨度（<1小时）的查询使用原始粒度（15秒），长期趋势（>1个月）使用聚合后的5分钟粒度。聚合规则可以通过Prometheus的Recording Rules实现，例如对CPU使用率每5分钟取平均值，这样能大幅减少存储量。只采集必要的指标，比如删除那些从没有用过的自定义指标，或者对基础指标（如CPU总量）降采样。容器监控成本优化不是一刀切，而是按需分层，热数据保留高精度，冷数据保留低精度。