从现有的告警记录中提取故障告警,并找到造成故障的原因。

思路整理

目前我们的告警类型众多,但所有告警都有以下几个特点:

  1. 告警有层级和优先级之分。有些告警表示底层故障(网络带宽、磁盘IO等),有些表示上层故障(接口慢查等);慢查故障的优先级肯定不如宕机来的严重。
  2. 不同服务、告警之间存在依赖关系,某次故障告警可能由其他故障告警造成,也可能引发其他告警。所以对于一个告警,需要向下分析其根因,也要向上分析其可能造成的影响。
  3. 上述依赖关系包括纵向的基础设施依赖关系(顶层应用依赖Redis、MQ,Redis依赖K8S。K8S依赖网络、磁盘等),也包括横向的业务依赖关系(PUB依赖AIM,AIM依赖PMS)。
  4. 依赖关系可以抽象成一个图,但是图中可能有环,有环的情况是比较危险的,可能造成循环故障,例如上次DCC和UAS互相依赖;所以理想情况下最细粒度的依赖关系应该是个有向无环图(DAG),对于DAG可以用拓扑排序得到横向的业务依赖关系。
  5. 除了故障会引发故障,事件也可能会引发故障。例如某次服务启动失败可能因为触发了配置变更事件引起。

故障发生与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]. 饿了么监控体系:从架构的减法中演进而来(监控+观察系统体系结构、组织方式值得参考)

案例分析

不同类型的告警排查策略也不同,下面从故障表现、严重程度、出现原因、排查修复方法、可能影响这几个方面分析一些常见的故障。

HystrixException:接口熔断

故障表现:接口无法访问。

严重程度:高

出现原因:依赖的其他服务或接口出现故障,多由依赖服务出问题或网络问题导致。

排查修复方法:先横向分析业务依赖关系(Tracing维度),找到最根源出问题的业务服务,再去根源业务寻找逻辑错误或底层基础设施故障(Metrics维度),并找到造成底层设施故障发生的根本事件(Logging或事件维度)。可以使用接口依赖关系寻找依赖的服务,以及可能影响的其他业务。

可能影响:业务层面横向依赖的其他服务(Tracing)

HttpResponseOver5s:接口超时5S

故障表现:接口响应慢,出现超5S的慢查大概率这个接口已经不能正常工作响应了

严重程度:高

出现原因:本身调用链路过长或依赖的服务接口调用链路过长,或网络基础设施问题导致。

排查修复方法:查看本次调用链路,找出耗时的部分(Tracing);同时关注网络情况(Metrics)(最近有无网络配置变更、带宽情况等)。

可能影响:业务层面横向依赖的其他服务(Tracing)

HttpResponseOver1s:接口超时1S

故障表现:接口响应慢

严重程度:低

出现原因:本身调用链路过长或依赖的服务接口调用链路过长,或网络基础设施问题导致。

排查修复方法:查看本次调用链路,找出耗时的部分(Tracing);同时关注网络情况(Metrics)(最近有无网络配置变更、带宽情况等)。

可能影响:业务层面横向依赖的其他服务(Tracing)

InstanceDown:实例宕机

故障表现:实例不可用

严重程度:高

出现原因:1. 发布服务实例上下线、2. 网络问题导致某个时段没有监控到Metrics、3. pod内资源不足导致pod被驱逐

排查修复方法:查看故障时段是否在进行服务发布(事件),若没有则需要进一步排查原因。在Grafana上查看该服务的pod监控有无断层(Metrics),若无断层查看有没有pod因为资源不足被驱逐(Metrics)

可能影响:该实例部署的服务及其影响的其他服务(Tracing角度)

DiskWriteTime:磁盘写延迟

故障表现:ES、MySQL等数据库读写变慢,相关接口慢查

严重程度:中

出现原因:写入过于频繁,磁盘性能不足

排查修复方法:观察服务实例是否需要升级配置(Metrics、Logging)

可能影响:该实例部署的服务及其影响的其他服务(Tracing角度)

NodeDiskSpaceUsageHigh:磁盘空间使用率过高

故障表现:磁盘空间不足

严重程度:中

出现原因:写入过于频繁,磁盘性能不足

排查修复方法:观察服务实例是否需要升级配置(Metrics、Logging)

可能影响:该实例部署的服务及其影响的其他服务(Tracing角度)

TARGET_DOWN:目标宕机

故障表现:DB等目标不可用

严重程度:高

出现原因:1. 发布服务实例上下线、2. 网络问题导致某个时段没有监控到Metrics、3. pod内资源不足导致pod被驱逐

排查修复方法:查看故障时段是否在进行服务发布(事件),若没有则需要进一步排查原因。在Grafana上查看该服务的pod监控有无断层(Metrics),若无断层查看有没有pod因为资源不足被驱逐(Metrics)

可能影响:该实例部署的服务及其影响的其他服务(Tracing角度)

NETWORK_PING_LOSS_OVER:网络丢包

故障表现:src至dst网络不连通

严重程度:高

出现原因:1. 网络带宽被占满、2. QOS限流导致丢包、3. 网络设置最近被改动

排查修复方法:查看当前src至dst网络带宽占用情况(Metrics),查看最近网络配置是否被改动(Logging/Event)

可能影响:所有需要在目标线路上通信的服务

RocketMq:MQ故障

故障表现:根据日志,不同的报错表现也不一致,常见的有消费积压、消息被删除等

严重程度:高

出现原因:消费者消费能力不足

排查修复方法:查看依赖的消费者,排查消费者消费是否正常(Tracing、Metrics)

CPUUsageOver:CPU使用率过高

故障表现:CPU使用率过高

严重程度:高

出现原因:较复杂,多见于线程池失控,一般是IOWait或代码逻辑有问题

排查修复方法:查看线程池占用情况(Metrics)

NETWORK_IN_USAGE || NETWORK_OUT_USAGE:网络带宽占用过高

故障表现:网络带宽占用过高

严重程度:高

出现原因:可能在进行数据同步等

排查修复方法:关注定时任务(Event),使用一定QOS限流策略等

MQ_CONSUME_FAILURE:MQ消费失败

故障表现:MQ消费失败

严重程度:中

出现原因:MQ消费者逻辑有问题

排查修复方法:关注MQ消费者逻辑(Tracing),注意有没有抛异常

MemoryUsageOver:内存使用率过高

故障表现:内存使用率过高

严重程度:高

出现原因:内存泄漏等原因

排查修复方法:关注SBA和Grafana上的内存指标(Metrics)

TOMCAT_THREAD_BUSY:Tomcat线程繁忙比例过高

故障表现:Tomcat工作线程过多

严重程度:高

出现原因:线程被阻塞等原因

排查修复方法:关注代码逻辑和其他指标造成的阻塞,例如网络和IO等(Metrics)

标签: none

添加新评论