编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。
随着云原生技术的发展与演进，微服务和容器化技术成为大型分布式 IT 架构的必然选择。新技术在让 IT 系统变得更敏捷、健壮、高性能的同时，也带来了更高的技术架构复杂度，给应用监控带来了前所未有的挑战。
传统监控挑战
系统监控爆炸式增长
传统监控重点关注应用、主机、网络等系统层面的监控。随着微服务、云原生等新技术的大量运用，系统架构越来越复杂，应用数量呈爆炸式增长。当一个故障发生时，大量系统报警会产生报警风暴，使得技术人员无法快速定位问题。同时，大量的系统级监控会产生大量误报，技术人员*花费大量的精力去处理这些误报，最终对报警产生麻木。
监控结果和业务目标之间欠缺联系
传统监控缺少业务视角的监控，以及业务与 IT 系统之间的联系。这导致用户、业务人员和技术人员之间无法形成统一视角。很多故障往往是用户已经反馈，技术人员却在用系统监控指标证明系统没有问题。或者业务已经受损，技术人员依然无法确定是哪个系统的问题，恢复时间被大大拉长。
监控工具之间数据割裂，数据缺乏分析
以往阿里巴巴采用多种监控工具，用于监控网络、物理机、应用、客户端等不同的对象，但不同工具之间无法共享数据，监控数据缺乏统一的分析，更加难以跟业务场景相结合，造成大量的故障只能依靠技术人员的经验，在多个工具之间不断地切换和逐步排查，大大增加了故障恢复时长。
监控维护成本高，报警准确率低
传统监控都需要大量的配置工作，整个过程费事费力，缺乏自动化、智能化监控的手段，这也是造成各系统监控能力参差不齐的重要原因。一些新业务因为无力投入大量精力配置监控，导致业务监控能力缺失。同时，随着业务的发展，技术人员需要不断地调整报警规则，又常常因不及时的调整造成误报和漏报。
业务驱动的监控理念
为了适应 DevOps 研发模式，解决传统监控的问题，阿里巴巴总结了一套以业务驱动的自顶向下的全景监控体系，主要包括：业务监控、应用监控和云资源监控三层：
- 业务监控是整个监控体系的“顶层”，能够反映用户使用业务的真实情况，可以与业务结果直接挂钩，能够被不同部门、不同角色的人员所理解。
- 应用监控提供应用中服务和系统层监控能力，能够直接反应系统运行状态，帮助研发人员全面了解应用中服务和中间件的健康状态，快速定位系统问题。
- 云资源监控提供应用依赖的各类云资源(如 RDS、OSS、SLB 等)的基本监控，在故障排查中能够为研发人员提供实例级别的明细监控数据，快速确定是应用系统的问题，还是云基础实施的问题。
监控分层以后，各层的监控指标和报警规则会按重要程度分成严重、警告、普通等多个等级，不同层次、不同级别的监控报警会被分派给不同的角色来处理，比如集团的安全生产团队只关注全集团的核心业务指标，事业部的稳定性负责人关注部门级的核心业务监控，每个团队的研发人员则接收自己负责业务和应用报警，而云资源实例的监控一般不发送告警消息，主要用于故障排查和定位。这样充分发挥了 DevOps 的优势，传统模式中少数运维人员成为故障排查瓶颈的问题也得以解决。同时，每个人需要处理的报警数量大幅减少，也解决了在故障发生时因为报警风暴，而将重要的业务监控报警淹没的问题。
统一的监控架构
基于全景监控的理念，阿里巴巴探索出了一套统一监控的架构，该架构不追求大一统的监控平台模式，而是采用分层建设，抽象出了云资源，应用，业务这 3 种监控系统，每种监控都专注发现相关领域的故障发现，再通过统一 CMDB 解决监控元数据相互不统一的问题，通过智能算法平台，报警中心和故障平台集中管理事件，故障以及提升准确率。
业务监控
阿里巴巴“业务监控”采用专为监控自研的日志采集&计算框架，通过页面配置即可实时提取日志中的监控指标，具有简单易用、自定义能力强、响应速度快、对业务无侵入等特点；提供了完整的业务监控领域模型，引导用户完成监控覆盖。
业务监控的领域模型包括：
- 业务域：一个完整的业务或产品称为“业务域”，如电商的“交易域”、“营销域”、“支付域”等。
- 业务场景：业务域中的核心业务用例叫做“业务场景”，如交易域的“下单确认”、“创建订单”等，业务场景是
整个监控模型的核心。
- 业务指标：体现每个业务场景的特有指标，如每分钟的订单数量、交易成功率、错误码等。
在业务指标的选择上，传统的运维人员喜欢使用穷举式的手段配上所有可观测性的指标，各种告警加上，显得有“安全感”。实际当故障来临时，满屏出现指标异常、不断增加的告警短信，这样的监控看上去功能强大，实际效果却适得其反。
通过对阿里巴巴历年故障的仔细梳理，阿里巴巴集团内的核心业务的常见故障（非业务自身逻辑问题）都可以通过流量、时延、错误等 3 类指标反应出来，我们称之为黄金指标：
- 流量 ：业务流量跌零 OR 不正常大幅度上涨下跌，中间件流量如消息提供的服务跌零等，都可能触发重大故障；
- 延时 ：系统提供的服务 OR 系统依赖的服务，时延突然大幅度飙高，基本都是系统有问题的前兆；
- 错误 ：服务返回错误的总数量，系统提供服务 OR 依赖服务的成功率。
业务监控平台提供了“黄金指标”插件，通过单次配置就可以生成一组黄金指标，是目前业务监控使用范围最广的指标模型。
业务监控报警直接与故障关联，对监控数据的质量有很高的要求，同时需要具备很好的灵活性（既满足不同技术实现的监控需求，又不能对被监控的业务系统造成性能影响）。阿里巴巴的“业务监控”通过日志作为数据来源，能最大程度地保证业务监控的灵活性，能够适应几乎所有的技术栈。日志采集采用了无压缩增量采集、zero-copy 等技术，降低监控采集对业务系统的性能影响；采用拉模式架构、重试机制、数据齐全度模型保证了数据采集的可靠性和完整性；完全白屏化的配置能力、完善的调试功能，最大程度降低了用户的配置难度和配置成本。
应用监控
阿里巴巴应用监控采用标准化和组件化的方式搭建，与阿里巴巴技术栈相结合，提供常用的系统和中间件层面的监控组件；运维同学无需修改程序代码，整个监控过程自动化，应用上线、扩容后自动开启应用监控，无需人为操作，大幅降低了监控的维护成本。
当运维系统执行应用上线、扩容等操作后会将变更信息写入到 CMDB，CMDB 会将变更信息推送到MQ，应用监控平台订阅 MQ 实时获取应用的配置变化生成新的监控任务，监控任务下发到指定的目标服务器（容器）的 Agent 端，Agent 根据任务的配置信息发送对应的采集请求，从业务应用提供的 Exporter 等 EndPoint 中获取监控数据，并上传到监控集群进行计算和存储；同时异常检测模块也会根据应用配置的变化生成报警检测任务，从时序数据库中拉取监控数据进行异常检测，并将异常事件发送给报警中心。
云资源监控
阿里巴巴云资源监控直接对接阿里云平台的“云监控” API 获取各类云资源的指标数据和报警事件，再将这些数据与 CMDB 中应用与云资源的关系信息连接，最终形成应用视角的云资源健康状态视图，解决了云基础设施监控与上层应用监控相互隔离的问题。依托云平台的监控能力和 CMDB 的数据积累，整个云资源监控也是自动化完成的，无需用户人工配置。
智能检测平台
为了解决报警准确率低、配置维护成本高的问题，阿里巴巴建设了智能检测平台，通过 AI 算法精确地发现线上业务和应用的异常，并且在此过程中不需要任何人工配置报警阈值。针对业务和应用监控数据的不同特点，采取不同的异常检测策略：
1、 智能基线
业务监控对报警的准确性要求极高，同时数据会随着业务周期不断波动，高峰和低谷之间数据可能相差几十倍甚至上百倍。传统的阈值或同环比报警往往需要有经验的运维专家不断地调整规则，极易引发误报。对此，阿里巴巴采用智能基线算法通过历史趋势自动学习数据曲线的周期规律。当业务指标超出基线容忍范围时，就会立即触发业务报警。为了优化算法对数据的兼容性，智能基线算法通过在线预测的功能（即算法对往后一段时间的数据进行逐点预测），完成了对长期历史规律与近期历史规律较好地折衷；基于对阿里巴巴内部大量多样化业务指标的训练和专家经验标注，让平台对不同类型的业务波动能优雅地在算法中体现出来，算法可以很好地适配数据曲线中的波动毛刺及随业务产生的高低起伏，可一键接入各类业务监控数据；算法长期经受各种外部攻击及爬虫的内部压测干扰的历练，目前已具备了对干扰攻击较好的抵抗能力；算法可以很好的支持秒级与分钟级计算，无需任何人工监控配置，无需随业务变化对算法进行调参，算法可自己通过对规律的学习适应业务的变化。
2、 应用指标异常检测
应用监控指标数量众多，传统的人工配置阈值的方式成本极高。企业往往会采用报警模板的方式对大量应用配置相同的报警阈值，但由于不同应用系统的差异性较大，很难定义一个准确的阈值，这就容易产生“小了漏报，大了误报”的问题。系统指标的场景与业务指标不同，它的周期性更不确定，各个指标的浮动相对来说会比较大且没有周期特性。针对应用指标的特性，阿里巴巴又针对性开发了应用指标异常检测算法，通过断层检测、频率波动异常检测、尖峰/低谷异常检测、长期趋势渐变检测、浮动阈值等多种算法联合进行检测；同时由于应用监控指标数量众多，为了能够大范围使用，所有检测方式都采用了轻量化算法，大幅降低异常检测服务的资源消耗。
报警中心：统一对接各监控平台的报警事件，实现报警事件地统一记录、统一处理（合并、降噪、抑制等），最后发送到相关处理人。
故障管理平台：用于定义故障等级并管理整个故障生命周期的平台，命中故障等级定义的重要报警将升级成故障，进入故障管理流程。
CMDB: 运维统一 CMDB 是整个阿里巴巴应用运维体系的元数据中心，维护着整个阿里巴巴的产品、应用、实例（容器、VM、云资源）、机房、单元、环境等运维对象，以及对象之间的关联关系，各层的监控系统都与 CMDB 模型中的对象关联。
通过这样体系化的建设，我们不但能在故障发生时快速准确的发出告警，还具备了从业务入口下钻分析故障链路上各个关键应用，资源状态，甚至基础设施的能力。因此开发运维人员可以在一个监控界面上逐步排除故障发生时的可疑点，快速定界到故障发生的原因。
这里以某订单系统调用延时突增故障为例，介绍一下全景监控的故障排查过程：
- 线上问题发生的第一时间，负责该订单系统的研发 Owner 会收到报警中心的调用延时报警（如果线上问题达到故障等级标准，故障台将自动发送对应等级故障通告给相关人员）。
- 研发人员通过报警信息中的链接直接打开对应业务监控页面查看交易总调用量、延时、成功率等黄金指标数据，发现延时大幅升高，成功率有所下降，调用量没有明细下跌，排除上游流量徒增造成系统容量问题的情况。
- 通过业务监控的多维下钻功能，查看交易的错误码详情可以发现“超时错误码”大量增加，可以排除是业务逻辑类问题。
- 继续从业务监控下钻到应用监控，根据订单指标对应的调用链路发现，某下单应用的数据库调用成功率大幅下降，调用延时暴增。
- 再从应用监控下钻到云资源监控，查看该应用关联的数据库的 CPU、调用时长、慢 SQL 指标都出现异常，查看慢 SQL 列表和应用的变更记录发现与上一次发布的定时任务相关，通过运维系统回滚后解决问题。
监控管理体系
好的监控体系除了有优秀的监控功能以外，还必须有与之配套的管理系统。阿里巴巴采用了故障管理驱动的监控管理体系，为各个部门、团队制定了严格的量化故障等级定义。故障等级定义直接与业务监控指标关联，明确不同故障等级对应的指标触发规则。安全生产团队会与各业务部门梳理核心业务场景、业务指标和故障等级定义。梳理完成的“业务监控”配置和“故障等级定义”需要通过评审达成一致，使得业务团队（运营、产品、客户）与研发团队之间形成统一的监控标准，明确各方的职责，降低沟通成本，实现监控结果与业务目标的强关联。
整个故障定义的过程都是线上化和结构化的，当业务指标超出故障定义的范围时，故障台会自动触发故障通告，并将通告信息及时发送给相关团队的技术人员。技术人员通过故障通告快速查看业务监控数据，通过全景监控的纵向拓扑联动能力，从业务指标下钻分析到关联应用状态，再从应用状态下钻分析到云资源状态，实现快速故障定位。然后技术人员根据故障排查的信息，确定故障恢复方案，并通过运维平台执行回滚、降级、切流等操作快速恢复故障。整个过程都在线上完成，故障排查的进展会自动推送给相关人员，所有操作都会被记录。最后由安全生产团队组织故障复盘，制定改进措施、完善监控覆盖，实现业务安全生产的正向反馈。
总结
全景监控不仅是业务、应用、资源等分层监控能力的简单集成，更重要的是具备通过业务指标下钻分析到应用状态，及从应用状态下钻分析到资源状态的纵向拓扑联动能力，也是各层指标的智能化健康检查能力的一体化监控。全景监控直击传统监控平台缺失业务监控能力、各层监控数据及报警分散、监控配置成本较高等痛点，基于阿里巴巴强大的监控技术积累和应急故障处理的最佳实践，为阿里巴巴经济体提供一体化、一站式的监控解决方案，是阿里巴巴安全生产管理的最佳实践。
免费下载《阿里巴巴DevOps实践指南》
阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。
前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。