得物技术直播服务监控告警归因实践告警直播监控实践服务

背景
伴随得物社区、直播业务快速发展，用户体量也越来越大，服务的稳定性要求日益趋高。那如何快速的对监控告警进行归因、快速的解决问题，我想每个人都有自己的排查定位手段。对经验稍少的同学，可能大家都经历过相同的几个阶段，迷惑告警信息不知从何入手、排查思路容易走入误区、问题原因不知如何筛选。本文着眼于该知识的沉淀，通过互相学习、借鉴团队智慧、总结排查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上

文章图片

甄选可能的原因

	监控指标
外部HTTP	全部接口RT上升	QPS出现流量尖刺
Redis	全部请求RT上升	QPS随流量波动
Mysql	全部请求RT上升	QPS随流量波动
Goroutine	全部Pod都上涨明显
三方依赖	全部请求RT上升

结合上述现象，我们首先能确定影响范围为服务级别。其次发现服务日志中出现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原因	memory	存储层	流量路径	三方依赖	网络故障
接口级别	服务中某接口存在异常状态，其余接口正常			存在		存在
pod级别	某一pod存在异常状态，同服务其余pod正常	存在	存在	存在	存在		存在
服务级别	某一服务所有pod都存在异常状态，同集群中其余服务正常			存在	存在
集群级别	服务所在集群整体受影响,如前段时间测试环境ingress问题				存在		存在
IDC级别	IDC范围内服务整体影响				存在		存在

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
关注得物技术，做最潮技术人！