网站运维工具使用iis日志分析工具分析iis日志(iis日志的配置)

/fuqiang88/p/5870306.html

我们只能通过各种系统日志来分析网站的运行状况，对于部署在IIS上的网站来说，IIS日志提供了最有价值的信息，我们可以通过它来分析网站的响应情况，来判断网站是否有性能问题，或者存在哪些需要改进的地方

对于一个需要长期维护的网站来说，如何让网站长久稳定运行是件很有意义的事情。有些在开发阶段没有暴露的问题很有可能就在运维阶段出现了，这也是很正常的。还有些时候，我们希望不断地优化网站，让网站更快速的响应用户请求，这些事情都发生在开发之后的运维阶段。

与开发阶段不同的，运维阶段不可能让你去调试程序，发现各类问题，我们只能通过各种系统日志来分析网站的运行状况，对于部署在IIS上的网站来说，IIS日志提供了最有价值的信息，我们可以通过它来分析网站的响应情况，来判断网站是否有性能问题，或者存在哪些需要改进的地方。

IIS日志包含了哪些信息

我前面说到【IIS日志提供了最有价值的信息】，这些信息有哪些呢？看看这个截图吧：

这里面记录了：

1. 请求发生在什么时刻，

2. 哪个客户端IP访问了服务端IP的哪个端口，

3. 客户端工具是什么类型，什么版本，

4. 请求的URL以及查询字符串参数是什么，

5. 请求的方式是GET还是POST，

6. 请求的处理结果是什么样的：HTTP状态码，以及操作系统底层的状态码，

7. 请求过程中，客户端上传了多少数据，服务端发送了多少数据，

8. 请求总共占用服务器多长时间、等等。

这些信息在分析时有什么用途，我后面再说。先对它有个印象就可以了。

IIS日志的配置

默认情况下，IIS会产生日志文件，不过，还是有些参数值得我们关注。IIS的设置界面如下（本文以 IIS 8 的界面为例）。

在IIS管理器中，选择某个网站，双击【日志】图标，请参考下图：

此时（主要部分）界面如下：

在截图中，日志的创建方式是每天产生一个新文件，按日期来生成文件名（这是默认值）。

说明：IIS使用UTC时间，所以我勾选了最下面的复选框，告诉IIS用本地时间来生成文件名。

点击【选择字段】按钮，将出现以下对话框：

注意：【发送的字段数】和【接收的字节数】默认是没有选择的。建议勾选它们。

至于其它字段，你可以根据需要来决定是否要勾选它们。

如何分析IIS日志

如果你按照我前面介绍的方法设置了IIS日志参数，那么IIS在处理请求后（的一段时间之后），会生成IIS日志。

我们可以在【日志界面】的右边区域【操作】中点击【查看日志文件】快速定位到IIS日志的根目录，然后到目录中寻找相应的日志文件（默认会根据应用程序池序号来区分目录）。

比如：我找到了我需要的日志：

这个文件一大堆密密麻麻的字符，现在我该如何分析它呢？

有个叫Log Parser的工具就可以专门解析IIS日志，我们可以用它来查看日志中的信息。

比如我可以运行下面的命令行（说明：为了不影响页面宽度我将命令文本换行了）：

复制代码

代码如下:

"C:\Program Files\Log Parser 2.2\LogParser.exe" -i:IISW3C -o:DATAGRID

"SELECT c-ip,cs-method,s-port,cs-uri-stem,sc-status,sc-win32-status,

sc-bytes,cs-bytes,time-taken FROM u_ex130615.log"

现在就可以以表格形式来阅读IIS日志了：

说明：我不推荐用这种方法来分析IIS日志，原因有二点：

1. 慢：当日志文件稍大一点的时候，用它来分析就比较浪费时间了（尤其是需要多次统计时）。

2. 不方便：它支持的查询语法不够丰富，没有像SQL Server针对数据表查询那样全面。

推荐的IIS日志分析方法

