https://opentalk.upyun.com/333.html
2017 年 10 月 29 日，又拍云 Open Talk 联合 Spring Cloud 中国社区成功举办了“进击的微服务实战派北京站”。融数数据北京研发中心 CTO 王东作了题为《微服务下的APM全链路监控》。分享分为五个部分，从性能管理一直到现在的 microservice 对 APM 的大影响，然后自然去构建适合微服务的 APM 平台。王东认为：因为监控不是目的，目的也不是告警，目的是发现问题，所以本次分享，王东主要讲解了讲如何打造监控告警和保障的闭环，以及我们现在的产品对未来的一些商业层面上的思考。
以下是分享详情：
一、应用性能管理（APM）
什么是APM
APM (ApplicationPerformance Management) 即应用性能管理，属于IT运维管理（（ITOM）)范畴。主要是针对企业关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本（(TCO))。
APM主要特征有三个特征
- 多级应用性能监控：覆盖通讯协议1-7层，通过事务处理过程监控、模拟等手段实现端到端应用监测。
- 应用性能故障快速定位：对应用系统各个组件进行监测，迅速定位系统故障，并进行修复或提出修复建议。
- 应用性能全面优化：精确分析各组件占用系统资源的情况，并根据应用系统性能要求给出专家建议
APM的发展历程
APM的发展主要经历了三个阶段：
第一阶段：以网络监控基础设施为主，主要监控主机 的CPU 使用率、I/O、内存资源、网速等，主要以各类网络管理系统（NMS）和各种系统监控工具为代表。
第二阶段：以监控各种基础组件为主，随着互联网的快速发展，为了降低应用开发难度，各种基础组件（如数据库、中间件等）开始大量涌现，所以这个时期应用性能管理主要是监控和管理各种基础组件的性能。
第三阶段：以监控应用本身的性能为主, IT 运维管理的复杂度开始出现爆炸性的增长，应用性能管理的重点也开始聚焦于应用本身的性能与管理上。
第四节阶段属于我们的思考：云计算方兴未艾，而DevOps以及微服务的兴起对传统APM产生了很大的冲击，传统厂商也在做一些革新，也做一些微服务方面的尝试和云计算方面的尝试。随着Machine Learning、AI的技术的兴起，对定位故障、定位问题，也会起到一些帮助，基于大数据的分析的手段也会有一些帮助，在融数的产品里面也希望有所体现，当然我们还是在初步的尝试阶段。
2016年Gartner对APM的定义分为三个维度
1、 DEM-Digital experience monitoring：数字体验监控，浏览器及移动设备用户体验监控及利用主动拨测的实现的业务可用性及性能监控。
2、 ADTD-Application discovery, tracing and diagnostics：应用自动发现、追踪和故障诊断，自动发现应用之间的逻辑关系，自动建模、应用组件的深入监控及性能关联分析。
3、 AA-Application analytics：应用分析，通过机器学习，进行针对JAVA及.NET应用的根源分析。
二、微服务对APM的大影响
服务开发架构的发展历程
微服务带来的挑战主要有六点：依赖关系无比复杂，持续交付，容器化环境，服务注册、发现和可靠性，一切皆服务（Everything-as-a-Service) ，DevOps。
微服务对APM的影响主要分为三种
- 微服务的规模和动态性使得数据收集的成本大幅度提高，例如（CPUcpu、内存和网络传输的开销；）
- 大量的监控数据对后台数据处理分析的产生影响，服务的体量非常大的情况下，出现了问题之后，如何快速定位到发生问题的根本原因上，这需要大量的模型建立和机器学习；
- 对于可视化和关联分析的要求方面，传统APM缺少好的手段。
三、如何构建适于微服务的APM平台
建立一个基于微服务的APM平台和建立一个APM平台所面临的问题差不多，区别就在于平台的架构和是基于容器还是基于VM。这里要强调一点：监控和告警不以业务为目标就是耍流氓。
△ APM的核心能力
基于微服务的端到端的监控是比较复杂的，下图中是包括整体机房里全部内容，包括路由器、防护墙、交换机等，以及依赖的三方服务，和对外的服务的依赖和提供。
△ 基于微服务的应用程序端到端监控
以下两张图分别是APM探针的基本原理及融数数据APM探针的基本原理。
APM探针的基本原理
△ 融数数据 APM 探针的基本原理 (Java探针结构)
融数数据经常让客户看我们的成本，性能开销大概在3%到5%，收益就可以看到很多，包括改进，防止SQL注入，安全攻击，代码漏洞的定位，包括平均响应Apdex。
分布式追踪可以有效的将浏览器的监控、APM的监控、日志、移动端的监控全部串通，有些功能是没有完全实现的。最终目的就是追踪一切，也就是说从业务服务一直到微服务，或者是传统的中间件的JAVA代码，以及到主机容器和中间键的层级，每一个层级都会有追踪，然后通过流失数据处理做数据的收取和健康的检查。
△ 分布式追踪 – Google Dapper
△ 分布式追踪 – OpenTracing
追踪过程中可以做一些检测，比如说异常检测告警等等，通过数据的计算和分析，比如说通过拓扑，依赖的检查、关联分析、性能指标分析，以及实时计算，可以做数据的分析和计算。
△ 追踪一切
服务所依赖的环境信息，比如它在哪个域里面，它依赖的是在容器上跑，在VM上跑，物理机上跑，还是说在物理机的其他数据，比如说业务的划分，区域的划分，都是通过环境信息在CD中获取的。
△ 服务关联元数据
下图是融数数据APM的总体架构，我们把所有的JAVA技能叫中间件，agent是埋在中间件上，实的箭头是数据摄取的数据流。
△ APM总体架构
下图是融数数据的整个的APM的核心的能力，包括浏览器，融数现在浏览器也是有探针的，可以做到首屏、白屏时间，资源加载完成时间，到解析时间，用户IP、请求重定向时间，以及使用者使用什么设备来访问网页等等都有。应用服务器有比较多了，包括服务动态发现，IO异常，性能指数等等。
△ APM核心能力
四、打造监控、告警和报障的闭环
构建“开发+部署+监控+告警+报障”闭环，在运行环境下，拿到统一监控，一旦有问题会直接到轮值报障系统里，轮值报障会把它放到运维的数据库里，进到专业运营的分析报表里面去分析，然后来做一些改进。同时希望建成的一个理念，谁构建谁运维。
△ 构建“开发+部署+监控+告警+报障”闭环
1. 告警平台
下图是融数数据告警平台的架构图，告警数据源有APM、业务数据、日志和ITIM。
有些指标不需要自动的故障检测，有些指标通过简单数学的算法就可以，有些是有季节和周期性变化的，还有些是一个趋势，这时就需要自己来设置规则。
告警最糟糕的是漏告，一定要用算法去解决漏告问题。这里就涉及到告警归并和分发的问题。
- 告警归并：把多条类型相同的告警总结成一条告警
- 分发：每一类型的告警会有一个告警流水线，系统会根据告警的配置，发送到不同的流水线里，分布式的去处理这些告警。
2. 报障平台
报障平台很简单，首先把业务监控、系统监控和业务人员的报障通过我们的工单系统收进来，然后建造问题分类服务的分类树CTI，之后通过OnCall系统通知值班人员。通过故障分类系统、支持组，快速将接入的各监控系统报障通知给相应维护人员， 并通过配置的SLA及组织架构，对未及时响应的报障进行上告处理，以达到卓越运维的目的。
五、未来的思考和展望
大数据能力的充分释放-自动异常点检测
-
- 不同服务有不同的特点，避免修改每个服务的阈值。
- 在服务负载发生变化时，避免手工调整每个服务的阈值。
- 避免静态阈值造成的误报
- 在不生成报警的的情况下预测 不正常的指标，用于诊断问题