背景和现象初创公司架构lanmpweb前端和后端分开服务器业务驱动主要是nginx和apachenginx主要是处理静态文件和反向代理前后端、搜索引擎、缓存、队列等附加的服务都是用docker容器部署。因为比较初级上传文件和采集文件都是直接写在硬盘上涉及到的目录共享就在其中一台服务器存储并且nfs共享。我们暂且分为ECS1apache1、ECS2apache2、ECS3nginx。某天网站业务中断但是没有报错。一直在等待响应默认响应超时是一分钟所以很基础高可用没有起到作用。中断10分钟左右重启服务提示“open too many files”但是lsof统计没几个。因为初级处理不了所以直接重启服务器一段时间后一切恢复正常可是第二天又来一次这种情况。二、第一次出现后的排查思路本来第一次发现这种问题的时候就要追查原因了看了一下zabbix监控图像其中断了十分钟包括网络、内存、CPU、硬盘、IO等监控数据。首先想到的是网络问题结论是zabbix-servert获取不到了zabbix-agent采集的数据估计就是网络不通了。但是这个结论站不住脚因为我本身通过ssh登录服务器并且命令输入无卡顿不至于头文件都传不过来。后来一看阿里云的云监控上面有数据似乎也可以佐证网络这个说法因为云监控是阿里云内部的监控可以内网获取到监控数据。直到看CPU的使用率这项发现有一段时间的CPU使用率100%。并且我重启的时候CPU恢复正常不能说网络一定没问题但系统肯定有问题。也可以解释因为CPU使用已经是100%zabbix-agent和根本不能正常运行所以没有监控数据。因为这个公司全部都是云服务器没有使用IDC所以我们也没有安装smokeping来监控接着我们就不把重心在网络上了。目前掌握的信息就是:在毫无征兆的情况下CPU暴涨到100%重启之前一直保留重启之后恢复原样。匆忙之中又看了一下系统各日志因为太匆忙没有总结没有找到什么有价值的东西。现在有下面几种猜想第一程序的bug或者部署不当触发之后耗尽资源。第二、docker容器的bug。第三、网络攻击。第四、病毒入侵。第五、阿里云方系统不稳定。小总结了一下现在问题还没有找出来。下次还有这个问题的可能所以先尽量防范但是又不能重启一刀切。所以在zabbix上面设置了自动化当检测到ECS1获取不到数据的时候马上操作ECS3标记后端为ECS1的apache为down。保留异常现场。请求停止的时候CPU100%还在三、现场排查1、相应的排查计划想到这些信息需要获取的实际上没有严格按照这样的步骤1用htop和top命令监控CPU、内存使用大的进程。先看看哪个进程消耗资源较多,用户态、内核态、内存、IO……同时sar -b查io的历史定时抽样。2统计tcp连接数看看有没有DDOS攻击。netstat -anp |grep tcp |wc -l 。用iftop-i eth1看看通讯。同时用tail -n 1200 /var/log/messages查看内核日志。3用pstree查看打开进程ps aux|wc-l看看有没有特别多的进程。虽然zabbix监控上说没有但是我们要检查一下看看有没有异常的进程名字。4查看全部容器的资源使用docker stats $(docker ps -a -q)看看能不能从容器上排查。5有了“too many open files”的启发计算打开文件数目lsof|wc -l根据进程看看ll /proc/PID/fd文件描述符有没有可疑的打开文件、文件描述符。6关于用lsof打开文件数找到的线索排序打开文件找出进程号 lsof -n|awk {print $2}|sort|uniq -c|sort -nr|more7关于用lsof打开文件数找到的线索用lsof -p PID查看进程打开的句柄。直接查看打开的文件。8启动容器的时候又总是“open too many files。那就是打开文件数的问题因为CPU的使用率是CPU的使用时间和空闲时间比有可能因为打开文件数阻塞而导致CPU都在等待。针对连接数的问题大不了最后一步试试echo 6553500 /proc/sys/fs/file-max 测试打开文件对CPU的影响。9玩意测出来了消耗CPU的进程可以使用strace最终程序。用户态的函数调用跟踪用「ltrace」所以这里我们应该用「strace」-p PID10从程序里面看到调用系统底层的函数可以跟踪。跟踪操作 strace -T -e * -p PID主要看看代码调用的函数有没有问题。2、现场排查第二天同样时间ECS果然暴涨了CPU。这是时候zabbix的工作如希望进行保留了一台故障的ECS1给我。1用htop看到资源使用最大是搜索引擎下我写的一个判断脚本xunsearch.sh。脚本里面很简单判断索引和搜索服务缺一个就全部重启。就当是我的容器有问题我直接关掉搜索引擎容器。httpd顶上我又关掉apache容器。rabbitmq相关进程又顶上。这时候我没心情周旋了肯定不也是这个原因。sar -b查看的历史io也没有异常。2统计tcp连接几百。先不用着重考虑攻击了。用tail -n 1200 /var/log/messages查看内核日志是TCP TIME WAIT的错误。可以理解为CPU使用100%程序无响应外面的tcp请求超时。这是结果还是没有找到根本原因。接着往下看系统内核日志发现了和“open too many files”呼应的错误“file-max limit 65535 reached”意思是已到达了文件限制瓶颈。这里保持怀疑继续收集其他信息。3查看进程数量数量几百。列出来也看到都是熟悉的进程可以先排除异常进程。4监控容器的资源使用里面很不稳定首先是xunsearch容器使用80%的CPU关掉xunsearch又变成了其他容器使用CPU最高。很大程度上可以排查容器的问题和执行程序的问题。5查看了最大连接数cat /proc/sys/fs/file-max是65535但是用lsof查到的连接数是10000多完全没有达到连接数。6各项参数都正常现在聚焦在打开的文件数这个问题上面。也可以用另外同一种方式查看一下内核统计文件 /proc/sys/fs/file-nr比较一下差异看看能不能找出问题。cat了一下打开文件数是66080果然超了内核日志就以这个为标