二谈apm规划

最新推荐文章于 2024-10-10 13:49:30 发布

大鸡腿同学

最新推荐文章于 2024-10-10 13:49:30 发布

阅读量96

点赞数

本文链接：https://blog.youkuaiyun.com/weixin_38336658/article/details/132974055

版权

theme: hydrogen

# 前言

1、最近换了部门

感觉是命运的使然，一开始博主是在架构组搞技术，当你出去找工作的时候会偏基础架构类，或者技术类，至于业务类的会出现这么一个情况，那就是业务对口问题，搞搞业务以后也是一条出路。

2、业务对口问题

这是一个无解的东西，比如说你之前没有干过相应的模块，入手会比较慢，或者没有见过成熟的体系、设计，那么在以后开发中会让整个系统健壮性、稳定性都有影响。

我有次跟同事吹水：“我经历过开发主导、产品主导的情况的，开发主导的产研团队，会缺乏业务积极性，就是重心会习惯性往技术上靠，但是技术又不能让业务提效；当然产品主导也有相应的问题，有些产品就是需求型的，业务说什么功能我们就开发什么，有时会出现几个需求互相冲突，有时东一块西一块，没有想清楚我们这个功能模块真正怎么划分比较合理”。

所以我提出我的观念：“不管谁来主导项目，都需要见过成熟的产品，或者有主见的东西，才能胜任”，比如说供应链的模块，你之前有没有见过成熟的供应链，或者说你有没有主动去学习业界成熟的设计，还有有没有进行自己的思考。业务对口，底层也是这个逻辑。

聊到这里，我就有个想法来聊聊apm的规划，方案一定是经过跟成熟系统对比，最终促进我们改进。

# apm 规划

apm作用

我们来想想apm最主要解决什么问题呢？

1、查看日志

场景：定时任务执行情况，我们只知道任务在执行，但是具体执行到哪步需要靠这些日志来观察；异常堆栈，现在有个生产的异常，我们需要看服务的异常堆栈知道哪个代码哪行报错还有异常信息点；节点运行情况，比如说数据库连接不上，jar冲突，版本冲突等等，都需要依靠日志来感知。

2、优化

场景：链路优化还有合理性，链路优化的思考方向是链路的平均请求的时间都最长，还有单次请求时间最长，链路的合理性的方向是计算各个操作次数，比如说多少个mysql请求、redis请求、服务请求，还有总链路的长度、复杂度。

3、异常分析

场景：现在出现一个异常，怎么快速定位问题，或者在业务反馈用户使用上有问题的时候，apm及时发现问题，然后快速的解决。

这块需要依靠系统对异常的分析，然后做问题的定位，最终给出相应的解决策略，里面关键点就是链路分析，解决策略的得出逻辑。

4、总览

场景：应用、接口的健康情况，里面有些接口数、异常数、接口响应时间，我们以这些为依据，来进行应对突发的流量，进行节点扩容，异常情况的感知。

目前我们自研鹰眼需要发力的点

之前已经有一篇介绍apm的系统设计， apm监控得有多少细节啊🤔，它还是有点欠缺的，就是缺乏成熟体系的借鉴，大体后面的优化方案该怎么走，其实是需要依靠我们这篇的规划来的。

着重可以看出目前有两点是薄弱的，一个是异常分析还有定位，另一个是优化上，目前链路还没起到应有的优化的目的。

下面我们讲讲这两方面～

# apm异常分析、定位

整体思路：先定位到哪个应用出问题，然后哪段代码，或者哪个中间件连接有问题，可能慢查询、big key。

首先异常分析，我们日常的话是直接在apm上看哪个应用、哪个接口出现异常，直接定位异常情况，但是这个有个滞后性，就是需要有用户反馈异常，然后开发同学再去排查异常，还需要去花时间定位，比如说没有打印日志，或者有些中间件没有什么记录，排查根本就毫无头绪，所以异常分析是有它的重要性的。

在去哪儿网他们有个apm的异常分析博客，里面提到了就是链路的合并分析，比如说a->b->c,另一个链路是d->b->c,合起来就是a/d->b->c,有这么一个总拓扑图之后，比如说多个接口请求有异常，两个链路都在c节点出现超时、或者异常，那些这时就直接定位到c服务。

这个是异常分析里面，通过链路异常然后结合总的链路合并，来将异常定位到服务，当然也有链路短的，就是网关直接到服务没了，那么异常直接就是到这个服务了。

定位到服务之后呢，需要定位到代码，或者中间件，或者jvm，这是一个细化过程，这时需要一系列的埋点，数据库可以跟普罗米修斯进行监控，然后上报到grafana，然后apm定时拉一个状态，也可以通过服务的log分析，当前数据库连接情况，响应情况，是不是有慢查询；然后中间件是不是连不上，或者连接占满了；

我们通过这些埋点，将异常从大粒度服务，然后细化到中间件、代码层面，这样可以快速的反应，比如说让运维同学加大内存，看看网络问题。

具体实施可能遇到问题

1、异常码怎么定义

我发现现在研发团队对异常码都是各自一套的，只能说我们的framework没有做好，或者说普及上没有做好。然后异常情况怎么定义？timeout、连接中断、连接数不够，这些每个中间件都不一样，那么apm怎么捕获这些数据？这是一个规范或者说定义的问题

2、中间件埋点

上面也有提到，目前对中间件管理是没有到位的，可能我们通过服务的报错来感知，那么具体比如说cpu爆了，内存爆了，开发同学都是没什么感知的，这块也是一个优化的点。

3、分析量比较大的

如果没有时间范围的限制，我们分析的量是比较大的，前面有个提到总拓扑图，如果我们去统计一个月的，可能接口一直在变，我们分析量也会非常大，对于时间维度需要进行进一步的考量的，比如说现在有个异常出来了，我们是对最近10分钟链路做分析还是多少分钟，如果这个时间段里面没有这个接口，那么我们异常的定位就会缺乏数据依据。