稳定性 监控 业务后期 - 架构师 雪崩
本文是之前的思考. 最新思考见稳定性 问题定位 系统优化
整体思路:
1. 突增原因
底层某一个系统资源紧缺的原因肯定来自于上游业务请求量乘以耗时的增长. ( 如果是耗时,那原因是下游. 如果是流量,原因是上游 可以很方便的排除雪崩异常的报警,避免找不到方向..)
如果都没有,就有可能是内因. 1. 机器原因 2. 有种可能是有几个耗时语句的执行.(整体统计完,以后看一个耗时接口的各个具体耗时数据,介入分析原因)
有了ZipKin统计的各个数据, 就可以全局的分析耗时成员流量,已经各个依赖关系.
找到拓扑图最底层的那个耗时系统进行分析. 1. 请求量有无变,溯源到上游系统类似变化 2.耗时有无变 ,定位到具体某个请求是否耗时占比比较高,导致整体拔高 (瞬间耗时高,挤占连接数, 这个 占比区间要尽量小, 怎么样算异常, 要对应到连接数 比较少 . 业务方自己配置. ) 3. 都无,可能整体耗时都高.内部硬件,网络原因.
学习 phoenix 的网络调优经验
人工排查经验,复盘经验. 找因果
1. 时间点很重要. 因果关系. (回溯)
2. 根据各异常,分析上下游耗时,请求量激增.
3. 业务核心主流前置接口,用户重试可瞬间累积到5-10倍. 加上各个流程的重试策略.雪崩时重试级联.耗时配置= E(下游耗时 * 重试次数) . (累加N个接口每个都耗时) 重试是为了可用性,但和稳定性抗压能力违背.全部默认两次.
重试+降级是比较好的方案.按不同的业务系统降级.对外服务的系统,隔离性建设很重要.
稳定性建设:
外因:
1.做活动 2.催款
最终崩塌:
雪崩. 一个慢 sql,导致所有 sql 耗时增加. 最终导致乘客重试. 导致系统重试 (rpc 重试,mq 重试) 原本保证可用性的都变成了最后一根稻草.
内因:
1. 做好扩容准备
2.做好无法扩容系统的reviw .
2.1 非索引
2.2 索引量查找行数比较大. (对于这些读,完全可以用读库扩容的方式实现) .
2.2.1 自动化将99%慢查读引流到读库. 做到可扩容.
2.3 返回的行数比较大的 sql
2.4 redis 的 hashList等指令.
案例: 28分 mq 耗时 31
2. 常态整体就异常
说明需要扩容了.
1. 数据采集 (省钱和高效的决策依据)
1. 操作层级
2. 网络层级
3. 业务层级
dubbo. 连接池 看连接无用. 要监控活跃线程树. 原生是没有的.
内部线程池. 活跃线程池数量. 最终提现到流量入口上.
各个层级的 dubbo 请求数量. 快速定位 provider 耗尽的原因.
4. 日志层级
error 业务报警, info (不再稳定性层面,大并发,大流量. )
2. 数据曲线展示 . 大盘自己配置 小米监控 不含 groupby 不如 cboard.
3. 数据监控报警.
依赖拓扑图和上面的理论算法.