「这是我参与2022首次更文挑战的第26天，活动详情查看：2022首次更文挑战」。
一、异常情况
最近有一个新的项目需要进行在线上环境的测试，在一顿操作创建完虚拟机，分配好磁盘、内存资源后，创建的数据库已经对应用户；接着就将项目打包丢虚拟机运行；然后启动了“祖传”的Nginx配置脚本，对服务进行了一键配置，并申请了SSL证书；最后将域名解析到CDN服务商。
经过一小段时间的测试，暂时是没出现什么问题，但是突然一次更新后，突然就报nginx的500了。然后我也去尝试请求了一下，发现有一部分接口可以正常使用，另外一部分接口总是报500错误。
二、排查
①检查CDN
由于nginx脚本已经使用好久了，从来没有出现过配置出错导致的问题，所以我优先想到去查看CDN服务是不是出了问题。
之前也出现过由于CDN配置不正确，导致query参数丢失的情况。但几番搜索尝试之后，并没有发现任何问题。
配置该开的都开了，不该开的也没启动，基本可以排除是CDN的锅。
②检查程序
或许是因为程序出现问题导致报错，于是就分别在虚拟机内和宿主机内进行了测试：
首先是本地测试，对127.0.0.1进行对应接口请求，发现没有出现问题，可以排除是服务程序问题。
然后在宿主机对虚拟机模拟IP10.0.0.x同样进行了测试，也没出现问题。
③检查Nginx
请求实现的路径大致为：虚拟机内应用程序->宿主机->Nginx转发->CDN->用户。
此时，另外一个项目也出现了问题，而且问题也很古怪，一台机器上请求会返回Nginx的500，另外一台却能正常使用。于是我查看了程序的请求日志，发现Nginx的500错误的请求根本就没有到达程序，此请求未被日志所记录。
但奇怪的是，即使Nginx报了500错误，对应的error.log也没有错误内容，就跟没有发生过一样。
那肯定是Nginx的锅了，但是一段时间可以，然后就不行了，也不像是配置错误的问题，且错误发现在不只一个项目中，应该是宿主机环境出问题了。
④检查系统环境
Ⅰ检查内存
首先想到的就是内存占用，使用free -m查看内存占用：
这还剩挺多的，不至于出错吧。
Ⅱ检查磁盘
接着想到可能是磁盘空间不够了，于是使用df -H进行查询：
终于找到原因了，是日志所在的分区装满了，所以Nginx没有错误日志是应该写不进去了。然后就发现了原来连每天存储的正常请求日志也没了。
三、问题解决
既然知道了是用于磁盘满了导致的问题，那么清理出磁盘空间就行了。
使用du -sh *在日志Nginx存储的目录下进行查找：
然后就找到了两个远古项目的日志文件已经达到10GB左右了。
删除掉了其中过期的日志，释放出磁盘资源：
然后服务就能正常使用了。
