一、问题现象

下午两点，刚刚睡醒，就接到了客户打来的电话，说他们的网站挂（这个用词很不准确，但是感觉到问题的严重性）了，询问是怎么发生的，之前做了什么操作，客户的回答是：什么都没做，突然就不行了！对于这样的回答，我早已习惯，因为要想从客户那里得到有用的咨询，基本上很难，因为客户不是专业人士，所以只能根据客户的描述，一步步去判断问题。

通过客户给出的这个提示，问题判断方向有如下几个方面：

1、网站无法访问了，可能服务down了。也可能服务器宕机了。
2、网站访问很慢，基本打不开，所以客户就认为宕机了，但是此时服务和服务器可能还处于启动状态。
3、客户自身网络问题，或者DNS问题？

带着疑问，开始了故障排查。

二、问题排查

作为一个运维老鸟，我的一贯思路就是眼见为实，既然客户说网站不能访问了，那我还需要自己测试一下，打开浏览器，输入域名，网站久久不能打开，直到超时。看来确实网站打不开了。

2.1、初步排查

接着，开始登录服务器把脉，客户网站的架构是nginx+tomcat，我首先通过ssh登录到nginx服务器上，连接速度还是很快的，登录上去后，先执行下top命令，检查下系统整体运行状态，如下图所示：

这是一个centos7.9的系统，nginx服务器的硬件配置是32Gb内存，2颗8核物理CPU，nginx通过负载均衡将动态、静态请求发送给后端的多个tomcat上，tomcat运行在另外两台独立的服务器上，硬件配置为2颗8核物理CPU，64GB内存。

从图中可以看出，服务器CPU资源有一定负载，但是不高，32GB的内存资源还比较充足，cached了不少内存，这部分都是可以使用的。另外16个nginx进程每个平均占用CPU负载在30%-40%之间。整体来看，系统资源还是比较充足的，初步判断，不是nginx服务器的问题。

接着，继续登录到tomcat所在的服务器，仍然通过top命令查看系统整体资源状态，如下图所示:

tomcat服务器也是一个centos7.9的系统，系统整体负载偏高（最高14），64Gb的物理内存，可用的仅剩下200M左右，虽然cached了48GB左右，另外可以看到有三个java进程，每个进程占用cpu资源都在100%以上，并且一直持续了几个小时，这里有些异常，最后，关注了一下，启动java进程的是apsds这个普通用户。

然后继续查看，发现这三个java进程，其实是启动了三个tomcat实例，每个tomcat实例都是一个独立的服务，接着，再去查看第二个tomcat物理服务器，发现跟现在这个无论是硬件配置、还是软件部署环境，都完全一致，也就是两台tomcat启动了6个tomcat实例，通过前端的nginx做负载均衡整合，对外提供web服务。

2.2、第二次排查

通过简单的一遍服务器状态过滤，发现可能出问题的是tomcat服务器，于是将精力集中在tomcat服务器上，于是，重新登录tomcat机器，查看tomcat访问日志，通过对日志的查看，发现了一些异常，因为有很多不熟悉的静态页面被访问，如下图所示：

图中966.html这个页面感觉有问题，因为客户的网站静态页面是自动生成的，生成的页面后缀是.htm的，而不是html，这是其一，其二，通过查看966.html这个页面的访问次数，吓了一大跳，一天的时间，300多万次访问，这明显不正常，因为客户网站平时的访问量都在10万以内，根本不可能这么高。

接着，继续查看访问日志，发现类似966.html的这种页面访问非常多，每个页面的访问量都很大，于是，就到/htm/966.html对应的网站目录下，一探究竟吧，进入网站根目录下的htm目录，又发现了一些异常，如下图所示：

这个目录是网站生成的静态页面目录，可以看到有基于htm的静态页面，这些页面以gk开头，是客户网站自动生成的正常文件，另外还有很多以html结尾的静态文件，这些文件不清楚是怎么来的，此外，还看到有个1.jsp的文件，这个就更诡异了，在静态页面目录下，不可能放一个jsp文件啊，经过与客户的咨询以及与研发的沟通，确认这些以html结尾的静态文件以及1.jsp文件都不是网站本身生成或使用的，那么重点来了，先来看看这些文件的内容吧。