月度归档:2016年03月

监控的盲点

【背景】
公司已经有较为完善的监控手段。monitor,通过累积量等一维数据监控自身的情况;智能监控,通过多维数据统计成功率和时耗。当然我们一直认为“一切尽在掌握”。

【问题】
某业务B_T的调用方发现出现超时的情况,排除网络问题,在我们看来只可能是后端服务S_T出问题了。而后查询对应的后端自身服务monitor监控正常,智能监控也变化ok。最后经后端童鞋深入排查,发现是自己server假死了。那么问题来了:
1) 为啥监控没啥变化
假死的server,在LB里面权重被放低了,所以请求量就少了,咋眼看去,monitor视图请求量几乎没变化(减少的很小),因此没有产生告警。而因为假死,所以正常的请求并未被S_T处理,所以智能监控不会被上报,成功率和时耗没有变。
2) 为啥其他业务没太大影响
S_T为很多业务服务,量大的服务,由于成功率都很高,所以通常不会有告警。而量小的业务(或者长尾业务)却很容易受到波动。
3) 为啥没有被LB完全踢掉
这个跟后端S_T的异常姿势有关系,由于是假死,偶尔处理一个请求,LB探测到S_T还alive,又会扔正常的业务数据过来,挂一会儿,又踢掉,周而复始。

【思考】
虽说根本上是后端的server开发者的问题,但是后台开发,监控为王。没有完美的程序,只有不完美的监控。这里暴露出来监控的一些特点,就是不能简单的通过自身的监控上报来判断服务质量,这样就会存在上诉的盲点,监控应该是一个纵深,立体化的过程。将调用方视角的后端服务质量纳入后端服务的监控范围,整合上下游的监控或许才能更加精准的为后端服务保驾护航。

记一次负载均衡不生效的问题

【背景】
公司目前使用一种基于调用方反馈来衡量后端服务的负载均衡组件,姑且称之为LB_T。正常情况下后端服务异常都会让调用方将此问题机器M_T踢掉,因为每一次成功的调用,调用方都会上报一个成功状态和时耗用以对后端可用性和负载做统计。

【问题】
但这一次只看到后端一直返回错误,而调用方却仍然再往这台机器发包。在基础组件上没有找到太多蛛丝马迹,而后进一步排查发现后端过载了仍然会向前端回包。这也就解释得通了,LB_T这种LB方式通常后端有回包就会认为是成功。虽然可以特化处理错误码,但为了整体的通用性,修改框架让后端过载时只上报自身服务质量和记录日志,不向前端回包,问题解决。

【思考】
问题虽然解决,但是引发了我们的思考:代码中使用了LB组件就一定能做到负载均衡,异常时能切换能容灾?答案是否定的:
1. 姿势非常关键。每一次请求都必定要对LB进行一次Update。
2. 上下游配合。一定要清楚的知道后端何为异常,对后端足够的了解,相互配合才能达到效果。