悲催的事情
今天下午2点多（时间发生故障的时间是14:14 ，反馈时间却是：14:25 ）收到运营推广部门同事告知，网站打不开了，这个烦呀，怎么会打不开了，由于以前的系统有问题，都重新写了，切换到新的系统上面了，打不开就直接报错了，报错页面如下
分析过程
找到错误日志
出现错误不可怕，这一点我们必须第一时间明确，千万不要担心，担心解决不了任何问题。 对我们最有帮助的就是各种业务日志。通过查阅日志得出如下的错误，当时出现了大量的错误日志
curl: (56) Recv failure: Connection reset by peer
如下是我们的业务架构图
可以我们S1 通过API 接口 访问 S2 ， 我们的错误日志就是在S1上面发现的，因为我们所有的http请求都是通过一个类发出去的，会进行文件日志存储，大致代码如下。
言归正传，找到错误信息只是第一步，得基于日志进行分析具体问题，而接近问题
分析错误
第一种猜测：认为 S2 API出问题了，然后去S2服务器看请求日志和load 负载都不高，内存也没有问题。那么可以排除。
第二种猜测：Yii2 S1 站点代码出问题了，当第一个人反馈的我还有这种猜测，但是随着其他人反馈我知道，肯定不是代码问题。排除
这个时候我心里其实知道一定是流量"大"导致的，因为当天把老系统10来个域名切换到新的系统了，那么就会导致新的系统访问量增加。这是今天系统唯一变化的地方，在排查错误过程中有个原则就是 本来是好的，现在不好了，那么从好到不好这期间应该有什么东西变化了，这个变化的就是我们要第一优先级考虑的线索。
临时处理方法：问题解决不了，但是我们不能一直有时间去慢慢排查，因为每天的运营推广费用总体都有几十万了，那么我们就做一个动作：将今天切换的域名切回老系统，先让业务恢复。这么操作之后临时恢复了可以访问。
但是这只是为我们争取到了时间，让我们有更多的时间排查错误，那么继续猜测下去。
第三个猜测：既然S2 API 服务没问题,那么问题应该在S1上面，我就在S1服务使用命令 curl 访问了下，报错同样的（如下图），这时候见鬼了，我就跑到另外一台服务器暂时叫S3 使用同样的curl 可以访问。此时就可以完全确定 S1 服务的问题，无论什么问题肯定这台机器出问题了
定位问题
基于第三个猜测的方向，定位问题情况，那么我们就可以在S1上面更加仔细的排查了，我看了机器的各种硬件指标是正常的（CPU LOAD，内存，网卡的流量），如下图一切正常，完全访问没压力（下图中的内存使用率不对，因为没有加上 buffer 的，实际内存还剩余很多）。这个时候陷入了僵局，
的确是很久不做运维一线工作了，敏感度不够，我就找了一个运维朋友问了下，真的是一语惊醒梦中人，我结合今天的动作增加流量 我觉得他的说法是对的，然后我就按照这个思路去验证。
解决问题
基于我运维朋友的指点，我看了S1的文件句柄真的很小，就是1024，我看了当时的请求量比平时多了3倍，所以不够很正常，我就把句柄数设置更大了，很多朋友说 这样只是修改了优化参数，如何验证咧？
验证问题
问题是必然要被解决的，既然有了新系统那么必然是要切换的，不把问题解决就没办法完全切过去。我就让把今天添加的域名一点点的加，看看请求户会不会出现问题，有点压力测试的感觉。直接我们说结果：把所有域名切换到新系统，并还多加了几个域名 发现 S1服务器 屁事都没有，压力完全没有，我就说嘛在我的印象中一台 4核8G 服务器 怎么承受这点压力都受不住了。
总结
在这个过程大家可以看到一个大致的排查错误的一个方式方法 如下图。这里面有一个过程有点反过来的感觉：解决问题->验证问题，大部分思维应该是 验证问题->解决问题 。这里面是因为我们前面临时解决问题了，导致没办法直接验证，而要先把问题解决了在验证
不足之处
报警机制不够完善，导致没有第一时间报警
服务器初始化做的不够完善，导致服务器优化配置出问题
后续基于以上的不足我们这边会完善运维系统，为企业提供高可用服务保驾护航
原文地址：curl: (56) Recv failure: Connection reset by peer 分析解决过程
标签：linux centos curl 推广