主机监控回答”机器还扛不扛得住”，业务监控回答”用户还能不能用”，把两者混在一起看，故障发生时你会被几十条告警同时轰炸，却分不清哪个才是真正要处理的，核心结论：业务层监控必须独立于主机监控单独看，因为两者处理的对象、告警的语义、响应的紧急程度完全不在一个维度上。
很多团队最开始做监控，手段很朴素：盯CPU、看内存、查磁盘，这套逻辑在单机时代够用，但今天大多数业务跑在微服务架构上，一个用户请求要经过网关、鉴权、订单、支付、消息队列五六个环节，每个环节的主机指标看着都正常，但业务端到端就是走不通，这时候只有主机监控,你连从哪儿下手都不知道。
业务监控和主机监控的区别，为什么必须分开
要理清这个问题，先得搞清楚两个监控各自看什么，主机监控的对象是机器资源，业务监控的对象是用户可感知的服务质量，两者唯一的交叉点是业务最终运行在主机的进程上，但交集归交集,不能等价替换。
监控对象不同：一台机器的”健康”和一个业务的”健康”是两码事
主机监控盯着的是CPU使用率、内存剩余量、磁盘IO、网络带宽这类资源指标，这些指标反映的是机器有没有超负荷，是不是快被跑满了，但业务监控盯着的是接口成功率、响应耗时、下单流程完成率、支付回调延迟这些业务动作的结果,反映的是用户侧的实际体验。
举个例子：一台服务器CPU只有20%，内存充足，磁盘空闲，主机监控看起来很健康，但实际业务场景中，应用连接池被打满，线程全部阻塞在等待状态，用户点任何按钮都是转圈圈，这种时候主机监控数据漂亮得很，业务却已经死了，反过来也一样，一个批量任务跑起来CPU吃到90%，对主机来说压力很大，但用户完全不感知，业务层面没有任何问题，两种监控回答的是不同的问题,分开看才不会被彼此的噪音干扰。
告警的处理逻辑完全不同
主机监控的告警，处理方式通常是扩容、加机器、清理日志、优化SQL，偏向资源调度层面，业务监控的告警处理方式是查代码逻辑、查依赖服务、查第三方接口，偏向功能修复层面，两类告警对应的负责人能力模型不一样,响应时效要求也不一样。
主机告警通常有一定的提前量，内存是逐步涨的，磁盘是慢慢满的，给运维留出了反应时间，但业务告警往往是突发性的，前一秒正常，下一秒支付成功率掉到几乎为零，这种告警需要立刻投入排查，晚几分钟损失的就是真金白银，如果把业务告警和主机告警混在一个监控大盘里，等同级别的资源告警一多，业务告警很容易被淹没，处理优先级被拉低,代价就是故障时长被拉长。
故障排查的起点就不是一回事
吃过亏的运维都有感受：用户报障”页面打不开”
，如果监控面板上只有主机数据，你的排查路径往往是先开一台机器看负载，再看有没有报错日志，翻半天可能找出一个根本不相关的原因，但如果有一套独立的业务监控，故障一发生，直接从上往下看：是接口超时？是成功率下降？是哪个环节的依赖变慢了？从业务链路的入口往出口走，每一步都有数据支撑,定位效率完全不一样。
业内专家指出：业务监控存在的意义是缩短故障排查的MTTR（平均恢复时间），而不是替主机监控做备份，两者分析问题的路径完全不同，分开看不只是为了整洁,是为了让每条排查路径都保持清晰。
只做主机监控，业务故障为什么总是漏报
这是很多团队的真实困惑：监控该做的都做了，主机层面没有异常告警，为什么业务故障总是先由用户打电话投诉才发现？原因不复杂,主机监控的模型本身就覆盖不了业务场景。
典型故障场景：主机没垮，服务却已经死了
Java应用假死是最经典的案例，进程还挂在系统里，端口还能通，但JVM的线程池全部阻塞，垃圾回收频繁到近乎停顿，任何请求进来都处理不了，从主机监控的视角看，CPU占用可能只有5%，内存没有溢出，网络连接数正常，这种故障主机监控完全无感，但业务监控只要放到应用层做一次健康探测,立刻就能发现。
再比如数据库连接数打满，应用进程活着，主机资源也没耗尽，但数据库连接池把新请求全挡在外面，主机监控只能在数据库服务器上看连接数涨没涨，但连接数涨到什么程度会导致业务不可用，这取决于业务逻辑，主机监控无从判断，套用一句行业共识：主机监控能证明机器活着,但不能证明业务活着。
端口存活不等于业务可用
很多团队用TCP端口探测来充当业务监控，端口能连上就认为服务正常，这是很大的误解，端口通只能说明进程还在监听，但进程内部可能已经在报错风暴里挣扎，一个Web服务，端口通着，但所有请求返回HTTP 500；一个数据库，端口通着，但查询全部超时，这些情况用一个简单的”存活检测”是不管用的,必须从业务返回数据做判断。
业务链路的故障点往往不在自己主机上
现代业务系统大量依赖第三方服务：支付宝和微信的支付接口、短信验证码通道、云上的对象存储、CDN节点，这些依赖环节如果出故障，你把自己的主机看烂了也发现不了原因，主机监控只能看到你对端口的连通性，看不到第三方接口的成功率和耗时变化,而这些恰恰需要业务层的拨测来覆盖。
业务拨测
近几年，越来越多的团队把拨测当作业务监控的重要补充，模拟真实用户的操作路径，周期性地执行一遍流程，然后把每一步的响应时间、成功率作为业务监控指标展示出来，这样做的好处是，无论依赖的是内部服务还是外部接口，只要业务流程走不通，监控一定会报警,不需要关心具体是哪一层出了问题。
业务监控怎么做才能发现真实故障
分开看不光是理念，更要有具体的方法，业务监控的搭建不需要一步到位，从核心链路开始,逐步扩展。
先定义什么是对业务来说最重要的指标
不是所有接口都值得做业务监控，要抓核心链路，做电商的，关注加购、下单、支付、退款这条主链路；做内容平台的，关注登录、刷信息流、发布内容、评论互动,指标通常围绕三个维度：
- 成功率：核心接口的成功率，低于阈值就触发告警，阈值建议按业务要求设定，比如支付成功率低于99.5%就要重视
- 响应耗时：分位数监控，重点关注P95（95%请求的响应时间），比平均值更敏感
- 流量异常：QPS突降或突增，往往意味着依赖服务挂掉或者被攻击
配合全链路监控做根因定位
业务监控负责发现问题，全链路追踪负责定位问题，两者配合，业务监控发现异常，全链路追踪能把一条请求从入口到出口的每一步耗时展示出来，落到具体的主机、具体的SQL、具体的依赖调用，这个时候再去看主机监控，就是带着问题去查证,而不是漫无目的地排查。
分离告警通道，按优先级流转
主机告警和业务告警应该走不同的通知通道，业务告警直接推给应用负责人和研发值班人员，主机告警推给基础设施运维，告警处理平台里分开配置，避免业务故障的告警被资源告警刷掉，同时业务告警要做聚合降噪，同一链路的多条告警合并成一条,避免故障发生时成千上万条告警把真正的原因淹没掉。
配套高频巡检脚本
有些业务指标的接入成本较高，可以先从脚本层面补充，比如用curl模拟用户请求，定时检查返回状态码和耗时，异常时推送告警，这类脚本在故障发生时能提供最直观的证据,配合日志可以快速定位代码层的错误。
| 维度 | 主机监控 | 业务监控 |
|---|---|---|
| 核心指标 | CPU、内存、磁盘、带宽 | 成功率、耗时、QPS、事务数 |
| 告警语义 | 机器资源紧张 | 业务功能不可用 |
| 首要受众 | 基础运维、DBA | 应用开发、业务负责人 |
| 响应时效 | 通常有提前量 | 多为突发，需立即响应 |
| 排查方式 | 扩容、优化资源 | 查代码、查依赖链路 |
| 故障表现 | 指标缓慢爬升 | 用户可感知的功能异常 |
业务监控数据怎么维护，什么时候看什么
分开看不等于建两套完全割裂的系统,而是在统一监控平台里做清晰的视图拆分。
日常巡检和告警处理的主次关系
日常工作流建议这样排：业务监控告警永远排在最高优先级，因为它直接关联用户可感知的故障，主机监控告警按级别分流，高级别（如磁盘满了、宕机）那不用等业务告警，直接处理；低级别（如CPU短暂高负载）可以先观察,不占用值班人员注意力。
业务监控的指标也会有噪音
不是所有业务指标的波动都是故障，促销活动期间QPS暴涨引发的耗时增加是正常现象，大规模的爬虫访问也会人为拉低成功率，所以在业务监控的指标上要做基线学习，用历史数据自动调整告警阈值，避免死板地设定固定值，这也是一个成熟业务监控系统应该具备的能力区分正常波动和异常波动,不依赖人工去配规则。
长期趋势的分析价值
业务监控除了告警，还要承担趋势分析的工作，看一个接口的P95耗时在一个季度内是缓慢上升还是平稳下降，可以提前感知系统性能是否在劣化，这种趋势级的数据分析是主机监控无法提供的，因为主机资源的波动是短期的、局部的,而业务指标的变化才反映系统整体质量的走向。
常见问题
业务监控和主机监控分开看，会不会增加监控系统的运维成本？
不会，反而会降低整体成本，分开看的本质是在同一个监控平台上做数据分层和视图分组，而不是搭建两套相互独立的监控系统，主机监控和业务监控都有自己的数据采集逻辑，按照各自的频率和策略运行，展示在不同的仪表盘上即可，通过标签机制关联主机和业务，排查时可以互相跳转，真正的额外成本在前期梳理核心链路和定义业务指标的阶段,这部分投入通常在第一次故障排查时就能回本。
业务监控怎么做才能减少告警轰炸？
核心思路是聚合和降噪，先把告警按业务链路聚类，比如支付链路涉及五个服务，其中任何一个出问题都统一归为”支付链路异常”，而不是分别发五条告警，设定合理的告警沉默周期，同一条规则在短时间内不重复触发，为告警设置依赖关系和父子层级，底层告警触发后，上层衍生告警自动抑制，多数情况下,这三条规则落地后告警量能减少八成以上。
中小团队没有专职监控工程师，怎么起步做业务监控？
从最简单、最核心的开始，不需要一次性搭建完整的全链路系统，先用开源的拨测工具或者几行脚本，对线上核心接口做定时探测，检查返回码和响应时间，然后把脚本的探测结果接入现有监控平台（如Zabbix、Prometheus均可），配置告警规则，稳定运行之后再逐步扩展，覆盖次要链路，引入更复杂的协议探测，中小企业不需要追求监控系统的宏大完整，能先于用户发现业务故障,就是业务监控的第一阶段价值。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/627656.html
