搭建指标监控平台是保障系统稳定性的关键一步，但很多人一开始就被各种概念和工具淹没。本文不打算罗列所有选项，而是给出一个可操作的路径：先明确边界，再逐步实现采集、存储、可视化和告警。如果你刚接触监控，或者想从零搭建一套基础监控，这篇文章会带你走通整个流程。
明确监控边界：先确定要监控什么
在动手搭建之前，先想清楚监控的范围。指标监控的核心是收集数值型数据，比如Web服务器的请求延迟、数据库的连接数等。依据 Prometheus 官方文档，指标是数值测量，而时间序列则记录这些测量随时间的变化。因此，你需要先列出自己关心的指标：是CPU使用率、内存占用，还是业务层面的QPS？边界不清晰，后续的采集和存储都会失控。
选择技术栈：Prometheus 与 OpenTelemetry 的角色
当前开源生态中，Prometheus 是监控和告警的主流工具，它从2012年诞生，2016年加入CNCF，如今已被广泛采用。Prometheus 擅长收集和存储时间序列数据，并提供强大的查询语言。而 OpenTelemetry 则是一个厂商中立的可观测性框架，用于生成、收集和导出遥测数据，包括指标、日志和链路。两者可以结合：用 OpenTelemetry 进行应用埋点，用 Prometheus 存储和告警。
采集数据：从应用和基础设施入手
采集是监控的第一步。对于基础设施，可以使用 Node Exporter 等工具暴露系统指标；对于应用，则需要在代码中埋点。OpenTelemetry 提供了多种语言的 SDK，可以方便地生成指标。但要注意，埋点不是一蹴而就的，你需要决定哪些指标值得收集。例如，对于 Web 服务，请求延迟和错误率是核心；对于数据库，连接数和查询耗时更重要。采集频率也要权衡，过高会增加开销，过低则可能错过异常。
存储与查询：利用 Prometheus 的时间序列数据库
Prometheus 内置了高效的存储引擎，以时间序列形式保存指标，每个序列由指标名和标签（key-value对）唯一标识。在存储时，需要关注标签的基数（cardinality），高基数会导致存储膨胀和查询变慢。如果你遇到高基数问题，可以参考 Prometheus 高基数指标救星：Relabeling 机制从入门到实战 来优化标签。查询方面，PromQL 是 Prometheus 的查询语言，可以灵活聚合和计算指标，但学习曲线较陡，建议从基础函数开始。
可视化：搭建仪表盘
数据有了，还需要直观的界面。Grafana 是常用的可视化工具，可以对接 Prometheus 数据源，创建各种图表和仪表盘。你也可以使用 Prometheus 自带的简易表达式浏览器，但功能有限。在搭建仪表盘时，建议先从关键指标入手，比如 CPU 使用率、内存占用、请求延迟等，然后逐步增加视图。注意，仪表盘不是越多越好，要确保每个图表都有明确的用途。
告警：及时发现问题
监控的最终目的是及时发现问题。Prometheus 支持定义告警规则，当指标达到阈值时触发通知。告警规则需要精心设计，避免误报和漏报。例如，可以设置 CPU 使用率超过 90% 持续 5 分钟才告警，以减少抖动。通知渠道可以接入邮件、Slack 等。告警的阈值需要结合历史数据调整，否则容易失效。
自动化部署：使用 GitHub Actions 持续交付监控配置
监控平台本身也需要维护。你可以使用 GitHub Actions 来自动化部署 Prometheus 配置和告警规则。例如，将配置文件放在仓库中，通过 CI/CD 流程在变更后自动重载。这样既能保证配置的一致性，也能减少人为错误。GitHub Actions 提供了灵活的工作流，可以轻松集成到现有开发流程中。
常见误区与失败条件
搭建过程中，有几个常见的坑：一是过度追求监控指标的数量，导致系统开销过大；二是忽略标签基数，造成存储爆炸；三是告警规则设置不当，产生大量噪音。此外，不要期望一次就能完美，监控系统需要持续迭代。如果遇到磁盘 I/O 问题，可以参考 从零理解Linux磁盘I/O延迟：用Prometheus Node Exporter监控Await指标 来深入理解。
参考资料
延伸阅读