清理7G日志文件引发翻车

- 2021年5月31日，提前收到了六一礼物，囧！

- 话说闲来无事，在发布测试环境服务的时候，死活
启动不了，问运维，运维小哥检查了一番，说：“你的硬盘满了！” ，“纳尼？” 我看了下日志，确实很大，我对运维说:“你把日志清空吧”。很快，运维清空了日志，问题解决。正确剧本应该到此结束。可我偏要看看生产环境是否也存在同样的情况。因为生产环境打印的日志更多。

- 翻车大剧就此开始

- 我查看了生产环境，发现日志文件：7G，按照硬盘大小也不大，但是该出事，躲都躲不过。我让运维把日志清一下，并发了以下命令：
> cd /data/logs/service/adapter-service \
cat /dev/null >stdout.out
- 运维小哥操作很快，回复:"搞定！"
- 一共3台机器，我原本想让运维小哥一起执行，但多年经验养成的习惯是：一台一台搞，比较稳妥，所以就没有说。事后证明，这样做挺正确的。
- 收到运维小哥的回复，我高兴的去刷日志，看看日志文件大小是不是清空了。可以奇怪的事，日志久久没有清空。等来的却是：服务器报警！
- 磁盘读iops： 816.68次/秒>=300次/秒
- 负载load:    14.94>=8 
- 负载load:    Host.load1（22.99>=20 ）（22.99>=20）
- 内存使用率:  98.18%>=90%
> 磁盘IO,负载,内存,网络 相继轮番报警，持续4个多小时

> 从15:38分开始：服务器报警，

> 截止：17:57 重启服务器，报警消失

后来我担心18点下班后，运维小哥下班，所以让运维小哥重启一下生产机器，重启过后，报警也奇迹般消失了。

> 事发后复盘（猜测）

* java程序写日志文件，
* filebeet 监控并读取日志，
* 删除日志的动作：cat /dev/null > stdout.out . 
> 其中删除命令 和 java写日志的程序存在文件描述符冲突，造成日志始终删除不了，磁盘读iops，内存使用率高应该是filebeet读日志文件造成。

有大神知道其中确切原因及原理嘛？望指教！