整体思路:
1. 突增原因
底层某一个系统资源紧缺的原因肯定来自于上游业务请求量乘以耗时的增长. ( 如果是耗时,那原因是下游. 如果是流量,原因是上游 可以很方便的排除雪崩异常的报警,避免找不到方向..)
如果都没有,就有可能是内因. 1. 机器原因 2. 有种可能是有几个耗时语句的执行.(整体统计完,以后看一个耗时接口的各个具体耗时数据,介入分析原因)
有了ZipKin统计的各个数据, 就可以全局的分析耗时成员流量,已经各个依赖关系.
找到拓扑图最底层的那个耗时系统进行分析. 1. 请求量有无变,溯源到上游系统类似变化 2.耗时有无变 ,定位到具体某个请求是否耗时占比比较高,导致整体拔高 (瞬间耗时高,挤占连接数, 这个 占比区间要尽量小, 怎么样算异常, 要对应到连接数 比较少 . 业务方自己配置. ) 3. 都无,可能整体耗时都高.内部硬件,网络原因.
学习 phoenix 的网络调优经验
2. 常态整体就异常
说明需要扩容了.
1. 数据采集 (省钱和高效的决策依据)
1. 操作层级
2. 网络层级
3. 业务层级
dubbo. 连接池 看连接无用. 要监控活跃线程树. 原生是没有的.
内部线程池. 活跃线程池数量. 最终提现到流量入口上.
各个层级的 dubbo 请求数量. 快速定位 provider 耗尽的原因.
4. 日志层级
error 业务报警, info (不再稳定性层面,大并发,大流量. )
2. 数据曲线展示 . 大盘自己配置 小米监控 不含 groupby 不如 cboard.
3. 数据监控报警.
依赖拓扑图和上面的理论算法.
时间： 2024-10-10 13:09:05