log转储的重要性


  今天MEI大师在群里说他维护的Cacti页面打不开,但是查看服务器CPU使用率、内存这些很低没什么压力,网络也是正常的,咨询我怎么解决。我问了他一些基本的系统架构问题,知道就是一台普通的Centos 5,server是Apache+PHP,数据库是MYSQL。最后发现是MYSQL日志的锅,在此整理下思路。

  由于不是什么重要的业务,压力不会在IP连接数,首先检查守护进程是否启动,ps -ef 看过后发现都是正常状态。

  然后 netstat -ntu | grep 80 发现80端口连接也正常。这时候顺手敲了一个df -h ,结果尼玛发现根目录使用率已经达到100%了,然后还有大概300G的LV没用。问了大师才知道这是他在网上下的虚拟机镜像,默认根目录就50G。

  既然如此,参考这里调整根目录空间大小 ,把没用的300G分到根目录,完事之后果然能访问web应用了。

  然并卵,以为这就解决问题就图样了,之后观察到根目录使用率以肉眼可见速度增长。此时我已经意识到应该是Cacti本身出了问题在报错,检查Cacti的日志,报错大概意思是数据库表的结构错误,需要修复。接着查看MYSQL的日志文件mysqld.log,已经达到20G左右大小,基本上1秒1行cacti表的报错。

  至此已经明白是MYSQL日志的锅,mysqlcheck之,rm mysqld.log,重启MYSQL进程,故障基本解决。

  最后,   加上mysqld.log的logrotate转储。   加上mysqld.log的logrotate转储。   加上mysqld.log的logrotate转储。