0. 埋点数据
1. 梳理出统计数据
2. 从统计维度来定位问题.
3. caseByCase定位排查
我的其他文章:
https://www.cnblogs.com/fei33423/p/7169590.html
稳定性建设的方法论 架构师应该做什么? 偏传统视角. https://blog.csdn.net/fei33423/article/details/79301078
万能方案:
从数据分析角度来看稳定性. 数据分析有个下钻的概念. 核心依据就是: 有个指标表.
这个指标表最关键的是: 你不能有中间汇总结果. 关注最细维度是什么?
如果一个指标是个多对多的产物. 例如 投屏是: 设备和用户的组合. 一次请求时: 客户端和服务器机器的组合.
举例: 耗时: 一般只看总流程. 所以我们的耗时日志, 已经是总和有的结果. 是下游各个流程的耗时汇总.
所以我们分析时会不停的切换 趋势图表. 先看总表再看依赖趋势表.
原始指标: 离散的. 计算指标: 平均,耗时.
如果说我们能整理出一份最细粒度的指标表就可以了. 而不是传统的各种汇聚表.
例如耗时这块: 1. 下游各依赖的耗时最终汇总到return处,打印. 打印n条,每条都有各维度的值. 例如 sql的耗时: 1s, 入口类型是按钮, 入口系统是xxx, 入口api是xxx, 耗时类型是sql,content是 最细粒度是traceId. 上一个层级是入口id. 2.方法二, 类似eagleId的形式
维度是有层级的,
就是思维脑图. 最好的方式是把所有维度都拉平,然后放到一个数据统计表里. 但是这张表的列就会非常多,而且没人能维护.
解决方案,指标(耗时)分解:: 各个层级自己来整理指标表.
例如: 一个系统.
code,耗时,系统,接口,下游系统(下游系统名,支付宝,其他cpu时间-一个系统里可算,鹰眼上无法算. 鹰眼角度无法抽象出维度的概念,只能单traceId看),下游系统接口.
最细粒度是下游系统接口名. 注意 cpu的话,统一为cpu时间.
这样把 变成多列,同时分解后的维度增加了 下游系统名,下游系统接口两个维度.
核心日常建设: 用户体验无影响的error都要解决,不然影响定位监控.
如何配置报警(小流量和波动):
1. 避免波动,耗时的监控简单, 连续2分钟超过600ms.
2. 小流量, 成功率,
2.1 无key为零.
2.2 x分钟内总和>0 ,避免10分钟内都没有数据.
2.3 考虑离散数学值,1次失败,必然会引发重试. 故最小case时 1次失败,1次成功. 这种case不报警,偶发. 故总量至少两次失败的场景. 统计要发现偶然的现象2次失败,其他都成功,又要避免误报.
即 10分钟内总和 >1,且 成功率<50 报警. 10分钟内总和 >2, 成功率 < 2/3 67% . 10分钟内 > 3 , 成功率 <75% 3/4
10分钟内 > 5, 成功率 <80%. 10分钟内 > 10, 成功率 <90%.
>100 成功率<99%
如何得到率(成功率,异常占比率):
如果是状态记录 (成功,失败),可以配置成功率. 如果本身就是统计值,非有线离散值. 可以设定一个函数,比如区间函数. 不在这个区间就不正常. 例如断线率,卡顿率.
0. 埋点数据
1. 梳理出统计数据
2. 从统计维度来定位问题.
3. caseByCase定位排查
排查定位问题,依赖的工具不能少. linux体系结构和性能监控工具集.
4. 定期检查错误列表code,慢sql,慢依赖. [ 排查一次del有感, 慢sql很多,但是找不到根源. 慢sql统计曲线.] 最终还是依赖dba的专业工具定位,扫描总行数确定了优先级. del by orgId .
有些sql不慢,但是中间网络卡顿了.这些排查需要相关的工具平台.
有个慢sqlcase: 刚好流量很大,但是对于的sql操作很少. 但是呢这个流量大的业务量刚好命中了很少的delete 语句, 没有命中索引,引发了一堆慢sql.
原因: 一开始排查错了方向,从流量大角度排查.但没想到是一个异常case导致. 这种最难定位. 也就是所谓的雪崩.
还少这个流量有个指标特别不一样, 都是慢,但是他的行数比较多io高,其他的都是cpu比较高.
流程耗时高的原因到底是cpu高,还是io高. 细化指标很重要. 也就是所有流程都要有类似鹰眼的trace分析,即下钻分析.
下钻分析分两种: 1. 维度下钻 2. (加和维度,平均维度)组合下钻
网络被隔断,难排查,也是这个原因,这个流量的各区间段的耗时你不知道了.没有traceId了. 网络的话通过, 垂直分析来定位. ping怎么样.