背景

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