稳定性 监控 业务后期 - 架构师

稳定性 监控 业务后期 - 架构师 雪崩

本文是以前的思考. 最新思考见稳定性 问题定位 系统优化

总体思路:

    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. 数据监控报警.

    依赖拓扑图和上面的理论算法.