APM应用具备的几种能力
来源:NET | 作者:广州泰息特 | 发布时间: 2020-02-26 | 1632 次浏览 | 分享到:

前   言

最近几年APM是个网红词汇,但是大家对APM的认知还有一些误区,人们普遍认为APM是解决应用故障的利器。当业务系统被投诉缓慢或者内存泄露被迫不断重启等问题出现时,运营商就快速找一个APM厂商,要求帮忙快速定位问题,如果问题解决了说明产品有价值,但由于问题已经解决便不再购买,如果没有解决则认为APM没有用更不再购买了!

但是要知道,解决应用生产环境中的各种性能故障是APM的绝招之一,如果只是将APM应用在这个范畴,那真是杀鸡用了牛刀呀!今天我们就和大家聊聊,APM还有哪些价值。

我们认为,APM还有下面四个方面的核心价值:

1.    动态业务系统架构的梳理分析

2.    关键业务的筛选

3.    系统故障快速锁定排查

4.    全量数据多维度智能关联分析

 

1.动态业务系统架构分析

某电力客户的部分业务请求需要加载几分钟才能出来,审批一个列表经常喝完一杯水都还没有完成。经过多次不同环境、不同时段测试发现该状况是一个常态,我们从URL请求架构层出发研究调用系统方法量和访问数据库量进行分析,发现单次URL请求调用数据库达到几百次,频繁调用数据库导致执行效率降低,增加URL请求的处理时间,通过在业务系统增加缓存机制大大提升了业务请求的效率。

APM必须具备系统架构的分析能力,架构分析可从两个维度分析,分别是:业务系统运行状态和各组件之间的数据对比。下面我就给大家说说两个维度应该分析的内容:
   (1)、
 业务系统运行状态。架构合理的业务系统数据异常只是偶发性事件,持续发生数据异常均为架构不合理造成的。

  • 业务请求的缓慢率。缓慢率高一般是由多个业务缓慢引起,多个业务同时发生缓慢只有两种情况,一是网络原因,二就是系统架构不合理。

  • 系统异常的发生次数。系统异常为偶发性事件,若持续发生大量的系统异常,表明系统资源和方法存在不合理的使用。

  • 业务错误的发生次数。业务请求出现大量的业务错误,肯定是URL请求与处理过程中存在问题,是否对所有场景都支持。

  • FGC的发生频率。频繁发生FGC的原因多种多样,通常情况下是因为系统突然产生大量垃圾,导致系统触发FGC无法进行其他任务。

  • 内存及CPU的利用率。内存与CPU是否长期利用率较高或多次发生内存占满与CPU占用的情况。

   (2)、各组件之间的数据对比。

  • 前后与后端的调用量和响应时间的对比。前端调用次数与后端调用次数比例越大表明结构越不合理,前端响应时间与后端响应时间对比分析耗时比例。

  • URL请求与SQL调用的对比。URL请求次数与SQL调用次数的比例,平均每次请求触发多少次SQL调用,架构不合理在数据对比下显露无遗。如下图,1次URL平均有40多次的SQL调用,架构上就不是很合理。


  • 业务系统中业务组的数量。业务请求组有多少,业务请求有没有进行多合一设计或者一分多设计。

  • 业务请求报文与方法。业务请求报文的格式(XML或JSON),主要使用的请求方法格式(POST或GET),这样看到系统的开发周期和安全性隐患等。

 

2.智能锁定关键业务能力

每个应用少则拥有几千个不同的URL,多则拥有上万个URL,每天的请求量都在十万级、百万级、千万级以上,这么多不同的URL和海量URL请求数据,如何从中准确找到用价值的URL并对这些关键的业务请求进行布控即成为关键。

APM必须要拥有对URL智能分组统计的能力,并对自动分布的URL进行任意参数的TOP对比。如:请求次数最多的10个URL、相应时间最长的10个URL、错误率最高的10个URL、失败率最高的10个URL。在找到关键的URL后可以快速标记并进行自定义命名。对海量的URL请求可以做到自动标记和命名,并对重要业务进行自动标记和自定义命名。智能锁定关键交易后可对关键交易进行精准优化和唯一策略的精准告警等。

但是常常技术指标上发现的URL经常是助攻型业务请求,不是真正的核心业务,这时候就需要开发人员、业务人员和工具一起快速确定关键业务。 

3.系统故障快速锁定排查能力

伴随着各系统微服务化的演进,服务数量、机器规模的不断增长,线上环境也变得日益复杂,工程师们每天都会面临着这些苦恼:

1.线上系统出现故障时无法第一时间感知;

2.面对线上系统产生的海量日志,排查故障时一筹莫展;

3.系统内部及系统间的调用链路产生故障时难以定位;

……

线上应用的性能问题和异常错误已经成为开发人员和运维人员最大的挑战,而排查这类问题往往需要几个小时甚至几天的时间,效率低下且严重影响了业务发展。

       高效运维APM必须要具备一项能力:要做到实时告警,针对应用层、服务器层、单业务层、用户层等多层级多维度的告警机制,做到系统故障第一时间感知。在告警的同时要对故障进行记录,标记故障位置,在故障排查时查看发生时的系统资源状态、交易链调用、故障信息、组件状态等做到还原故障现场。

4.全量数据多维度关联分析能力

APM监控到的海量数据如果只是用来故障排查,那就大大降低了数据的价值。如何让APM监控的数据发挥更大价值呢?这个就需要APM拥有全量数据多维度关联分析的能力,包括任一时段任意维度的数据环比分析,不同组件数据间的智能关联分析。如:今天与昨天的数据对比,本周与上周的数据对比,URL请求与数据库调用比例,前端与后端相应时间对比等。

APM只解决故障的时代已经过去

数据在未来企业发展中举足轻重,人们常说“得数据者得天下”。APM一直以来的职责都是依靠不断获取数据来完成,随着APM的不断发展,所获取的数据也越来越多、越来越全面,数据的不断积累使得APM的使命不断丰富。新一代的APM要向应用业务性能管理迈进,强调业务分析能力,帮助企业进行业务梳理,抓住业务变化趋势背后的需求变化,用业务数据、智能分析为企业创新、创收提供支撑。