推荐的一篇用多种脚本清理iis日志的代码第1/3页_其它

应用场合:主要用与虚拟主机,也可用于个人服务器

产生背景:2005年某月某日,一向运行正常的虚拟主机死机了,让机房值班人员重启数次,都不成,接显示器进系统看,提示:C盘空间不足,半夜还得去机房处理,到机房后先断网,再进系统发现有两个地方有问题,C:\WINDOWS\system32\LogFiles文件有6G,还有一个就是Symantec隔离病毒的地方,到网上找了下,最大可能性是我们的虚拟主机的所有日志都写在这里,并且没人知道写在这里,郁闷,在IIS里看了下,还真是这么回事,日志天天都在长,当时公司订单很多也没人关注这个,当时清理了一下,系统正常,回到公司后把IIS日志改到别的盘了。

解决方案:不过这不是最终解决方法呀,一个虚拟主机几百个站点呢,有的站点一天就能产生几百M的日志文件,还得及时清理。
与是有了两种解决方案:
1.每天清理前60天的日志
2.过段时间清理一下60天前的日志。
不过哪种方法都得采用技术处理,人工去删除 的话除非你很专业,可以查找60天前的日志文件来删除,不过即便你技术很好,这种方法也是很费时的,最好的方法是:使用DOS批处理或脚本来实现,可使用到的脚本主要是vbs与js.

在下边的解决方案里有几种方法大家可以选择适合自己的,他们的总的设计思路是这样的:

IIS日志文件的格式是:ex年月日.log 比如:ex071116.log
IIS日志文件存储位置:默认情况下是在:%windir%\system32\LogFiles ,如果您使用的是专业的IIS管理软件,里面一般会让你设置相应日志目录

IIS日志清理CMD版:跟据当前时间计算出前N天的日期,比如今天是:2007-11-16,前60天的日期就是2007-9-16(程序可以自动识别30天或31天或润月),然后再处理成20070916这样的格式,然后再组合成ex070916.log这样的IIS日志文件格式,这样一来我们就得到的要清理的日志文件名然后,我们再使用del /s /f d:\iislog\ex070916.log 来清除日志所在文件夹目录及子目录下的所有这个文件名的文件了,从而清除志,但这个仅仅是清除一天的日志,所以我们还得把这个批处理加到计划任务里,让它每天定时执行,这样一来,所有的计算机的日志问题我们就可以不用管了。

IIS日志清理VBS版:VBS版理论是没有iis版快,因为他还要借助脚本驱动,而不像cmd版直接使用dos系统的批处理功能快(猜的),VBS毕竟是高级语言,处理日期的能力用一句话就实现了,而CMD版得写半页。IIS日志清理VBS版的实现用VBS遍历IIS日志所在目录下的所有文件,及文件夹,然后取文件名组合成日期型的,然后当前日期-这个日期,看看是不是超过了设定的天数,超过的话delete,这种思路有个好处就是一次可以清除N天前的所有记录,而不是只是一天的,他可以你CMD版日志清理一样,把这个脚本写到计划任务里,天天运行,也可以过一段时间手动运行一次。这个代码明显比IIS日志清理CMD版少了。

IIS日志清理JS版:这个版其实与IIS日志清理VBS版差不了多少,思路都是一样的,只是使用的脚本语言不一样而已,还有就是调用时的两个参数里的每一个参数:目录,这个目录得写成:D:\\iislog,以前都用vbs还当主要脚本,这次主要是要学C#了,听说这两种语言都差不多,正好也练习下,也没花多少时间。

IIS日志清理WSH版:WSH版其实是最简单的,因为他的集成化程度很高,操作过程是这样的:使用vbs或js生成要处理的文件的文件名,然后再使用WScript.Shell执行cmd命令来处理,利用了IIS日志清理CMD版及IIS日志清理VBS版的优点,这个也是一次只能处理一天的日志,当然您也可以把它改成处理多天的日志。正因为WSH集成化程度高,可以执行很多操作,所以黑客们都很喜欢这个,用的最多的也就是WScript.Shell,所以一般安全意识比较高的服务器提供商都会把这个组件给禁用掉,这样一来,这个最好用的功能就变成了最不能使用的,通用性最差的了。

当前1/3页 123下一页阅读全文

时间: 2024-10-29 19:25:11

推荐的一篇用多种脚本清理iis日志的代码第1/3页_其它的相关文章

推荐一篇不错的新手asp编程的基本法则第1/2页_应用技巧

一.新手常犯的错误 在论坛看到很多帖子代码中都有一个共同的基本错误,字段类型错误. 程序和数据库是紧紧相连的,数据库字段文本型或时间型的都使用单引号 比如下面这段修改语句: conn.execute "update Counts set counts='"&counts&"' where num="&num&" and Atime='"&now()&"'" 等号左边都是字段名,等

跨站式脚本(Cross-SiteScripting)XSS攻击原理分析第1/4页_安全相关

