开发者工具
打造围绕开发者全生命周期的工具产品
https://developer.aliyun.com/…;utm_content=g_1000283729
随着云原生技术的倒退与演进，微服务和容器化技术成为大型分布式 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 列表和利用的变更记录发现与上一次公布的定时工作相干，通过运维零碎回滚后解决问题。
监控管理体系
好的监控体系除了有优良的监控性能以外，还必须有与之配套的管理系统。阿里巴巴采纳了故障治理驱动的监控管理体系，为各个部门、团队制订了严格的量化故障等级定义。故障等级定义间接与业务监控指标关联，明确不同故障等级对应的指标触发规定。平安生产团队会与各业务部门梳理外围业务场景、业务指标和故障等级定义。梳理实现的“业务监控”配置和“故障等级定义”须要通过评审达成统一，使得业务团队（经营、产品、客户）与研发团队之间造成对立的监控规范，明确各方的职责，升高沟通老本，实现监控后果与业务指标的强关联。
整个故障定义的过程都是线上化和结构化的，当业务指标超出故障定义的范畴时，故障台会主动触发故障通告，并将通告信息及时发送给相干团队的技术人员。技术人员通过故障通告疾速查看业务监控数据，通过全景监控的纵向拓扑联动能力，从业务指标下钻剖析到关联利用状态，再从利用状态下钻剖析到云资源状态，实现疾速故障定位。而后技术人员依据故障排查的信息，确定故障复原计划，并通过运维平台执行回滚、降级、切流等操作疾速复原故障。整个过程都在线上实现，故障排查的停顿会主动推送给相干人员，所有操作都会被记录。最初由平安生产团队组织故障复盘，制订改良措施、欠缺监控笼罩，实现业务平安生产的正向反馈。
总结
全景监控不仅是业务、利用、资源等分层监控能力的简略集成，更重要的是具备通过业务指标下钻剖析到利用状态，及从利用状态下钻剖析到资源状态的纵向拓扑联动能力，也是各层指标的智能化健康检查能力的一体化监控。全景监控直击传统监控平台缺失业务监控能力、各层监控数据及报警扩散、监控配置老本较低等痛点，基于阿里巴巴弱小的监控技术积攒和应急故障解决的最佳实际，为阿里巴巴经济体提供一体化、一站式的监控解决方案，是阿里巴巴平安生产治理的最佳实际。