第1章：远程监控体系设计

监控体系设计，说白了就是给系统装上一双「眼睛」。我做了这么多年运维，见过太多团队一上来就堆监控工具，结果告警比业务流量还猛。嗯，今天咱们就聊聊怎么把这双眼睛装得既看得清、又不瞎报警。

1.1 监控分层模型

我个人习惯把监控分成三层：基础设施、应用、业务。这三层缺一不可，就像盖房子，地基不稳、墙不牢、屋顶漏雨，哪个都住不了。

基础设施层

这是最底层，也是最容易出问题的地方。CPU、内存、磁盘、网络，这些是硬指标。我在项目中遇到过，有一次磁盘IO被打满，应用层监控一切正常，但用户就是觉得慢。后来查了半天，才发现是隔壁团队在跑大数据任务。

• 计算资源：CPU使用率、负载、上下文切换
• 存储资源：磁盘容量、IOPS、读写延迟
• 网络资源：带宽、丢包率、连接数
• 虚拟化层：宿主机资源争抢、虚拟机漂移

应用层

这一层关注的是服务本身的状态。比如进程是否活着、接口响应时间、错误率。我曾经踩过一个坑：进程监控显示正常，但实际已经死锁了。所以光看进程存活是不够的，还得看它能不能正常处理请求。

业务层

这是最接近用户感受的一层。比如电商网站的订单成功率、支付转化率、用户登录耗时。业务监控的难点在于，很多指标需要从日志里提取，而且业务逻辑变了，监控也得跟着改。

1.2 监控数据采集方式

数据怎么来？主要有三种方式：Agent、API、日志。每种方式都有适用场景，我一般混合使用。

Agent方式

在目标机器上装一个代理程序，由它主动采集数据上报。这种方式最常用，比如Prometheus的Exporter、Telegraf。优点是实时性好，缺点是每台机器都要装，维护成本高。

# 一个简单的Prometheus Node Exporter配置示例
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

API方式

通过调用目标系统的API来获取数据。比如云厂商的监控API、数据库的监控视图。这种方式不需要装Agent，但受限于API的调用频率和返回格式。

日志方式

从日志里提取监控指标。比如统计Nginx日志里的请求量、错误码。这种方式适合业务监控，但需要做日志解析，延迟会高一些。

采集方式	优点	缺点	适用场景
Agent	实时性好，数据全面	维护成本高	基础设施监控
API	无需安装，灵活	受限于调用频率	云资源、第三方服务
日志	信息丰富，可回溯	延迟高，解析复杂	业务监控、审计

1.3 监控指标设计：黄金信号

Google的SRE团队提出了四个黄金信号：延迟、流量、错误、饱和度。这四个指标基本能覆盖大部分场景。我自己的经验是，再加一个「可用性」会更完整。

延迟（Latency）

请求处理的时间。注意，不是平均值，而是分位值。P99延迟比平均值更有意义。你想想看，平均延迟100ms，但P99可能是5秒，那用户体验其实很差。

流量（Traffic）

系统承载的请求量。比如QPS、TPS、带宽使用率。流量突然飙升，可能是好事（活动大促），也可能是坏事（被攻击）。

错误（Errors）

请求失败的次数。包括显式错误（5xx）和隐式错误（返回成功但内容不对）。我建议把错误率按类型分开监控，方便定位问题。

饱和度（Saturation）

资源被用到了什么程度。比如CPU使用率80%以上、内存剩余不足10%。饱和度指标能帮你提前发现瓶颈，避免系统崩溃。

1.4 知识体系总览

下面这张图是我自己画的，把本章的核心逻辑串起来了。你可以把它当作监控体系设计的「地图」。