稳定性之监控,报警,定位偏业务视角,偏数据分析视角,智能定位. 2/5/15 of 安全生产

本文链接：https://blog.csdn.net/fei33423/article/details/80279583

父文章: 安全生产 - 稳定性建设的方法论架构师应该做什么? [有重复,待整理]_个人渣记录仅为自己搜索用的博客-CSDN博客

父文章

我的其他文章:

技术人人都是监控专家

稳定性监控业务后期 - 架构师 - fei33423 - 博客园

智能会议室建设总结_个人渣记录仅为自己搜索用的博客-CSDN博客也同样提现创建业务id的重要性

泛化监控系统_通过埋点和机器学习_个人渣记录仅为自己搜索用的博客-CSDN博客跨用户概念

自动化根因定位_错误码溯源

业务感知系统业务分析定位_个人渣记录仅为自己搜索用的博客-CSDN博客

问题定义

一切侧问题定义开始, 定义明白了,就抽象出来几大要素. id 边界监控的问题定义(值) 维度状态.

例如投屏

告警: 投屏的成功/失败监控

--->

定位: 进一步定位快速失败原因

提升成功率

已有的失败原因统计分析

< --

复盘: 拉平成独立的错误码

埋点

服务端/客户端数据埋点

异常埋点

在入口层打印埋点, 成功失败都打印, 尽可能多的维度,注意打印业务包里的class,method,且过滤掉工具包的class,method. 异常的时候要打印边界的系统名和接口,且和下游边界要保持一致,且要有端码, 这样异常分析对应code的时候下钻的时候可以继续下钻分析.

边界处不打印.

变成云图/鹰眼的模式. 耗时下钻分析. 哪个在哪个前面,统计分析的时候就比较明确,下钻查询也比较明确,要根据端码来筛选下钻.

结构化异常日志, 如何做好error日志结构化,便于日志监控过滤._个人渣记录仅为自己搜索用的博客-CSDN博客

业务埋点

0. 埋点数据

1. 梳理出统计数据

2. 需要有各个维度.

系统定义,接口名称.

维度的层次

不需要把所有维度都打印在一个日志里. 一个流程上,拆分职责单一后,每个系统都需要各自埋点,关注自己的维度和枚举值.

业务视角埋点[一次思维的突破]

将服务端埋点的方法论泛化到业务视角,这个是一次思维方式的突破,迁移能力,抽象能力. 从服务端架构师升华到业务架构师. 业务负责人只会业务流程异常增多, 希望看到业务视角的请求和水位, 例如成功投屏数量降低, 人均1失败以下的视频会议数量降低, 而不是希望收到各个接口告警,很慌,而且不知道什么原因. 接口告警不影响业务的,业务负责人不关心. 任何的监控都是基于流程和价值链的. 对于业务来说,一次业务行为,可能会涉及到几次行为,更甚至多个人的多个行为. 需要分析定义状态, 状态型记录投屏的整个流程,定义业务实体id(业务id)(业务唯一id)(投屏id)(支付上是订单id), 才可以进行核对告警,有时候中间状态也不能告警,因为用户就是不继续点击了. 客户端调用服务端,设备端各几次都是下边界的维度. 告警时各个边界各自为政.

问: 根因分析时所有系统根因分析分开还是所有维度一起? 分开比较好, 各个治理, 这样职责清晰,问责也清晰. 不要太细,6-10种原则.

根因分析

你无法通过监控直接快速报错, 但是可以辅助抽样分析, 根据现有的维度看是平均分布,还是集中分布,进一步到对应的维度上去抽样分析.

投屏为例子,投屏这个业务的生命周期,从发起一次投屏,到投屏结束. 其中结束可以是人主动,也可以是抢占被动结束,也可以离开会议室超时结束,或者关屏. 投屏的超时很特殊,可以细挖的比较多,例如. 投屏码填错,网络隔离,内网不好,内外网都不好. 投屏失败,你可以整理很多维度,例如设备系统版本,设备软件版本,用户操作系统版本,但基本上都没啥用. 最终原因分析success=false, code是"wifi配置错误", 这个错误会在已有的维度上平均分布. 在"wifi配置错误"这个维度上强占比. 一堆报错根因分析. 除非某个操作系统升级,导致投屏失败.

更复杂的是视频会议, 涉及到N个人, 会议的指标不是简单的成功还是失败. 失败数人均1个异常的占比,人均10个异常占比. 异常分析.

埋点总结

三要素:

触发方, 系统, 下边界. 业务埋点触发方视角是人,系统是客户端/h5. 各自出报表.
下边界原因拆分

1.超时 2.参数异常 3.下边界异常

超时进一步分析, 对于所有超时的traceId ,维度 type:客户端上处理时间,网络上时间,接入层上时间,系统时间.接入层下时间,系统时间, 值: cost. 两种展示方法: 一种是各type总时间分布图一种是第一耗时次数, 第二耗时次数.

业务告警 - 高阈值

失败数告警, 并且要告知失败原因. 每次操作都要上报(重复性的操作不用,例如投屏数据报传播). 但投屏后,每次传递信息流可以不用上报,异常了再上报. 结合核对监控不能正确关闭的投屏也是异常投屏.

核对告警

临时状态的告警

定位

1. 自动化根因定位

雪崩场景会失败,例如底层的redis异常,网络异常,会导致哪哪都报警.

业务上根因定位

2. caseByCase定位排查,查找到根因.

换句话说埋点时期的维度可以不包括三方系统.

值班

告警 - 日常值班_个人渣记录仅为自己搜索用的博客-CSDN博客

低阈值告警,一点点解决.可以不全看

核对值班历史问题重查

sql的窗口能力对账概念 - 账证核对，账账核对，账实核对，账表核对_个人渣记录仅为自己搜索用的博客-CSDN博客

有些异常只需要值班,而不需要告警. 例如偶发性异常可重试异常,性能小阈值性异常,不需要快速跟进的异常一天人工处理一次. 告警是大于阈值很多

告警 - 低阈值

技术水位: db水位, 线程池数量

业务水位: 直播系统的在线会议室水位

稳定性问题定位[基于此监控系统] 系统优化[内部调用异常数据流量,基于此系统上的压测瓶颈发现]

万能方案:

从数据分析角度来看稳定性. 数据分析有个下钻的概念. 核心依据就是: 有个指标表.

这个指标表最关键的是: 你不能有中间汇总结果. 关注最细维度是什么?

如果一个指标是个多对多的产物. 例如投屏是: 设备和用户的组合. 一次请求时: 客户端和服务器机器的组合.

举例: 耗时: 一般只看总流程. 所以我们的耗时日志, 已经是总和有的结果. 是下游各个流程的耗时汇总.

所以我们分析时会不停的切换趋势图表. 先看总表再看依赖趋势表.

原始指标: 离散的. 计算指标: 平均,耗时.

如果说我们能整理出一份最细粒度的指标表就可以了. 而不是传统的各种汇聚表.

例如耗时这块: 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为零.