应用实时监控 ARMS 赋能培训| 学习笔记

开发者学堂课程【云原生中间件产品销售红宝书：应用实时监控 ARMS 赋能培训】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/629/detail/9894

应用实时监控 ARMS 赋能培训

内容介绍：

一、传统运维之昨天的故事

二、APM 定义

三、云上运维之美好的未来

在阿里云上怎么做一款监控，如何帮助客户提升监控的效率以及解决性能问题。

 

一、传统运维之昨天的故事

1、系统上线前

最早之前不是产品经理，是一个运维，经常做搭建监控系统，公司头号系统要上线了！我辛苦自建了监控系统，来应对对开发和PD宣告:老子搞的脚本监控和自动化预案，遇神杀神，佛挡杀佛。

2、系统上线中 ing

半夜，被故障报警惊醒，“夜间马拉松”开启，穿山越岭，气喘吁吁，查故障到天亮。

3、系统上线后

故障恢复后，成为众矢之的反省、故障回顾报告: 神马，说不清楚哪里的问题?环境的问题!

4、传统运维之跳槽

毕业一两年，已经有三年的经验，因为经常加班。

面试官:云计算情况下的系统运维怎么搞?

我:这个.....我可以会写脚本报数

偶然机会认识apm产品领域。开始深入进行研究到现在。

 

二、APM 定义

1、Gartner 2019 APM 魔力象限报告对于APM市场的定义:

（1）DEM ( Digital Experience Monitoring) : Web与移动端的可用性和性能监控。

（2）ADTD ( Application Discovery， Tracing and Diagnostics) :应用发现，链路跟踪及诊断。

（3）AIOps :使用大数据及机器学习技术，通过自动识别性能和事件的特征、时序数据的异常检测和自动根因定位，辅助进行IT运维。

2、重点关注 Gartner 预测到2021年会有20%的企业应用使用 APM技术，和2018年相比会有四倍的增长。

3、为什么要升级监控系统?

（1）收益:微服务提升研发效率;混部提升资源利用率。

（2）复杂度提升:自上往下难以定位问题，自下往上难以评估影响面。

传统互联网架构和传统企业架构，it系统各个都是独立的烟囱式的建设，后来搬到云上以后做成微服务，做成容器，复杂度提升，虽然开发和运维看起更简单，实际上本身提升的容器，难度会越来越高，因此对监控系统都提出更高的要求，因为原it系统上没有监控系统，也可以做比如 cpu 内存的诊断，没有强行看日志查 bug，但是云上系统从一台机器一台 ecs 变成 cum，而且 cum 分布式互相调用，就像从左边变成右边，原来用人力还能填的问题，现在一定要通过工具做提升。

4、监控体系建设评级--评判标准

建设的监控体系应该靠哪些标准评判建设的好不好，有三点，也是业界比较认可的。

（1）平均修复时间( MTTR-通常是从问题产生影响到被解决的平均时间)

（2）对每个问题进行故障排除所涉及的平均员工数。

（3）每次故障的量化程度。( 例如:故障影响的用户、每分钟失败的交易)

每一次故障可以量化影响多少，比如在阿里，出现故障，故障影响哪些用户损失多少金额，而大部分种种量化的程度是能更好的不断收敛故障。

5、监控体系评级---成熟度模型一LO

（1）常见问题

我们刚接到了一连串的电话表示网站或应用变得很慢，我们是否可以确认?

CPU、内存、磁盘和网络看上去都很正常啊，应用为什么还是那么慢?

某个请求是如何与IT基础设施关联的?

（2）特征

仅有基础硬件监控。

（3）使用 arms 原因

APM基础功能。

问题的用户在哪个级别可以有相应的推荐，l0级别的用户只用阿里云使用云监控，经常就会有问题，cpu内存磁盘和网络都很正常，但应用还是很慢，经常接到故障电话的报障或者用户投诉，不知道为什么，确认不了，只做最基础的硬件监控，这样的用户如果使用apm的功能，这些用户问题直接就可以解决掉。只要提交问题就再不会有。

6、监控体系评级---成熟度模型一L1

（1）常见问题

系统在客户那为什么还是这么慢?可是在我们办公室看上去很正常啊。

为每个关键调用打印日志将花费很长的时间，但是我敢打赌这是值得的。

有谁知道我们的应用之间存在的依赖关系吗?

（2）特征

有基础硬件和组件监控，日志监控。

（3）使用arms原因

ARMS无需埋点打印日志，实现监控。

以应用为中心建立监控输出最佳实践有效降低上手门槛。

已经用 apm 或者日志或组件的方式和传统的方式解决线上的问题，但是还是有类似的问题。比如系统在办公室里觉得很正常，客户也非常大，并且把所有的日志全打出来，花很长时间打这些东西，而应用也升级成分布式，但是根本不清楚是什么样的调用关系，用 arms 不用再打日志，无需打印更多的日志就可以实现非常好的监控效果。另外有一整套以应用为中心的建立监控的体系，帮助用户更好建立的监控。

7、监控体系评级--成熟度模型一L2

（1）常见问题

我们监控了每一个业务请求，但是我还想了解前端用户具体怎么操作的?