使用过ASP的同学一定见过这样的代码:  Hello, 复制代码 代码如下: <% Response.Write(Request.Querystring("name")) %> 假如我传入的name的值为:  [Ctrl+A 全选 注:如需引入外部Js需刷新才能执行] 这样就可以直接盗取用户的cookie.所以我就可以发送一条链接地址让别人去点: 复制代码 代码如下: http://www.xxx.com/reg.asp?name=<script>x=docum

phalcon-进阶篇1(过滤与清理)

phalcon-进阶篇1(过滤与清理) 本教程基于phalcon2.0.9版本 前言 先在这里感谢各位phalcon技术爱好者,我们提供这样一个优秀的交流平台 最后一次更新已经过去了1个半月,在期间也有很多热心的童鞋询问什么时候会更新,最近应为去录制phalapi的视频还有工作上的事情比较忙所以有些耽搁这里给各位小伙伴道个歉,后面争取每周一篇尽早完结phalcon的视频教程.那么相信学习了入门篇9节的童鞋基本想用phalcon来写一些自己的东西已经没有什么问题了,但是还记得我说的吗?phalco

[WebKit] JavaScriptCore解析--基础篇(三)从脚本代码到JIT编译的代码实现

前面说了一些解析.生成ByteCode直至JIT的基本概念,下面是对照JavaScriptCore源代码来大致了解它的实现. 从JS Script到Byte Code 首先说明Lexer, Parser和ByteCode的生成都是由ProgramExecutable初始化过程完成的.先在JSC的API evaluate()中会创建ProgramExecutable并指定脚本代码.然后传入Interpreter时,再透过CodeCache获取的UnlinkedProgramCodeBlock就是已

IIS日志清理(CMD版,VBS版,JS版,WSH版)_win服务器

应用场合:主要用与虚拟主机,也可用于个人服务器 产生背景:2005 年某月某日,一向运行正常的虚拟主机死机了,让机房值班人员重启数次,都不成,接显示器进系统看,提示:C盘空间不足,半夜还得去机房处理,到机房后先断网,再进系统发现有两个地方有问题,C:\WINDOWS\system32\LogFiles文件有6G,还有一个就是Symantec隔离病毒的地方,到网上找了下,最大可能性是我们的虚拟主机的所有日志都写在这里,并且没人知道写在这里,郁闷,在IIS里看了下,还真是这么回事,日志天天都在长,当

第十九篇 最新的ASP、IIS安全漏洞

当ASP以其灵活.简单.实用.强大的特性迅速风靡全球网站的时候,其本身的一些缺陷.漏洞也正威胁着所有的网站开发者,继上一篇中介绍了一些IIS的系统漏洞及ASP的安全问题后,本期中将针对最新的ASP.IIS安全漏洞进行详细的探讨,请所有的ASP网站开发者密切关注,提高警惕. 本月初微软再次被指责对其出品的WEB服务器软件的安全问题不加重视.在微软的流行产品IIS SEVER4.0中被发现存在一种被称为"非法HTR请求"的缺陷.据微软称,此缺陷在特定情况下会导致任意代码都可以在服务器端运行

ASP教程:第十九篇 最新的ASP、IIS安全漏洞

当ASP以其灵活.简单.实用.强大的特性迅速风靡全球网站的时候,其本身的一些缺陷.漏洞也正威胁着所有的网站开发者,继上一篇中介绍了一些IIS的系统漏洞及ASP的安全问题后,本期中将针对最新的ASP.IIS安全漏洞进行详细的探讨,请所有的ASP网站开发者密切关注,提高警惕. 本月初微软再次被指责对其出品的WEB服务器软件的安全问题不加重视.在微软的流行产品IIS SEVER4.0中被发现存在一种被称为"非法HTR请求"的缺陷.据微软称,此缺陷在特定情况下会导致任意代码都可以在服务器端运行

MySQL 自动清理binlog日志的方法_Mysql

说明: 开启MySQL binlog日志的服务器,如果不设置自动清理日志,默认binlog日志一直保留着,时间一长,服务器磁盘空间被binlog日志占满,导致MySQL数据库出错. 使用下面方法可以安全清理binlog日志 一.没有主从同步的情况下清理日志 mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY)'; #mysql 定时清理5天前的binlog mysql -u root

MS SQL Server数据库清理错误日志的方法

SQL错误日志记录了数据库运行过程的遇到的各种问题及一些重要信息,作为排错需要,我们通常都不会主动去清理这些日志文件,只有每次重启服务器时,SQL会自动删除时间最老的日志文件,并新生成一个日志文件. 通过在服务器上查看数据库的日志文件,发现存在大量的query notification dialog的信息,而且出现的频率非常的高,导致日志文件增大非常快. 通过google了解到这个错误跟service broker的消息机制由关系,可以通过使用跟踪标记:DBCC TraceOn(4133,-1)