告警故障与Metrics、Tracing、Logging三个维度的逻辑关系
从现有的告警记录中提取故障告警,并找到造成故障的原因。
思路整理
目前我们的告警类型众多,但所有告警都有以下几个特点:
- 告警有层级和优先级之分。有些告警表示底层故障(网络带宽、磁盘IO等),有些表示上层故障(接口慢查等);慢查故障的优先级肯定不如宕机来的严重。
- 不同服务、告警之间存在依赖关系,某次故障告警可能由其他故障告警造成,也可能引发其他告警。所以对于一个告警,需要向下分析其根因,也要向上分析其可能造成的影响。
- 上述依赖关系包括纵向的基础设施依赖关系(顶层应用依赖Redis、MQ,Redis依赖K8S。K8S依赖网络、磁盘等),也包括横向的业务依赖关系(PUB依赖AIM,AIM依赖PMS)。
- 依赖关系可以抽象成一个图,但是图中可能有环,有环的情况是比较危险的,可能造成循环故障,例如上次DCC和UAS互相依赖;所以理想情况下最细粒度的依赖关系应该是个有向无环图(DAG),对于DAG可以用拓扑排序得到横向的业务依赖关系。
- 除了故障会引发故障,事件也可能会引发故障。例如某次服务启动失败可能因为触发了配置变更事件引起。
故障发生与Metrics、Tracing、Logging三个维度的关系
故障其实就是Metrics维度的数据阈值。Metrics维度的数据变化与Tracing和Logging这两个维度有关。Logging可以理解为一系列事件的触发,事件中心的作用可以理解为从海量Logging数据中提取出真正有意义的事件。Tracing则将离散的Logging或事件以一次调用链路的粒度聚合了起来,或者说很多Logging或事件的触发都是在一次Tracing追踪的链路中进行的。
一次故障的发生表现为Metrics维度的数据符合某个PromQL查询,则认为发生了对应的故障。Metrics维度数据的变化可以由其他Metrics引起(例:接口慢查故障可能由网络带宽故障引起),也可能由Tracing维度数据引起(例:接口A慢查故障可能因为调用了接口B造成),也可能由Logging维度数据引起(例:配置中心变更事件导致某个服务启动失败或接口异常熔断)。
一般发生故障后,常见的排查步骤首先是去Grafana上去看直接或间接相关的指标曲线(Metrics),然后找到Metrics维度的根因,这一步最方便的操作就是把异常时刻的Metrics值和正常时刻进行对比,找到哪些数值相差比较大的,那么很有可能就是造成故障的原因。找到Metrics的根因后再去找触发这次阈值的操作(Logging & Tracing)。分析Logs的目的就是为了找到最根本的事件,而这个事件往往也是Logs的一部分。在这个过程中可能需要Tracing的数据来进行横向的分析,把不同的Logs聚合起来,根据服务和接口间的依赖找到业务上的根因。
相关资料:
[1]. Beginner's Guide to Observability(8、9两页比较有价值,指明了造成故障的三个方面和主流的Event-Handling技术)
[2]. Monitoring vs. Observability(详细介绍了Logs、Metrics和Traces三者在服务可观察性方面的特点和联系,比较有参考价值,可以细读)
[3]. 饿了么监控体系:从架构的减法中演进而来(监控+观察系统体系结构、组织方式值得参考)