我们的新监控工具确实提供了很多的数据。但是看完所有的这些图表并深入挖掘这些数据将花费好几个小时。

出现了一些常见问题或者需要限流降级时，我还要手动操作。

（2）特征

开源 APM 产品

（3）使用 arms 原因

全栈监控，自动诊断，限流降级

到l2的用户已经使用开源的apm产品，监控到请求的时间并且能有大概有使用的体感，所有开源apm产品都不提供前端和移动端的监控，缺失的，所以当它出现业务请求缓慢时想了解不影响哪些用户，如何操作，在apm工具和常用的ecs或者rds不一样，不是硬件，不是买了就一定能用好或者买了就一定都能用，需要有学习门槛，看图表进行挖掘问题，最后定位到问题，如果只用开源工具，学习需要很大的成本，现在真的出问题以后怎么样帮助用户，就是线上出问题监控发现了，来不及修代码，如何让问题降低的影响，用限流降级的手段，只提供出现重大的故障，核心服务打500qps上来不可用，那需要控制流量不能再打，把流量打降下来，导致整个系统不能用，arms提供限流降级的功能保护核心的服务，有损的给用户使用。

8、与开源相比

（1）一款全栈监控工具(覆盖面全，监管控一体，阿里云适配)

（2）全托管，按量付费。(成本可控，灵活，无人力维护成本)

（3）阿里APM的最佳实践。( 知道什么样的应该有什么样的功

能和如何用起来这些功能)

总结和开源相比arms是全站工具，覆盖面全，能做浏览器监控也能做移动端监控，并且和阿里云上的rvs，slb等产品，天生集成在一起，比如调数据库出来缓慢的问题可以直接发现，并且和arms的报告结合在一起诊断，另外就是全托管，开源还要维护存储软件，需要很多的成本并且相较于维护成本的软件，硬件成本arms都是比它低的，另外要输出apm的最佳实践。告诉用户怎么样把些apm产品在系统里面最好的实施起来。

9、APM 具体监控什么问题?

有没有用户受到影响？

是否有交易失败？

是认证慢吗？

我能发现问题吗?我记录了所有性能数据吗?

业务应用慢?

主机的响应时间怎么样？

Web services 停了吗？

数据库的响应如何？

第三方系统是否满足 SLA 约定?

WebServer 怎么样？

10、ARMS 覆盖范围一一立足应用 ,覆盖全栈

以用户体验能监控浏览器h5 app小程序等，用户移动端和浏览器端的应用，当请求从移动端发到后端开始进入整个应用程序端时能告诉应用代码的请求，应用代码里有怎么运行的，哪里缓慢，sql缓慢还其他的缓慢还是调用数据库比较缓慢或调用缓存比较缓慢，很多能实时发现出来并且告诉原因，以及prometheu可以支持组件监控和S层的监控以及日程监控都是有提供类似的服务。

11、怎么采集:全栈覆盖方式-无侵入埋点全栈链路追踪

具体怎么样采集数据，通过全站的方式，比如要监控前端，那就装JS或者sdk不需要改任何代码引入就好，那要监控应用，起一个探针，监控存储也装探针，就可以实现全联路监控，数据天生是打通的，比如用户在前端点按钮，到最后访问应用访问数据库返回sql等，整个流程是全部串联在一起监控的，而不是割裂监控的。这时非常大的卖点。

12、ARMS 的计费方式

ARMS 采用后付费预付费购买资源包的形式收费。解决方案需另外按照人天计算。比如做全力压测或者做培训是按照人天另算价格。

计费单位是 Agent*Hour和PV。

Agent*Hour :可以一个Agent就相当于一台ECS , Agent*hour 就是监控一台ECS一个小时。

PV:页面访问次数。用户访问一次页面就记一次费。

详见产品价格页:

https://www.aliyun.com/price/product#/pts/detail

13、性价比最高的监控产品

举例:某客户有1000核2000G的节点，共有200应用节点

规格:预计需要买1个黄金资源包，可使用6个月

自建花费:服务器消耗1.5万元/月

ARMS消费: 1万元/月,比自建便宜0.5万

14、ARMS 产品 Q&A

（1）非阿里云客户能用吗?

可以,无论客户是公有云/专有云/混合云/自建IDC ,头部的用户，有腾讯云有华为云，甚至还有自建idc的，无论什么云厂商，只要在公网可访问就能通过ARMS来监控。

（2）使用上需要什么门槛吗?

非常低门槛的甚至比rbs使用还低门槛，不需要任何开发能力,只需要懂一点 linux 知识即可成功部署监控。

15、厂商 APM 产品对比

 

把同样云厂商的 apm 产品做对比，aws 产品的功能比较齐全，功能用不到，但是对于aws 的竞品不在国内提供，azure 提供同样的产品，但是在国内也没有产品提供，gcp 也一样，不仅用不到而且产品不是自研的，收购的，华为的产品虽然提供相对完整的一批产品但自己内部不用，所以用户体验和功能没有那么齐全，腾讯没有，由于腾讯本身不是java的，所以分布式能力没有怎么做。

