监控漫谈（一）：监控不是什么高大上的东西——它就是系统的“体检报告”

你有没有遇到过这种情况：用户反馈说“系统好慢”，你打开服务器看了看 CPU 和内存，都正常。然后你就卡住了——不是没问题，是你不知道问题在哪。这就是没有监控的典型困境。监控不是什么遥不可及的高端技术，它就是给系统做一次“体检”，让你知道它在干嘛、状态怎么样、有没有生病。

一、一个比喻：监控就是系统的体检报告

你去医院体检，医生不会只给你量一个体温就说你身体健康。他要抽血、拍片子、做心电图，每一项检查都在看不同的东西：血液看内部生化指标，X 光看结构，心电图看心跳规律。

系统监控也一样。 你不能只看 CPU 使用率就说“系统很健康”。你需要从多个维度去了解系统的运行状态。

体检有三类核心检查项目，系统监控也有三大支柱：

这就是业内有名的“可观测性三支柱”。后面的文章会逐一深入讲解，今天我们先建立一个整体的认知框架。

很多团队对监控的心态是：“等系统稳定了再说”。这就像等生了病才去买保险——晚了。

没有监控，你上线就是在“盲飞”。 以下是我见过的真实场景：

一个 API 响应时间从 50ms 慢慢涨到 500ms，没人发现。直到用户投诉，研发去排查才发现数据库缺了个索引。如果有个简单的响应时间监控，这个问题在 100ms 的时候就会被发现。
一次发布修改了功能开关配置，某个灰度人群触发了一个未完成的 feature，导致大量请求走到错误处理分支，每小时产生几百条 500 错误。因为没有对 HTTP 500 状态码做实时监控告警，错误持续了一天才被发现，用户投诉进来之后才开始排查。如果接入了监控：QPS 正常但错误率从 0.1% 跳到 5%，告警会在分钟级别触发。
磁盘空间一天天被日志填满，直到凌晨服务挂了，运维被紧急叫醒。一个磁盘使用率监控就能避免这场凌晨的“夺命连环 call”。

监控不是在浪费你的时间，是在帮你省时间。 它把“被动救火”变成“主动预防”，把“用户告诉你出问题了”变成“你知道问题后告诉用户”。

在深入具体技术之前，有几点心态要先建立起来。这些比装什么工具更重要。

不要一上来就想搭建完美的监控体系。你连问题在哪都不知道，怎么可能搭出“完美监控”？正确的顺序是：先监控你最担心的东西，然后根据线上问题逐步补全。

第一步：监控 CPU、内存、磁盘、网络这四项基础指标。这是免费的，任何监控工具都能做。第二步：监控业务关键接口的响应时间和错误率。这是你用户真正能感受到的东西。第三步：根据线上事故反推——每次出了问题，问自己“如果监控了什么，这次能被更早发现？”然后把这个指标加上去。

监控不是越多越好。我见过一个团队，Grafana 上有 300 多个 dashboard，但没有一个人能说清楚现在系统的健康状况。

好的监控讲究“信噪比”。 你需要的不是面面俱到，而是关键指标的清晰呈现。后面讲到告警设计的时候，这个问题会特别突出——告警太多等于没告警，因为大家会把告警通知静音。

CPU 使用率 80%，这高不高？——看情况。如果是平稳运行在 80% 且业务正常，那可能只是资源利用率高，不是问题。但如果 CPU 使用率从 20% 在一小时内涨到 80% 且还在涨，这就是紧急事件了。

单点数值容易误导人，趋势和变化率才是监控真正的价值所在。

监控是一个很大的话题，这篇文章只是开个头。接下来的几篇，我们逐一深挖：

篇目	主题	核心内容
第二篇	日志采集	日志怎么收集、怎么存、怎么查？ELK、Loki 怎么选？
第三篇	指标监控	Prometheus + Grafana 怎么搭？什么样的指标才是好指标？
第四篇	告警设计	为什么告警让人“麻木”？怎么设计真正有效的告警？
第五篇	链路追踪	分布式系统里一次请求经过了什么？Jaeger、OpenTelemetry 怎么用？

读完这个系列，你应该能独立为一个小型系统搭建一套基本可用的监控——从零开始，不依赖任何商业监控平台。

监控不是技术问题，是意识问题。你不需要成为监控专家才能开始监控，你只需要承认一个事实：没有监控，你就是在盲飞。先把最基本的指标收集起来，把“系统现在怎么样”这个问题回答清楚。后面的报警、分析、优化，都建立在这个基础之上。

下一篇，我们聊聊日志——最原始、但也最容易被忽视的监控数据源。

每天前进一小步，就是一个新的高度！