监控分层架构：从硬件到用户的全链路观测
做高并发系统监控，最怕什么？
我最怕的是「监控孤岛」。服务器CPU飙到99%，你以为是硬件问题，结果发现是应用层死锁；业务指标暴跌，你怀疑是代码bug，最后查出来是CDN节点挂了。你看，单点监控就像盲人摸象，永远看不到全貌。
所以，我习惯把监控拆成四层：基础设施层、应用层、业务层、用户端。每一层解决不同的问题，合在一起才能拼出完整画像。
核心观点：监控不是堆工具，而是分层治理。每一层都有明确的关注点和指标，缺一不可。
1. 基础设施层监控：地基不能塌
这一层是最底层的保障。说白了，就是看服务器、网络、中间件这些「硬件」是否健康。
我见过太多团队，一上来就搞APM、搞调用链，结果服务器磁盘满了都不知道。嗯，这是本末倒置。
核心指标
- CPU使用率：别只看平均值，要看P99峰值。我曾经遇到过CPU每10秒飙到95%又回落，平均只有40%，但系统已经卡得不行了。
- 内存使用：注意OOM killer的触发。我习惯设置内存使用率超过85%就告警，留出缓冲。
- 磁盘I/O：iowait是个关键指标。如果iowait持续超过30%，你的数据库大概率在受罪。
- 网络带宽：入站/出站流量、丢包率、重传率。重传率超过1%就要警惕了。
- 中间件状态：Redis、Kafka、Nginx的连接数、队列积压、延迟。
我的习惯：基础设施层告警要「快」。CPU飙高、磁盘满这类问题，必须在1分钟内通知到人。别等业务挂了才反应过来。
2. 应用层监控：代码跑得怎么样？
基础设施没问题，那就要看应用本身了。这一层关注的是你的服务、接口、JVM、调用链。
我记得有一次线上事故，用户反馈页面打不开。基础设施层一切正常，CPU、内存都低。最后查出来是某个接口因为参数校验bug，导致线程池耗尽。这就是应用层监控的价值。
核心指标
- 接口响应时间：P50、P95、P99都要看。P99超过1秒，用户体验就会明显下降。
- 错误率：5xx、4xx的比例。我习惯把错误率告警阈值设在0.5%以上。
- 调用链追踪：哪个服务慢了？哪个数据库查询拖后腿？用Trace ID串联起来。
- JVM指标：GC频率、GC耗时、堆内存使用、线程数。Full GC超过1秒就要排查。
- 连接池：数据库连接池、HTTP连接池的活跃数、等待数。
避坑指南：我曾经遇到过应用层监控把日志打爆了磁盘。每个请求都打印全量参数，一天产生200GB日志。记住：监控本身不能成为故障源。采样率、日志级别要控制好。
3. 业务层监控：公司赚不赚钱？
这一层，技术人容易忽略。但老板最关心的是这个。
业务层监控，说白了就是把技术指标翻译成业务语言。比如：订单量、支付成功率、用户注册数、DAU、转化率。
我习惯在业务层做「同比」和「环比」对比。比如今天上午10点的订单量，比昨天同一时段下降了20%，那一定有问题。可能是推荐系统挂了，也可能是支付通道出故障了。
核心指标
- 核心业务流程：注册→登录→浏览→下单→支付→完成。每一步的转化率。
- 收入相关：GMV、客单价、付费用户数。
- 用户行为：活跃用户数、留存率、会话时长。
- 业务异常：下单失败率、支付超时率、退款率。
关键点：业务层告警要「准」。别因为一次小波动就半夜叫醒所有人。我一般设置：连续3个数据点偏离基线超过20%才触发告警。
4. 用户端监控：真实体验才是王道
这一层，是离用户最近的监控。服务器再好，代码再优，用户手机上卡顿、白屏，一切都是白搭。
我记得有一次，后端所有指标都正常，但用户投诉说页面加载慢。最后发现是某个第三方JS脚本阻塞了渲染。这种问题，只有用户端监控才能发现。
核心指标
- 页面加载时间：FCP（首次内容绘制）、LCP（最大内容绘制）、TTFB（首字节时间）。
- JS错误率：前端报错的数量和分布。我习惯按浏览器版本、操作系统维度聚合。
- API请求耗时：从用户端发起到收到响应的完整时间。
- 用户体验评分：比如Google的Core Web Vitals指标。
- 地域/运营商分布：不同地区、不同运营商的访问质量。
我的做法：用户端监控一定要做「采样」。全量采集会消耗用户带宽和电量。我一般设置1%的采样率，对于错误日志则全量采集。
四层联动：一个真实案例
讲个我亲身经历的事故吧。
某天下午，业务层监控显示「支付成功率」从98%骤降到60%。业务同学慌了，以为是支付通道出问题。
我打开应用层监控，发现支付接口的P99耗时从200ms飙升到5秒。再往下看基础设施层，支付服务的CPU使用率只有30%，但数据库的活跃连接数爆了。
最后查出来，是某个促销活动导致一个慢SQL把数据库连接池占满。用户端监控也印证了：用户点击支付按钮后，页面卡住超过10秒。
你看，四层监控缺一不可。如果只看业务层，你会误判为支付通道故障；如果只看基础设施层，你会觉得一切正常。
总结一张表
| 监控层 | 关注点 | 典型指标 | 常用工具 |
|---|---|---|---|
| 基础设施层 | 硬件、网络、中间件 | CPU、内存、磁盘、网络 | Prometheus + Node Exporter |
| 应用层 | 服务、接口、JVM | 响应时间、错误率、GC | SkyWalking、Pinpoint |
| 业务层 | 核心业务指标 | 订单量、转化率、收入 | Grafana + 自定义埋点 |
| 用户端 | 真实用户体验 | 页面加载、JS错误 | Sentry、自建RUM |
最后说一句：监控分层不是死板的。你可以根据自己系统的复杂度，适当合并或拆分。但核心思想不变——从底层到顶层，每一层都要有「眼睛」盯着。