Skill 系列（04）：Skill 指标体系——L1/L2/L3 三层监控，让质量下降有据可查

分类：技术
阅读时间：约5分钟

引言：为什么你的“质量”总是一言难尽？

你一定遇到过这种情况：某个功能上线后，用户反馈“卡顿”“报错”，但测试环境一切正常。你反复检查代码，却找不到根因——直到半夜业务量暴增时，才看到服务器CPU飙到99%。

问题出在哪？不是没有监控，而是监控的颗粒度不够。
今天要讲的“Skill 指标体系”，就是一套从粗到细、从宏观到微观的L1/L2/L3三层监控模型。它像一个倒金字塔的放大镜，帮你精准定位质量下滑的“病灶”。

一、什么是L1/L2/L3？一个比喻让你秒懂

想象你在管理一座城市：

L1（城市级）：总GDP、犯罪率、停电次数——只要这些数据平稳，城市就“看起来没事”。
L2（街区级）：某个区的交通事故率、供水管道破损数——这里有些细节，但还不够小。
L3（家庭级）：哪家下水道堵了、哪户暖气不热——这才是你处理投诉的最终落脚点。

对应到系统监控：

L1：业务总请求量、全局错误率、核心响应时间（P99）
L2：按服务/模块分拆的错误次数、延迟分布、慢查询数
L3：单次请求的完整调用链、具体的错误堆栈、慢SQL语句

记住核心逻辑：L1报警→L2初步定位→L3根因分析。
没有L3，你只知道“系统慢了”，却不知道是数据库还是队列出了问题。

二、三层指标的具体设计：从“看到问题”到“找到问题”

1. L1：宏观健康哨——让“大事”不放过

核心指标（建议监控3~5个）：

错误率：全局5xx/4xx占比（>1%报警）
核心接口响应时间（P99）：如订单提交、支付回调（>500ms报警）
活跃用户数/请求量：突然下降可能表示服务不可用
基础设施：CPU/内存/磁盘使用率（>80%预警）

真实案例：某电商平台双11大促时，L1监控发现支付接口P99从200ms暴涨到2s，触发自动告警。团队立刻进入L2排查。

2. L2：模块分解器——找到“哪个餐厅有问题”

操作方法：

按服务拆解L1指标：支付服务、商品服务、用户服务分别监控错误率和延迟
按流量入口拆解：App端、H5端、小程序端的差异
加入慢查询和死锁监控（数据库层）
设置分位数：P90/P95/P99分层观察

案例延续：L2发现“支付服务”的P99正常，但“订单服务”的数据库慢查询次数激增——原来是一个新上线的促销SQL使用了全表扫描。

3. L3：微观侦探——抓出“元凶”

必备工具：全链路追踪（如SkyWalking/Zipkin）、日志聚合（如ELK）、性能剖析（如Async-profiler）

典型操作：

看一次失败请求的调用链：是A调用B超时，还是B内部抛了Exception？
抓取慢SQL：哪个limit没加索引？哪个JOIN了千万级大表？
分析JVM线程栈：哪个线程卡在锁上？是死锁还是锁竞争？

最终结果：找到具体代码行、具体SQL语句、具体gRPC调用参数。

三、实战建议：0到1搭建你的三层体系

如果你是技术负责人，以下三步能让你用最少的成本见效：

先建L1：用Prometheus + Grafana搭三个面板（请求量、错误率、延迟），告警走钉钉/飞书。
再补L2：按微服务/模块打标签，在Prometheus中用sum by(service)分解，同时接入慢查询日志。
最后上L3：引入全链路追踪SDK（Java用SkyWalking，Go用OpenTelemetry），配合日志聚合搜索。

避坑提醒：

不要一上来就追求所有L3指标，否则监控系统本身会成为性能瓶颈。
L1/L2用1分钟粒度，L3用实时流式处理——成本控制是关键。

四、写在最后：从“经验主义”到“数据主义”

过去很多团队靠“谁的代码出问题谁背锅”来管理质量，但实际80%的线上故障是系统性缺陷：数据库设计不合理、依赖服务超时、内存泄漏累积……三层监控体系的价值，就是把这些隐性爆点变成显性指标。

你的行动号召：
今天下班前，花10分钟检查你的监控系统——

你是否有L1级别的面板？
一个L1告警后，你能在5分钟内找到L2的对应指标吗？
如果找不到，打开那个最慢的接口日志，看一次完整的调用链吧。

一个小心愿：下次有人问“系统是不是要崩了”，别只说“好像有点慢”——拿出三层指标的截图，让数据替你说话。

免责声明：
本文基于通用的系统监控最佳实践编写，具体实现需结合你的技术栈（如Kubernetes、Serverless架构等）调整数据采集方式。文中提到的工具（SkyWalking、Prometheus等）均为开源项目，使用前请阅读其官方文档并评估兼容性。任何系统改造都建议先在预发布环境灰度验证，避免因监控本身引发生产事故。

期待你的团队从“靠感觉”变成“靠指标”。下期见。