优质文档iis错误日志word范文模板 10页.docx
《优质文档iis错误日志word范文模板 10页.docx》由会员分享，可在线阅读，更多相关《优质文档iis错误日志word范文模板 10页.docx（9页珍藏版）》请在冰豆网上搜索。
优质文档iis错误日志word范文模板10页
本文部分内容来自网络整理，本司不为其真实性负责，如有异议或侵权请及时联系，本司将立即删除！
==本文为word格式，下载后可方便编辑和修改！
==
iis错误日志
篇一：
利用IIS日志分析网站安全问题
利用IIS日志分析网站安全问题
内容摘要：
随着网站制作技术的普及，网站的安全问题越来越严重，而分析IIS日志是一种比较常用，比较有效的方法，文章由此出发，介绍了如何分析IIS日志，利用日志发现安全问题，进而加强安全防范。
关键字：
日志、安全、措施
IIS提供了一套相当有效的安全管理机制，并且也提供了一套强大的日志文件系统，而IIS日志文件一直都是网站管理人员查找“病源”的有利工具,通过对日志文件的监测,可以找出有疑问的痕迹,得到网站的访问,操作记录,以及系统的问题所在。
1、IIS日志简介
1.1什么是IIS日志
II即为InternetInformationServer，是英特网信息服务的意思，是一个WorldWideWebserver。
而这个WorldWideWebserver的服务一般有三个步骤，第一是服务请求，包含用户端的众多基本信息，如IP地址、浏览器类型、目标URL等。
第二是服务响应，Web服务器接收到请求后，按照用户要求运行相应的功能，并将信息返回给用户。
如果出现错误，将返回错误代码。
第三是追加日志，服务器将对用户访问过程中的相关信息以追加的方式保存到日志文件中。
IIS日志记录了网站服务器接收，处理请求以及运行错误等各种原始信息。
即它可以记录访问者的一举一动，不管访问者是访问网站，还是上传文件，不管是成功还是失败，日志都以进行记录。
1.2IIS日志文件的存放
通过你的网站-->属性-->“网站”-->“启用日志”是否勾选可以看到日志文件是否启用。
IIS6.0日志文件默认位置为%systemroot%\system32\logfiles\w3svc1\，默认每天一个日志。
不要使用默认的目录，更换一个记录日志的路径，如果不换日志的路径，不对日志进行保护，会很容易被入侵者找到并把日志中的痕迹毁掉，因此建议不要使用默认目录，设置日志文件的访问友限，只允许管理员SYSTEM为完全控制的权限。
由于日志是不断增加长的，它会撑满整个硬盘分区，因此要做好日志管理工
作。
定期定日期导出或整理备份。
1.3日志文件的名称格式
的指标，可以帮助你定位每5~10分钟出现一次是否是上述原因导致。
另外，不要无理由地打开回收工作进程和使用工作进程池。
一般理由通常是有不明原因的内存泄露、线程挂起等回收工作进程相关说明（win201X安装iis在ie里键入下面的地址，里面介绍了启用进程回收的时机及重叠回收的概念）
mk:
@MSITStore:
C:
\WINDOWS\Help\iismmc.chm:
:
/htm/ca_recycwrkrprocess.htm错误定义：
503：
“服务不可用”错误是一个非自定义的错误，该错误表示服务器当前无法处理该请求。
原因：
1、管理员可能关闭应用程序池以执行维护。
2、当请求到达时应用程序池队列已满。
3、应用程序池标识没有使用预定义账户：
网络服务，而自己配置了标识，但是配置的这个用户不属于IIS_WPG组4、应用程序池启用了CPU监视，并且设置了CPU利用率超过一定百分比关闭应用程序池，而开发人员写的服务端页面（.asp,.aspx）执行效率不高，会引起CPU的长时间占用，最终达到设置的百分比，从而引起应用程序池关闭5、应用程序池的性能选项卡的请求队列限制所填的数值太小，默认为1000，可修改成一个更大的值，比如说4500.6、web.config的system.web/httpRuntime节点的appRequestQueueLimit属性设置的值太低。
排查思路：
1、先检查
C:
\WINDOWS\system32\LogFiles\HTTPERR\httperr1.log，看里面有没有503错误，503错误是不会
记录到C:
\WINDOWS\system32\LogFiles\W3SVC1下的，如果503那一行有AppShutdown字样，肯能是由于CPU占用率太高导致自动关闭应用程序池。
如果是AppOffline可能是由于应用程序标识出错引起的，如果是Disabled可能是由于管理员手工关闭应用程序池引起的。
根据这些信息然后再采取响应措施。
2、根据原因5和原因6来设置更大的请求队列数目。
3、禁用所有应用程序池回收选项。
4、添加ASP.NET\RequestsCurrent，ASP.NET\RequestsQueued两个计数器，查看IIS的请求数和队列数。
更多内容，可至此查询：
相关链接：
TechNetV播：
HTTP503故障排除（里面提到的可能性不打）
/china/technet/vcast/live/episode.aspx?
newsID=class01_022
\\CXZ\input\503.wmvIIS状态代码（里面提到iis状态码及可能原因，其中包括503）/kb/318380如果AppPoolQueueLength值是否太低"HTTP503服务不可用"错误消息（如果网站访问量比较大也许是这个原因）
/kb/816995/zh-cn/kb/816995/enFIX：
ASP.NET队列请求太多（该问题是1.0的bug，已经有hotfix修复）
/kb/822148/zh-cn/kb/822148/en元素（文中提到如何通过配置文件来设置应用程序请求的最大数目）
/library/chs/default.asp?
url=/library/CHS/cpgeef/html/gngrfhttpruntimesection.asp客户端请求收到“503：
服务不可用”错误（阐述503定义、可能原因及问题排查）/WindowsServer/zh-CHS/Library/IIS6.0入门及进阶webcast（有IIS排错系列）/nayinian/blog/item/回收工作进程相关说明（win201X安装iis在ie里键入下面的地址，里面介绍了启用进程回收的时机及重叠回收的概念）
mk:
@MSITStore:
C:
\WINDOWS\Help\iismmc.chm:
:
/htm/ca_recycwrkrprocess.htm上述内容摘自：
/onlytiancai/archive/201X/06/03/769309.html在IIS6.0中，记录日志的功能已经改为由http.sys实现，http.sys在内核模式下运行。
这一改进加快了日志写入速度，同时避免了多个工作进程争用同一日志文件。
某些特殊的情况下，http.sys会遇到错误，这时它应该但却不能将日志信息写入Web网站的日志，例如，工作进程正在被回收，禁止http.sys处理用户请求，或者用户试图连接到服务器，但请求中只提供了IIS所需信息的一部分。
如果出现这类情况，http.sys将把事件写入一个新的日志文件httperr.log。
在排解故障、优化IIS6.0的过程中，httperr.log日志文件是十分重要的。
默认情况下，httperr.log文件保存在\system32\logfiles目录，但可以修改，修改方法是找到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters注册子键，在它下面添加一个名为ErrorLoggingDir的字符串值，在ErrorLoggingDir中设置保存日志文件的完整路径。
在httperr.log日志文件中可以找到的信息包括：
所有的503（服务不可用）错误，空闲连接超时，解析URL时出现的各种错误，最后10个提交给失败的应用程序池的请求。
IIS6.0还拥有一种称为二进制日志的功能，启用这个功能后，IIS6.0将把Web网站的所有日志信息写入一个二进制格式的日志文件，日志文件的扩展名是.ibl。
要启用二进制日志功能，只要把配置文件的
W3SVCC/CentralBinaryLoggingEnabled条目设置成ture
（1）即可。
对于ISP来说，这个功能应该非常有用。
ISP的每台机器上可能有1000甚至更多的Web网站，如果每个Web网站每天生成一个日志文件，日志文件的总数很快会达到一个天文数字。
微软最近发布的LogParser2.2工具能够读取二进制日志文件并生成报告，这个工具可以LogParser的最新版本（2.2版）下载。
LogParser2.2
还能够读取前面介绍的httperr.log文件并生成报告。
如果这个直接下载链接不行，就还是从上面这个链接开始下吧。
/downloads/info.aspx?
na=90&p=&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=890cd06b-abf8-4c25-91b2-f8d975cf8c07&u=http%3a%2f%%2fdownload%2ff%2ff%2f1%2fff1819f9-f702-48a5-bbc7-c9656bc74de8%2fLogParser.msi从很久以前开始，IIS就允许指定本地服务器上保存日志文件的目录了。
不过，虽然IIS5.0和IIS4.0的IIS管理器允许在指定日志文件路径的时候输入一个远程服务器的通用命名规范（UNC）的路径，但Web服务器实际上不会把日志保存到远程服务器。
只有IIS6.0才真正支持日志文件路径的UNC路径名。
LogParser确实是一种非常酷的小实用工具，它解决了一些非常棘手的脚本启动问题。
我们仍然不知道分析SQLServer日志有什么用，但是我们知道LogParser的最新版本（2.2版）能做以下事情：
?
搜索事件日志，快速找到并报告所关注的事件。
?
搜索文件系统，快速找到并报告所关注的文件和文件夹。
?
搜索ActiveDirectory，快速找到并报告所关注的对象。
?
搜索各种各样的日志文件。
例如，LogParser能够搜索使用W3C扩展日志文件格式的日志。
使用此格式的日志包括：
个人防火墙日志；MicrosoftInternetSecurityandAcceleration（ISA）Server日志；WindowsMediaServices日志；Exchange跟踪日志；简单邮件传输协议（SMTP）日志文件。
?
快速而轻松地搜索Internet信息服务（IIS）日志、Netmon捕获文件、注册表等多种文件。
这些功能还占不到它的全部功能的一半呢。
LogParser使用一种真正的SQL查询语言，这意味着您可以执行聚合查询。
想知道您的事件日志中的各种事件ID类型的数量（三十七个事件100、四十三个事件101、十四个事件102）吗？
没问题，LogParser能够胜任这项工作。
当然，它还可以胜任很多很多其他工作。
您可以使用一个SQL命令（例如“ORDERBY”）来以您需要的任何方式对返回数据进行排序，也可以使用“TOP”来仅返回若干最“如何如何”的记录（例如，您的硬盘上的10个最大的文件）。
您可以从命令提示符下运行LogParser2.2，也可以将其作为一个可编写脚本的COM对象
（MSUtil.LogQuery）进行调用。
更多详细的功能示例我就不多说了，我要去安装测试去了，有意的到这个阿sir这里慢慢欣赏吧：
有了Log（即LogParser）就万事大吉了
/totaobao/bl
升级会员 