阿里云自己给自己的定位是竞争者，虽然没有国外两个厂商做的好，但在国内还是算领导者，优势就是有全站的监控在java服务领域比较强的实战能力，基础设施比较强，成本相对于自己不管是所有竞品都是有优势的。

16、ARMS 客户场景

（1）迁移上云

上云迁移,监控先行,迁移无成本。

（2）项目管控

作为甲方需要实时了解应用稳定性

（3）开源方案替代

pinpoint或者skywalking

（4）新版本上线/ 架构升级

变更和升级必然带来稳定性问题，需要持续监控和快速修复。

（5）扩容

扩容后需要检验下资源是否达到预期性能,是否有扩容极限。

（6）友商竞品

ARMS更有价格优势，且功能丰富简单易用。

用户要搬站从云下搬到云上，搬站是有过程的，做监控是可以无痛的进行迁移，只要有需求，把a探证一步那的监控就可以先带用R零上门迁移，监控迁移不要成本，也能帮助在迁移的过程中发现的各种性能问题以及迁移过程中引发的故障快速的修复，

另外就是用户在新版本上线或架构升级，80%以上的故障都是由于升级导致，变更升级必然会导致稳定性的问题，需要持续的监控和快速修复减少的损失，所以当用户出现新版本上限和价格升级时都可以推，项目管控比如像移动大甲方的应用是由像华为等乙方开发的。云平台是阿里云或者其它的云厂商做的，管控出问题要迅速的把问题定为是亚性的问题还是华为的问题还是平台的问题，需要快速定位而不是每次像开会就要拉出30个人一起开会，非常低效的定位，需要工具帮助提升定位的效率，把问题定位到具体的局部，

在做扩容和新产品规划容量规划时候需要工具检验，扩容以后是不是能水平扩容，扩容是不是有极限。压力也上不去，需要工具帮助他进行检验并且如果扣不上告诉它瓶颈在哪里，比如现在在扩ecs，虽然ecs水平扩容，但是水平一比二的扩容没有跟上或者需要一比三的扩容要提高种扩容的比例，都是监控可以帮发现和快速发现的。

开源方案就是会有比如像用户有用apm的开源方案，像pinpoint或者skywalking或者用友商，比如听云或者叫文字慧等等友商竞品，如果用可以推而且阿里云可以推产品，因为month是市面上最便宜的apm产品，是他们的十分之一并且功能因为有阿里云多年的积淀远超于它的，便宜好用，只要用户用阿里云，只愿意相信阿里云的品牌，试用一下，都是比较容易打下来的。

17、再具体一点

（1）线上问题定位

快速定位站点的性能问题，减少MTTR (故障平均修复实际)，减少故障带来的损失。

（2）监控报警

7*24小时应用监控,保证系统的可用性和可观测性，出了问题立刻进行报警。

（3）ARMS的建议沟通对象

客户公司架构师，客户运维部门主管。考虑建设整个运维系统时必然会考虑建设工具，推荐arms。

18、客户案例----人人视频

（1）客户背景:

用户端复杂:移动端/桌面/小程序，不同网络环境和运营商,如何定位问题

（2）解决方案:

同事有坑怎么办?端到端监控,快速定位问题范围。第三方有坑怎么办? CDN资源监控,运营商劫持监控。

不同网络环境和运营商都会出现问题，比如用腾讯云的Cdn，用阿里云的cdn，用很多cdn，网络如果出现不稳定时，需要有快速定位的能力，可以通过arms做资源的监控，通过第三方，用户反馈视频加载不出来，图片加载不出来，可以看是哪个cdn出问题，快速的做定位，保证用户的体验。如果出现问题，是前段问题还是后端问题分清楚，通过arms端到端的监控工具能力。

19、客户案例----广东税务局

客户背景:

混合云:公有云+私有云,公有云监控管理私有云。

解决方案:

（1）快速定责:运维方问题?开发方问题?

（2）作为局方如何衡量线上应用的质量?终端用户体验+可用性监控

非常典型的混合云的用户，有公有云，有私有云，通过公有云管理私有云就，arms在任何环境下都可以用，只要通公有云的客户就可以用，用户很简单，就像移动一样需要快速拎清是运维方的问题，环境的问题，还是开发方向的问题，代码的问题，做快速的问题定位和解决以及在开发方做交割时需要能保证线上的用户体验是可用的，那么就可以通过arms终端用户体验可用现金控，保证交割时验收线上应用的是高质量的。

三、云上运维之美好的未来

arms 可以比较好的定位到 jvm 内存溢出的问题吗?

能够到具体的类包或者线程吗?

演示

arms 有 jvm 监控，监控gc，监控堆内存等等相关的数据。根据历史的经验知道，负gc次数非常多以后，而且老连带持续不下降就存在内存泄漏，因此会自动的每天生成内存账款。

做内层泄漏监控很大的问题是出现内存泄漏以后，要快速重启机器保存不了现场，arms可以自动识别即将出现内存泄漏的风险，把内存账款做下来并且进行推送，就可以重新继续快速恢复，具体的问题可以arms进行排查，具体的排查结果。

可以看到具体的包和类，代码级的诊断。