虽然Log Parser支持将解析的IIS日志以表格形式供人阅读，但是有时候我们需要再做一些细致分析时，可能会按不同的方式进行【多次】查询，对于这种需求，如果每次查询都直接运行Log Parser，你会浪费很多时间。幸运的是，Log Parser支持将解析结果以多种格式导出（以下为帮助文档截图）：

在此，我建议选择输出格式为 SQL 。

注意：这里的SQL并不是指SQLSERVER，而是指所有提供ODBC访问接口的数据库。

我可以使用下面的命令将IIS日志导入到SQLSERVER中（说明：为了不影响页面宽度我将命令文本换行了）：

复制代码

代码如下:

"C:\Program Files\Log Parser 2.2\logparser.exe"

"SELECT * FROM 'D:\Temp\u_ex130615.log' to MyMVC_WebLog" -i:IISW3C -o:SQL

-oConnString:"Driver={SQL Server};server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI"

-createtable:ON

导入完成后，我们就可以用熟悉的SQLSERVER来做各种查询和统计分析了，例如下面的查询：

复制代码

代码如下:

SELECT cip,csmethod,sport,csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken

FROM dbo.MyMVC_WebLog

如果如下：

注意：

1. IIS日志在将结果导出到SQLSERVER时，字段名中不符合标识符规范的字符将会删除。

例如：c-ip 会变成 cip， s-port 会变成 sport 。

2. IIS日志中记录的时间是UTC时间，而且把日期和时间分开了，导出到SQLSERVER时，会生成二个字段：

date, time这二个字段看起来很不舒服，对吧？

我也很反感这个结果，下面来说说的二种解决方法：

1. 在SQLSERVER中增加一列，然后把UTC时间换成本地时区的时间，T-SQL脚本如下：

复制代码

代码如下:

alter table MyMVC_WebLog add RequestTime datetime

go

update MyMVC_WebLog set RequestTime=dateadd(hh,8,convert(varchar(10),date,120)

+ ' ' + convert(varchar(13),time,114))

2. 直接在导出IIS日志时，把时间转换过来，此时要修改命令：

复制代码

代码如下:

"C:\Program Files\Log Parser 2.2\logparser.exe"

"SELECT TO_LOCALTIME(TO_TIMESTAMP(ADD(TO_STRING(date, 'yyyy-MM-dd '), TO_STRING(time, 'hh:mm:ss')),

'yyyy-MM-dd hh:mm:ss')) AS RequestTime, * FROM 'D:\Temp\u_ex130615.log' to MyMVC_WebLog2"

-i:IISW3C -o:SQL

-oConnString:"Driver={SQL Server};server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI"

-createtable:ON

再看这三列：

复制代码

代码如下:

select RequestTime, date, time from MyMVC_WebLog2

这样处理后，你就可以直接把date, time这二列删除了（你也可以在导出IIS日志时忽略它们，但要明确指出每个字段名）。

IIS日志中的UTC时间问题就说到这里，但愿每个人都懂了~~~~~~~~~~~

IIS日志中的异常记录

IIS日志中记录了每个请求的信息，包括正常的响应请求和有异常的请求。

这里所说的【异常】与 .net framework 中的异常没有关系。

对于一个程序来说，如果抛出一个未捕获异常，会记录到IIS日志中（500），但我所说的异常不仅限于此。

本文所说的异常可分为四个部分：

1. （）程序抛出的未捕获异常，导致服务器产生500的响应输出。

2. 404之类的请求资源不存在错误。

3. 大于500的服务器错误，例如：502，503

4. 系统错误或网络传输错误。

前三类异常可以用下面的查询获得：

复制代码

代码如下:

select scStatus, count(*) AS count, sum(timetaken * 1.0) /1000.0 AS sum_timetaken_second

from MyMVC_WebLog with(nolock)

group by scStatus

order by 3 desc

IIS日志中有一列：sc-win32-status ，它记录了在处理请求过程中，发生的系统级别错误，例如网络传输错误。

正常情况下，0 表示正常，出现非零值意味着出现了错误。我们可以这样统计这类错误

复制代码

代码如下:

declare @recCount bigint;

select @recCount = count(*) from MyMVC_WebLog with(nolock)

