|
|
1.发现问题 监控系统经常发现磁盘报警。严重的会影响到线上的业务
2.分析原因 占磁盘大的主要因素有
1）系统日志 btmp,message,secure
处理方案：
1)系统日志使用lograte进行日志轮转。 日志超过1G轮转，同时按周轮转。只保留5个备份。生成第6个的时候，会自动清除最早的一个备份
2)加防火墙
机器未加防火墙，会导致外部机器频繁扫描主机。系统安全受到危险，同时会生成大量的扫描日志。
通过日志分析系统来看是否有大量的日志扫描行为。
2)nginx日志 访问日志和错误日志
处理方案：
1)访问日志使用lograte进行日志轮转
日志超过1G轮转，同时按天轮转，保留多少个备份视情况而定. 可以通过这个方案来清除历史日志。或者通过写脚本的方式来清除日志。
2)错误日志屏蔽常见的错误日志 例如图标文件访问关闭，搜索网站爬虫访问记录等。
可以通过日志系统收集相关的日志，使错误日志反馈的问题，可以暴露出来。并对相关的错误进行分析修复。
3)mysql日志
处理方案:
1)log-bin日志定期清除,可以采取脚本+cron的方式来处理
4)nohup启动类型的日志
处理方案：
1)创建固定目录，例如/data/log/nohup/来存放nohup.out日志.脚本+cron的方式来处理
5)tomcat日志
处理方案：
1)CATALINA.out 使用cronolog方式按天分割。脚本定期删除
2)其它日志，如果用不到，也可以定期删除.
6)应用打印的日志
处理方案:
业务与逻辑日志分离 按小时或者其它时间轴分隔
重要的数据申请一个nT的磁盘的备份服务器（1-N,看实际需求）。定期备份到相关的目录。本地服务器只留2-3天的数据
7)代码的备份
处理方案:
后续接入运维自动化。代码和配置文件分离。 代码和配置文件使用svn进行版本控制
发布的时候，首先会备份代码至本地的某个目录。保留三个即可.
文件服务器和应用服务器分离，使应用服务器本地不存永久的数据。
8)数据库的备份
处理方案：
数据库定时备份
发布前，备份数据，同时把数据传到新做的备份服务器上.不要在数据库的本地留太多的备份。
同时备份脚本在备份完成以后，都需要打成tar.gz的包，减少对磁盘空间的占用。
9)制定磁盘使用规范
1.系统分区只有20G，任何其它的应用的数据一定要落在数据库/data上,同时/data最好做成标配。最少应该多少。从使用前就规避以后这种问题的发生.
|
|
发表于 2015-10-12 14:31:52
收藏
楼主