背景

随同得物社区、直播业务疾速倒退，用户体量也越来越大，服务的稳定性要求日益趋高。那如何疾速的对监控告警进行归因、疾速的解决问题，我想每个人都有本人的排查定位伎俩。对教训稍少的同学，可能大家都经验过雷同的几个阶段，蛊惑告警信息不知从何动手、排查思路容易走入误区、问题起因不知如何筛选。本文着眼于该常识的积淀，通过互相学习、借鉴团队智慧、总结排查case，心愿最终能够让大家受害，疾速定位、及时止损。

一、直播监控告警归因实际

本文不波及到具体的业务问题归因，而是如何将告警信息归因到某一方面。对于业务档次的代码问题，这须要欠缺的日志输入、全链路追踪信息、符合条件的问题上下文等去判断，思路也是相通的。

目前得物社区、直播业务应用go、处于k8s环境，监控指标应用grafana展现，天眼告警平台飞书告诉。目前存在的告警规定有：RT异样、QPS异样、goroutine异样、panic异样、http状态异样、业务异样等。最近直播业务碰到一次某服务RT抖动，尽管扩容解决了相应抖动，但在归因定位过程中也走过一些弯路，上面是对整个排查过程的一个展现：

服务监控体现

告警信息反馈：服务RT异样回升、goroutine回升。通过grafana查看服务指标， 发现该工夫点有呈现流量尖刺，QPS回升显著

查看HTTP、GRPC指标，均匀RT、99线显著回升

Mysql指标中RT回升显著，猜想可能是因为mysql有大批量查问或者慢查问，导致RT稳定，从而导致告警

Reids指标中RT回升显著，猜想是因为redis抖动，导致RT回升，呈现超时而后流量被打到了mysql上

甄选可能的起因

联合上述景象，咱们首先能确定影响范畴为服务级别。其次发现服务日志中呈现redis timeout的谬误日志，调用三方服务呈现超时谬误日志。

第一点思考系统资源是否短缺，通过查看cpu、memory指标，告警工夫点系统资源不造成瓶颈。那么咱们能够排除这二个起因导致的此次服务抖动。

其次服务处于k8s环境中，由多个pod提供服务能力。且每个pod被调度在不同的node上，也就是不同的ecs上。同时该服务处于整体抖动状态，能够排除pod单机故障起因。

该服务整体受到影响，同k8s集群中其余服务失常，这能够排除网络故障的起因。总结下来所有的流量出入接口都受到影响，排除依赖服务故障的起因。那么接下来能思考的就是服务的存储层(mysql、redis等) 存在故障，或者服务流量门路某个节点存在问题。

定位问题

通过阿里云的RDS，查看mysql、redis的性能趋势显示失常，并无慢查问日志，机器资源短缺，网络带宽无异样，同时也不存在高可用切换。那么初步判断，存储层应该是没有问题的。

那么如何确定非存储层的问题呢？如果有应用同一存储层的另一服务，告警时段处于失常，那么就能够排除存储层故障。在直播微服务体系中，有另外一个服务应用雷同的存储层，在告警时段服务处于失常状态，如此就能够确定排除此起因。

那么只剩下流量门路节点故障这一个起因，回顾一下整个链路， 服务应用k8s部署运维, 引入了istio做service mesh, 是不是该组件导致的问题呢？监控面板中也有istio的监控，如下：

从监控中查看如同并没有问题，只是在告警工夫点有稳定。问题排查到这里，发现如同都没问题，那么起因到底是什么呢？回顾一下后面的剖析，咱们发现能确定性的排除其余起因，同时服务扩容后，RT抖动也恢复正常了。

所以还是将眼光转向流量门路节点的问题，寻求运维侧的同学反对，心愿实时查看下istio的状态。这时候，我发现运维侧同学反馈的istio负载和监控面板中不统一，这里也就是团队成员走弯路的中央，因为istio的负载指标显示谬误，所以跳过了该起因。通过多方排查，最终发现监控面板收集数据存在异样，通过修复监控数据展现，最终istio的实在负载如下：

实在的istio的负载，明确的指明了此次告警的起因。最初，经确认，目前sidecar应用的资源为2c1g。服务初期应用的pod配置为1c512m, 随着业务倒退pod数越来越多，所以抉择了降级pod的资源配置为4c2g。并且通过服务拆分，该告警服务流量转发居多，导致istio的cpu负载过高，从而导致此次抖动。因为目前sidecar资源固定2c1g, 所以通过把服务配置降级为1c2g减少pod数量，pod数量与sidecar数量是1:1，从而减少了sidecar的资源池，防止后续呈现此类抖动。

二、影响级别、可能的起因、参考思路

咱们须要疾速定位问题，那么首先要确定影响的范畴级别，以及存在哪些可能的起因。通过直播服务抖动的归因实际，能发现是一系列的筛选过程，最终失去答案。 对于非社区、直播技术栈的业务而言，我想都能总结出一套实用于本身服务的条例。 对于直播服务技术栈，存在的范畴级别，可能的起因如下所示：

• cpu方面：长期流量、代码问题、服务缩容、定时脚本
• 内存方面：长期流量、代码问题、服务缩容, (k8s中须要辨别RSS和cache)

<!---->

• mysql、redis：长期流量、慢查问、大批量查问、资源有余、高可用主动切换、手动切换
• 流量门路节点：南北向流量中ingress导致、东西向流量中istio导致

参考思路：

咱们在收到告警信息时，首先须要判断受影响的范畴，其次思考可能存在的起因，再根据现有条件、现状，针对性的排除某些起因。问题的排查过程就如同一个漏斗，最终漏斗的最下一层就是问题的根因，如下所示：

上面是一些疾速排除起因的case:

• 同一存储层，其余服务失常，能够排除存储层故障
• 服务pod数量大于1,根本能够排除服务的网络故障，因为pod散布在不同的ecs上
• 并非所有的流量出入口都存在故障，那么能够排除流量门路节点问题

三、流量门路、存储层介绍

日常除却代码层面，咱们也应该对服务的整个流量门路也要有所理解，对应用的基础设施架构要成竹在胸，这样在排查问题的时候，能疾速的帮咱们判断关键问题。上面介绍一下社区、直播业务的流量门路，以及基础设施高可用架构。

流量门路

南北向流量

南北向流量门路中，ingress是外围门路，呈现问题会导致整个k8s集群不可用。

东西向流量

东西向流量门路中, Envoy proxy接管所有流量，proxy呈现问题会导致服务pod受影响

存储层

mysql高可用架构

目前社区、直播业务应用的是mysql多可用区部署，在高可用主动切换的过程中，会导致服务抖动。

redis高可用架构

redis目前是通过代理实现集群模式，proxy和redis实例是1:N, 每个redis实例都是主从构造，当主从产生主动高可用切换、手动迁徙、资源变动，也会导致服务抖动。

四、总结

回顾一下整个过程，如同抽丝剥茧，一步步揭开庐山真面目。疾速的对告警归因，不仅要有正确的排查思路，也要求咱们除了代码层面的把握，还要对整个零碎架构有所理解。

文/Tim
关注得物技术，做最潮技术人！