2.1 监控对象分类：基础设施、应用、网络、业务

2.1 监控对象分类：基础设施、应用、网络、业务

本节摘要：监控对象天然分成四层，从物理机一直爬到业务：基础设施、应用、网络、业务。每层的观测重点、数据类型、告警阈值的逻辑都不一样。分层的目的不是为了分类而分类，是让你不会漏看——很多漏了的告警，其实是把指标错放了层。本节把四层的边界划清楚，每层给你列好必须拿在手里的几个观测点。

为什么先分层

我在值班室见过一个案例：整个系统 CPU 跑满了，但业务指标全绿。为什么？因为应用层指标没问题，但数据库进程在夜里偷偷把数据库内存交换到了 swap。监控只盯了业务层和应用层，漏了操作系统级的 swap 指标。分层的好处就是让你不会漏：从底层向上数，一层不漏地把"哪些东西可能坏"列出来，再逐个给关键指标上桩，这比想到哪盯到哪靠谱得多。

我们用从底层往上爬的顺序分四层：最下面是基础设施，往上走是网络，然后是应用，最上面是业务。每一层坏了都会把上面的全拖死，所以先从最底层开始，一层一层往上建桩。

第一层：基础设施

这一层是物理和操作系统级的东西：物理机、虚拟机、容器、操作系统内核。它在最底下，所以如果它出问题，整栋楼都会晃，监控必须先盯它。

最核心的观测点是四个：CPU、内存、磁盘、网络接口。这四个是操作系统给的四个基本健康温度计。

CPU：关注使用率（平均负载、每核使用率），上下文切换次数，中断次数。平均负载超过 CPU 核数的 70% 就值得警惕，超过就是压力已经够大了。还要看 idel 占比，它是"还有多少算力能给业务用"。

内存：关注总使用率，可用物理内存，缓冲区、缓存占用，swap 换入换出率。swap 一旦开始大量换页，性能掉得会非常快——这就是本文开头那个案例漏看的点：物理内存紧张才会触发 swap，只要 swap 的换入率不为零，就是压力信号。

磁盘：关注使用率（剩下多少空间），读写速率，IOPS，平均响应时间。100% 使用率不用多说，肯定告警；响应时间超过数十毫秒就是 IO 瓶颈，这个比"使用率百分之几"更能反映用户感受。

网络接口：关注带宽利用率，收发包速率，收错包率，丢包率。错包和丢包是硬件或者交换机层面故障最直接的信号，一旦有持续错包，不管流量多大都得触发告警。

容器环境下，上述指标的关注逻辑不变，只是被容器 namespace 隔离了，采集时要注意采集容器自己的额度而不是宿主机的总和。很多人用 Node Exporter 采集宿主机指标，忘了给每个容器单独开维度，结果容器跑爆了宿主机还绿，这是常见低级错误。

第二层：网络

基础设施之上是网络层。网络分内网和外网，都要盯，但观测重点不一样。

内网主要看交换机、路由器、防火墙等设备的端口状态、流量、丢包、延迟。这些设备在基础设施和应用之间，很多时候是"沉默杀手"——流量大、错包高，但应用层没告警，直到交换机端口打满丢包才发现。

外网要看带宽利用率，运营商丢包率，南北向延迟，CDN 命中率。对外提供服务的系统，运营商网络波动是家常便饭，CDN 命中率掉下来就意味着回源流量爆涨，这往往是缓存配置失效的信号，得及时发现。

网络层还有一个观测点：连通性探测。用 ICMP Ping 或者 HTTP 探测去定期测核心依赖的连通性，这比等应用层自己暴露异常更早发现问题。比如你的数据库依赖了域名解析，你可以给一个专门的探测任务，每分钟解析一次，超时就告警。

第三层：应用

网络之上是应用层，就是你写的代码部署进去那堆东西。这一层的观测点按角色分几个类别：

• 进程与 runtime：Java 的 GC 次数与时间、堆内存使用、线程数；Go 的 Goroutine 数量、堆分配、GC 停顿时间；Python 的进程数、内存使用。每个 runtime 都有自己的几个健康温度计，必须把它们曝出来。
• 服务端指标：当前监听端口存活、QPS、延迟分布、错误率、并发连接数。这是最核心的一组，服务有没有问题，先看这几个。
• 依赖指标：调用其它服务的 QPS、延迟、错误率。很多时候你的服务没坏，是你的依赖坏了，所以依赖的健康也得帮着盯——不然最后排查你还怪自己代码。
• 数据库/缓存指标：连接池使用率、查询延迟、慢查询次数、缓存命中率。连接池满了就是能压垮服务的常见原因，慢查询次数涨了就是索引需要优化的信号。

应用层最容易犯的错是"只盯自己，不盯依赖"。依赖挂了，你的服务也挂了，但你的指标全绿——这就是因为你没把依赖拉进监控范围。

第四层：业务

最顶层是业务层，这是离用户最近、也是领导最关心的一层。业务指标不是技术指标，它描述业务本身的健康状况。

举几个不同场景的例子：

• 电商：订单创建量、支付成功率、购物车转化率、商品搜索响应时间。
• SaaS：活跃租户数量、新建 workspace 数量、API 调用成功率、用户登录率。
• 内容社区：文章发布量、评论量、平均阅读时长、用户点赞转化率。
• 后端服务：任务完成量、任务失败率、队列堆积长度。

业务指标有个很重要的作用：帮你回答"到底影响了多少用户"。技术指标出问题但业务指标没事，说明这是后台任务或者非核心路径出问题，优先级可以低一点；反过来，技术指标都没事但业务指标掉了，说明有隐性故障，得立刻排查。

我个人的经验：技术指标是告警门，业务指标是确认门。技术指标先触发告警，你第一件事应该去看业务指标掉没掉——很多误报能在这里过滤掉，不会白叫起值班人。

四层的监控责任对照表

我们把它整理成一张检查表，你建桩的时候可以照着打勾：

本节要点回顾

• 分层从下往上：基础设施 → 网络 → 应用 → 业务，一层一层不漏。
• 基础设施核心四个：CPU、内存、磁盘、网络接口，每个盯最影响用户体验的指标。
• 容器别忘了隔离维度：采容器自己的，别只采宿主机总和。
• 应用层要盯依赖：你的服务没事，不代表依赖没事。
• 业务层是最后确认门：技术告警先看业务影响，过滤误报。
• 分层的目的：就是让你不会漏，不会把错指标放在错层里。

下一节我们从"对象"进到"指标"本身——把一堆可能的指标提炼成四个黄金信号，这是 Google SRE 喂出来的行业标准。