故障原因印象流.
1. 代码改动的发布 bug
2. 下游依赖 bug .(软件,硬件)
3. 稳定性雪崩
3.1下游慢等性能问题导致的雪崩
3.2 mysql 慢查等索引性能问题导致的雪崩.
4. 本业务机器故障.
5. 大促等流量激增导致的雪崩
6. 机房迁移.
如何避免上述问题? 体感报警,体感监控体系
问题定位2/5/15 稳定性 问题定位[基于此监控系统] 系统优化[内部调用异常数据流量,基于此系统上的压测瓶颈发现]
补充照片上没有的两点.
拆分: 水平拆分,垂直拆分,基础(中台)拆分. 读放大.
各个内部中间件系统最好也改造接上各核心节点监控. 分成各区间段.
数据驱动的稳定性建设基础: 1.入口监控 (dubbo,mq,定时任务 dubbo,内部定时任务) 2.出口监控(mq,dubbo,http,thrift,mysql,redis)
流量大的接口要隔离.
埋点树: 要有ui 自动下一批子节点找出来. 用来确认埋点是否ok.
监控: 1.量够看成功率,上周同比,上上周同比.. 将绝对值转换为率来判断,比如 大于多少算不正常,不正常的比例. 这样就自动化,不用担心. 2. 量不够看连续绝对值. 确定一个阈值,平台最好可配置时间段阈值
耗时这个指标绝对值有异常就要报警,比较重要. 体感角度监控. 从线程池角度监控: 乘积要监控.
梳理: 看绝对值. 成功率低的,耗时高的.
看耗时,一般上线都是低峰期. 耗时要特别关注.
看耗时提高(早高峰崩溃),相比6周同期,相比上周同期
1. 监控. 总量,率,失败数,耗时,总量*耗时, size,错误类型, exception. error日志.
低流量报警: 关注失败率和code率. 如果有些接口失败但用户体感无影响. 要进行改造.先暂时过滤.
流量: 需要一个系统,
整理出: 1. 离线稳定性分析大盘,架构师专注查看. 这样架构师不需手动执行n各sql,然后整理到webExcel中
2. 分配给各同学, web excel
3. 各个同学整理答复, 更新进度.
存储:
1. 持久化存储
2. 内存
自动化大盘,监控.
灰度监控,比较人肉,淹没在全量监控中.
[创新] 可视化web中台. 趋势图, 圆饼图, 漏斗图. 分组(kv),指标. 多key(无key)
[创新] 指标api后端中台. 服务端通过数据采集, 然后通过接口传递给可视化平台. 同比,环比,报表可点击.[ 阿里xflush + 业务自动化]
指标+ 指标上的指标.
链路: 入口到db的读放大
在线
2. 演练
3. 降级
4, 雪崩下问题定位
5. 指标平台. 按维度报警.
秘钥覆盖率, 大组织的,一部分人发了加密消息, 另外50w不能解密,向第三方取秘钥. 挂掉.
针对业务数据我们可以利用历史数据使用Holt-Winters等模型进行业务数据预测.