select scWin32Status, count(*) AS count, (count(*) * 100.0 / @recCount) AS [percent]

from MyMVC_WebLog with(nolock)

where scWin32Status > 0

group by scWin32Status

order by 2 desc

下表列出了比较常见的与网络相关的错误及解释：

所有状态码都可以通过下面的命令来获取对应的解释：

D:\Temp>net helpmsg 64指定的网络名不再可用。

关于scwin32status与scStatus，我还想补充说明一下：它们没有关联。

比如请求这个地址：/test.aspx

有可能scStatus=200，但scwin32status=64，此时表示已成功处理请求，但是IIS在发送响应结果时，客户端的连接断开了。

另一种情况是：scStatus=500，但scwin32status=0，此时表示，在处理请求过程中发生了未捕获异常，但异常结果成功发送给客户端。

再谈 scwin32status=64

记得以前看到 scStatus=200，scwin32status=64 这种情况时很不理解，于是搜索了互联网，各种答案都有，有的甚至说与网络爬虫有关。为了验证各种答案，我做了一个试验。我写一个ashx文件，用它来模拟长时间的网络传输，代码如下：

复制代码

代码如下:

public class Test_IIS_time_taken : IHttpHandler {

public void ProcessRequest (HttpContext context) {

context.Response.ContentType = "text/plain";</p>< p> System.Threading.Thread.Sleep(1000 * 2);

context.Response.Write(string.Format("{0}, {1}\r\n", "Start", DateTime.Now));

context.Response.Flush();

System.Threading.Thread.Sleep(1000 * 2);</p>< p> for( int i = 0; i < 20; i++ ) {

context.Response.Write(string.Format("{0}, {1}\r\n", i, DateTime.Now));

context.Response.Flush();

System.Threading.Thread.Sleep(1000 * 1);

}</p>< p> context.Response.Write("End");

}

段代码很简单，我不想做过多的解释，只想说一句：我用Thread.Sleep与Response.Flush这二个方法来模拟一个长时间的持续发送过程。

我们可以在浏览器中看到这样的输出（显示还没有完全结束时我截图了）

我把这个测试做了8次，只有2次是全部显示完成了，其余6次我提前关闭了浏览器窗口。

然后，我们再来看IIS日志的内容：

根据IIS日志并结合我自己的操作可以发现：

1. 当我提前关闭浏览器窗口时，就会看到scStatus=200，scwin32status=64

2. 如果请求内容全部显示完成，我就会看到scStatus=200，scwin32status=0

从这个试验我们还可以发现：timeTaken 包含了网络传输时间。

根据这个试验的结果，你是否想过一个问题：

如果你的网站的IIS日志中出现了大量的scStatus=200，scwin32status=64，而且请求是由用户的浏览器发起的。

这是什么原因造成的呢？

我的【猜想】是：用户在访问这个网站时已经不愿意再等待了，他们把浏览器窗口关掉了。

换句话说：可以从scwin32status=64的统计结果看出网站的响应速度是否能让用户满意。

寻找性能问题

IIS日志中有一列叫：timeTaken，在IIS的界面中显示了它的含义：所有时间。

这个所用时间的定义是：从服务端收到请求的第一个字节开始起，直到把所有响应内容发送出去为止的时间。

微软的网站有对这个字段做过说明：/kb/944884

知道了timeTaken的定义后，我们就可以利用它来分析一些请求的处理时间，即性能分析。

例如，我想查看最慢的20个页面的加载情况，可以这样查询：

select top 20 csuristem,scstatus,scwin32status,scbytes,csbytes,timetakenfrom dbo.MyMVC_WebLog with(nolock)where csUriStem like '/Pages/%'order by timeTaken desc

再或者我想再看看最慢的20个AJAX情况的响应情况，可以这样查询：

复制代码

代码如下:

select top 20 csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken

from dbo.MyMVC_WebLog with(nolock)

where csUriStem like '/Pages/%'

order by timeTaken desc

再或者我想再看看最慢的20个AJAX情况的响应情况，可以这样查询：

复制代码

代码如下:

select top 20 csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken

from dbo.MyMVC_WebLog with(nolock)

where csUriStem like '/ajax/%'

order by timeTaken desc

总之，寻找性能问题的方法就是：在查询选择timeTaken字段，并且用它做降序排序。

注意：scbytes,csbytes 这二个字段也是值得我们关注的：

1. csbytes如果过大，我们就要分析一下到底是不是因为表单包含了过多的无用数据，可否将表单拆分。

csbytes变大还有一种可能：Cookie太大，但它会表现为很多请求的csbytes都偏大，因此容易区分。

2. scbytes如果过大，我们就要检查页面是否没有分页，或者可以考虑用按需加载的方式来实现。

典型的情况是：当大量使用ViewState时，这二个值都会变大。因此我们能通过IIS日志发现ViewState的滥用问题。

还有一种特殊情况是：上传下载文件也会导致这二个数值变大，原因我就不解释了。

scbytes,csbytes，不管是哪个数值很大，都会占用网络传输时间，对于用户来说，就需要更长的等待时间。

一下子说了三个字段，在寻找性能问题时，到底该参考哪个呢？

我认为：应该优先关注timeTaken，因为它的数值直接反映了用户的等待时间（不包括前端渲染时间）。

如果timeTaken过大时，有必要检查scbytes,csbytes是否也过大，

如果后二者也过大，那么优化的方向就是减少数据传输量，否则表示是程序处理占用了大量的时间，应该考虑优化程序代码。

寻找可改进的目标

除了可以从IIS日志中发现性能问题，还可以用它来寻找可改进的目标。

例如：

1. 有没有404错误？

2. 是否存在大量的304请求？

3. 是否存在大量重复请求？

当发现有404响应时，我们应该分析产生404的原因：

1. 是用户输入错误的URL地址吗？

2. 还是开发人员引用不存在的资源文件？

如果是后者，就应该尽快移除无效的引用，因为404响应也是一个页面响应，而且它们也会占用网络传输时间，尤其是这类请求不能缓存，它会一直出现，浪费网络资源。

/os/windows/Win/126035.html

iis日志字段解析

IIS日志字段

日志的主体是一条一条的请求信息，请求信息的格式是由#Fields定义的，每个字段都有空格隔开。

date：表示记录访问日期；

time：访问时间；

s-sitename： 客户端所访问的该站点的Internet服务和实例的号码。

s-ip：服务器ip

cs-method： 表示访问方法，常见的有两种，一是GET，就是平常我们打开一个URL访问的动作，二是POST，提交表单时的动作；

cs-uri-stem： 就是访问哪一个文件；

cs-uri-query： 是指访问地址的附带参数，如asp文件?后面的字符串id=12等等，如果没有参数则用-表示；

s-port： 访问的端口

cs-username：对于通过身份验证的用户，格式是“域\用户名”；对于匿名用户，是一个连字符(-)。

c-ip： 访问服务器的客户端IP地址。（已过滤掉中间各种IP，是真实的客户端IP）

cs(User-Agent)：在客户端使用的浏览器。

-----------------------------------------------------------------------------------------------

sc-status：状态，200表示成功，403表示没有权限，404表示打不到该页面，500表示程序有错；

sc-substatus：跟数据缓存有关

cs–win32-statu： 客户端传送到服务端的字节大小；

通过这几个字段可以判断iis响应的状态是否正常。

-----------------------------------------------------------------------------------------

time-taken: 处理所用的时间 ，单位毫秒

默认包含网络传输的时间，只有当返回内容小鱼2k或者开启tcp缓存时不包含网络传输时间。

详细解释点此

--------------------------------------------------------------------------------------------

附：HTTP状态代码：官方说明

概括：

1**：表示请求收到，继续处理

2**：表示操作成功收到，分析、接受

3**：表示完成此请求必须进一步处理

4**：表示请求包含一个错误语法或不能完成

5**：表示服务器执行一个完全有效请求失败

详细代码说明：

100Continue初始的请求已经接受，客户应当继续发送请求的其余部分

101Switching Protocols服务器将遵从客户的请求转换到另外一种协议

200OK一切正常，对GET和POST请求的应答文档跟在后面。

201Created服务器已经创建了文档，Location头给出了它的URL。

202Accepted已经接受请求，但处理尚未完成。

203Non-Authoritative Information文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝

204No Content没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的

205Reset Content没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容

206Partial Content客户发送了一个带有Range头的GET请求，服务器完成了它

300Multiple Choices客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。

301Moved Permanently客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。

302Found类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。

303See Other类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取

304Not Modified客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可

以继续使用。

305Use Proxy客户请求的文档应该通过Location头所指明的代理服务器提取

307Temporary Redirect和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。

400Bad Request请求出现语法错误。

401Unauthorized客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。

403Forbidden资源不可用。

404Not Found无法找到指定位置的资源

405Method Not Allowed请求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）对指定的资源不适用。

406Not Acceptable指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容

407Proxy Authentication Required类似于401，表示客户必须先经过代理服务器的授权。

408Request Timeout在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。

409Conflict通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。

410Gone所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。

411Length Required服务器不能处理请求，除非客户发送一个Content-Length头。

412Precondition Failed请求头中指定的一些前提条件失败

413Request Entity Too Large目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头

414Request URI Too LongURI太长

416Requested Range Not Satisfiable服务器不能满足客户在请求中指定的Range头

500Internal Server Error服务器遇到了意料不到的情况，不能完成客户的请求

501Not Implemented服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求

502Bad Gateway服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答

503Service Unavailable服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头

504Gateway Timeout由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答

505HTTP Version Not Supported服务器不支持请求中所指明的HTTP版本

------------sc-win32-status 状态说明-------------

成功完成的时候该状态数值为0，其他的状态数值代表的意思如下：

函数不正确系统找不到指定的文件系统找不到指定的路径系统无法打开文件拒绝访问句柄无效存储控制块被损坏存储空间不足，无法处理此命令存储控制块地址无效环境不正确试图加载格式不正确的程序访问码无效数据无效存储空间不足，无法完成此操作系统找不到指定的驱动器无法删除目录系统无法将文件移到不同的驱动器没有更多文件媒体受写入保护系统找不到指定的设备设备未就绪设备不识别此命令数据错误(循环冗余检查)程序发出命令，但命令长度不正确驱动器找不到磁盘上特定区域或磁道无法访问指定的磁盘或软盘驱动器找不到请求的扇区打印机缺纸系统无法写入指定的设备系统无法从指定的设备上读取连到系统上的设备没有发挥作用另一个程序正在使用此文件，进程无法访问另一个程序已锁定文件的一部分，进程无法访问无无用来共享的打开文件过多无已到文件结尾磁盘已满不支持请求无无无无无无无无无无Windows 无法找到网络路径。请确认网络路径正确并且目标计算机不忙或已关闭

dows 仍然无法找到网络路径，请与网络管理员联系由于网络上有重名，没有连接。请到“控制面板”中的“系统”更改计算机名找不到网络路径网络很忙指定的网络资源或设备不再可用已达到网络 BIOS 命令限制网络适配器硬件出错指定的服务器无法运行请求的操作出现了意外的网络错误远程适配器不兼容打印机队列已满服务器上没有储存等待打印的文件的空间已删除等候打印的文件指定的网络名不再可用 详细解析拒绝网络访问网络资源类型不对找不到网络名超出本地计算机网络适配器卡的名称限制超出了网络 BIOS 会话限制远程服务器已暂停，或正在启动过程中已达到计算机的连接数最大值，无法再同此远程计算机连接已暂停指定的打印机或磁盘设备无无无无无无无文件存在无无法创建目录或文件INT 24 上的故障无法取得处理此请求的存储空间本地设备名已在使用中指定的网络密码不正确参数不正确网络上发生写入错误系统无法在此时启动另一个进程

以上是100以内的错误代码代表的含义，如果有其他的win32状态码，请直接在命令行模式下使用“net helpmsg”命令查看。

“net helpmsg”命令格式：

NET HELPMSG

message#

其中message#代表win32状态码。