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

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

父文章

我的其他文章:

   技术人人都是监控专家  

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

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

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

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

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

 

问题定义

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

   例如投屏

告警: 投屏的成功/失败监控	--->	定位: 进一步定位快速失败原因
提升成功率 | |		| | v
已有的失败原因统计分析	< --	复盘: 拉平成独立的错误码

埋点

服务端/客户端数据埋点

异常埋点

   在入口层打印埋点, 成功失败都打印, 尽可能多的维度,注意打印业务包里的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定位排查,查找到根因.

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

值班 

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

  核对值班 历史问题重查

     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为零.

    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怎么样.