说实话，当我们开始构建负载均衡系统时，最让我头疼的不是配置本身，而是如何确保这些节点随时都在正常工作。上周就遇到过这种情况：某个后端服务器悄悄宕机了，但负载均衡还在傻傻地把请求往那边送，结果用户看到的全是504超时。这种问题要在用户投诉前自己发现，就必须要有一套完善的健康监控机制。
主动探测 vs 被动监控
我个人比较倾向于结合两种方式来做健康检查。主动探测就是定期向服务发送测试请求，比如在Nginx里配置这样的参数：interval=5s fall=3 rise=2 timeout=3s。但光这样还不够，有时候服务器能响应探测请求，但实际处理业务时又会出问题，这时候就需要结合日志分析这类被动监控手段了。
不能忽视的四个监控维度
从那次事故后，我们建立了一个白板监控系统（现在想想其实用Prometheus就能搞定，但当时太急就自己造轮子了），主要监控四个关键指标：响应时间（超过200ms就标黄）、错误率（高于5%标红）、并发连接数和每秒请求量。有意思的是，我们发现当错误率上升时，往往并发连接数会先有异常波动，这给了我们宝贵的预警时间。
对了，这里有个血泪教训：千万别只监控HTTP状态码！有些第三方服务会返回200但内容是错误信息，我们吃过这个亏，现在解析响应内容也成了健康检查的一环。
熔断机制的黄金30秒
监控到问题后要快速响应。我们设置了一个三级熔断策略：轻微异常（持续30秒）发告警，中等异常（1分钟）自动减少权重，严重异常（2分钟）直接踢出集群。这个黄金30秒的缓冲期很关键，既避免了误判，又能及时止损。上次数据库主从切换时，这个机制帮了大忙。
说个题外话，有时候问题不在后端，而是负载均衡本身。所以我们给Nginx也加上了自监控，通过stub_status模块实时查看活跃连接数、请求队列等指标。毕竟，总不能病人没事医生先倒下了，对吧？
评论