一、架构

image.png

两个haproxy 通过keepalived 做高可用，用户请求通过haproxy 转发到后端由两个rabbitmq 组成的镜像集群。

二、问题描述

第一次故障过程 2018.11.01 21:00

1. 运维侧发现PHP端的php-fpm 监控异常，idle 进程数过少，运维开始排查问题，但未有相关操作

2. .NET 反馈收到rabbitmq 无法连接监控，运维检查监控，并没有发现rabbitmq 有异常

3. 此时PHP反馈eb 系统响应慢甚至无法响应，同时.NET 也有调用eb 系统，所以.NET 系统也受到影响

4. 从PHP侧得到的反馈，可以判断出是由于php-fpm 进程消耗过大导致eb 系统异常，运维此时重启php 服务

5. 重启后eb 恢复，但持续不久后，又开始又idle 进程数过少告警，且.NET 侧依然反馈rabbitmq 无法连接

6. 登陆并检查rabbitmq 服务无异常

7. 检查haproxy 日志，发现依然有正常请求日志进来，但haproxy 状态页无法访问，问题暂时定位于haproxy 异常

8. 重启haproxy 后，状态页可以正常访问，.NET 也反馈能正常连接rabbitmq

9. 由此判断，haproxy 异常导致部分请求异常

但整个过程下来，没有确定haproxy 异常的原因

第二次故障过程 2018.11.05 06:00

0. 由于经过第一次故障，发现PHP侧连接rabbitmq 时并没有释放连接，因此导致php-fpm 进程池耗尽，影响eb 系统，因此PHP侧对rabbitmq 使用进行优化，增加释放连接机制

1. .NET 依旧反馈无法连接rabbitmq，且eb 系统虽能访问但是功能异常（猜测是涉及到rabbitmq 操作的功能受影响），进而.NET 系统无法调用eb

2. 但这次php-fpm 进程数无异常，原因应该是添加了释放机制，在rabbitmq 异常的情况下，没有占用php 进程

3. 访问haproxy 状态页依然无法访问，且在此之前将haproxy 日志等级调为warning，但本次异常依然没有错误日志，系统也无错误日志

4. 本次依旧先只能重启haproxy ，并将haproxy 连接数从8k 修改为16k，再观察

第三次故障过程 2018.11.13 08:00

0. 在前两次故障的背景下，增加了关于haproxy 的监控

1. 同样.NET 反馈有受到rabbitmq 无法连接告警，但eb 暂未发现问题

2. haproxy 状态页可以正常登陆，但其中一个实例没有收到请求，该实例正式.NET 反馈的实例，从状态页看到另一实例是可以正常接收请求

image.png

3. 同样是通过重启haproxy 恢复正常

4. 考虑到状态页正常，且其中一个实例正常，那说明haproxy 应该也是正常的，但就是有一个实例异常，不能接收请求

5. 查看haproxy 配置，每个实例都限制了连接数，由此可以查看连接数情况以及相关监控

6. 从TCP监控可以看到，Established 状态的数量异常，前两次峰值到8k 左右就开始异常，第三次到了16k 原因是调整了haproxy 连接数配置

image.png

7. 而Established的状态是已建立的链接，这基本可以确定是由于程序没有释放链接导致

8. 通过在haproxy 上统计tcp 状态分析

image.png

发现爬虫机器的Established一直涨，这就基本确定了是爬虫的问题了

9. 爬虫修复后目前Established 已恢复正常。