指标监控系统选型，本质是选择一条从数据采集到告警的完整路径。本文直接给出判断路径：先明确你的监控对象和规模，再对比Prometheus与云原生方案（如基于OpenTelemetry的体系），最后结合Kubernetes环境落地。整个过程会涉及取舍、失败条件和常见误区，请按步骤操作。
一、先判断：你的监控需求属于哪一类？
选型前，先回答三个问题：监控对象（容器、虚拟机、还是物理机？）、规模（节点数量、指标量级）、团队能力（运维还是开发主导？）。根据答案，你可以将需求归入以下三类：
- 传统基础设施监控：以主机、网络、中间件为主，指标量级百万级以下，Prometheus足够。
- 云原生应用监控：Kubernetes集群、微服务、动态伸缩，需要高基数支持，Prometheus配合远程存储或云原生方案。
- 多语言、多框架统一观测：需要统一指标、日志、追踪，此时OpenTelemetry成为关键。
明确需求后，再进入具体方案对比。
二、Prometheus：经典之选，但需注意边界
Prometheus是一个开源系统监控和告警工具包，最初在SoundCloud构建，2016年加入CNCF，是继Kubernetes之后第二个托管项目。它采集并存储指标为时间序列数据，即带有时间戳和可选标签（key-value对）的数值。其核心优势是拉取模型和PromQL，但它的单机存储限制了扩展性。
适用条件：如果你有Kubernetes集群，Prometheus是事实标准，因为它原生支持Kubernetes的服务发现和指标采集。但要注意：高基数（如标签组合过多）会导致存储和查询性能下降，此时你需要使用Relabeling机制来优化。我们曾详细介绍过Prometheus高基数指标救星：Relabeling机制从入门到实战，建议先阅读。
失败条件：当指标规模超过单机容量（通常数亿时间序列），或需要长期存储（超过15天）时，Prometheus默认的本地存储会失效。此时需要引入远程存储（如Thanos、VictoriaMetrics），或转向云原生方案。
三、云原生方案：基于OpenTelemetry的统一观测
OpenTelemetry（OTel）是一个供应商中立、开源的观测框架，用于生成、采集和导出遥测数据，包括trace、metrics、logs。它支持超过90个观测供应商，被众多库、服务和应用集成。如果你的目标是构建可移植、可扩展的指标监控体系，OTel是首选。
为什么需要OTel？ 因为它提供了统一的API和SDK，避免厂商锁定。你可以使用OTel SDK采集指标，然后导出到Prometheus、云端或其他后端。这种抽象层使得应用代码与后端解耦，未来切换成本极低。
操作步骤：
- 在应用中集成OTel SDK，自动或手动埋点。
- 配置OTel Collector，接收、处理、导出指标数据。
- 选择后端：Prometheus、云监控（如AWS CloudWatch、Azure Monitor）或自建存储。
取舍：OTel增加了额外的组件（Collector），运维复杂度上升，但换来了灵活性和标准化。如果你的团队已有Prometheus，可以逐步迁移，而非一刀切。
四、Kubernetes环境下的监控选型要点
Kubernetes是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，它促进声明式配置和自动化。在Kubernetes中，指标监控需要关注节点、Pod、容器等层级，以及动态伸缩带来的指标波动。
关键点：
- 指标来源：kubelet暴露的cAdvisor指标、kube-state-metrics、自定义业务指标。
- 采集方式：Prometheus通过服务发现自动发现目标，但需注意标签设计和高基数问题。
- 与OTel集成：OTel Collector可以部署为DaemonSet，统一采集节点和Pod指标，再转发到Prometheus。
常见误区：直接采集所有指标而不加筛选，导致存储爆炸。应该使用Relabeling丢弃无用标签，或只采集必要指标。另外，不要忽略告警规则的设计，否则监控数据只是摆设。
五、从Prometheus迁移到云原生方案的路径
如果你已有Prometheus，迁移到云原生方案（如OTel）不需要推翻重来。推荐渐进式迁移：
- 保持Prometheus作为短期存储和告警引擎。
- 引入OTel Collector，作为指标的中转层，统一采集和导出。
- 逐步将应用埋点从Prometheus client库切换到OTel SDK。
- 最后，将后端迁移到云原生存储（如Thanos、Mimir），或直接使用云厂商托管服务。
失败条件：迁移过程中如果未做好指标命名和标签的统一，会导致数据不一致。建议先制定规范，再动工。
六、实战案例与操作步骤
以Kubernetes集群为例，演示如何从零搭建一套指标监控体系：
- 部署Prometheus：使用Helm或Operator，配置ServiceMonitor采集Pod指标。
- 集成Node Exporter：监控节点资源，如CPU、内存、磁盘I/O。可参考我们写的从零理解Linux磁盘I/O延迟：用Prometheus Node Exporter监控Await指标。
- 添加OTel Collector：作为DaemonSet部署，接收OTel数据，并转发到Prometheus。
- 设置告警：基于PromQL编写告警规则，如节点磁盘使用率超过80%。
过程中，你可能遇到高基数、存储膨胀等问题，及时调整。
七、总结与决策建议
指标监控系统选型没有银弹。如果你处于Kubernetes原生环境，Prometheus是稳妥起点；如果你需要多语言、多后端统一，OTel是未来方向。无论选择哪种，都要注意指标基数控制、存储规划、告警设计。建议先用Prometheus跑通，再评估是否引入OTel。
最后，参考官方文档获取更多细节：Prometheus Overview、OpenTelemetry Documentation、Kubernetes Concepts。
参考资料
延伸阅读