1. 日志文件的默认存放位置先找到它再说其他很多人在接触IIS排障时第一反应是去事件查看器翻系统日志翻半天才发现事件查看器里只记录了服务级错误真正的HTTP请求明细、客户端IP、访问路径、状态码全在IIS自己的日志文件里。那这份日志到底落在哪个目录答案很固定默认情况下IIS日志文件存放在%SystemDrive%\inetpub\logs\LogFiles下其中%SystemDrive%通常就是C:\。也就是说最常见的路径是C:\inetpub\logs\LogFiles但这个目录下不是直接堆放.log文件而是按站点准确说是按站点ID分子目录典型的目录结构长这样C:\inetpub\logs\LogFiles\W3SVC1 C:\inetpub\logs\LogFiles\W3SVC2 C:\inetpub\logs\LogFiles\W3SVC873984423W3SVC后面的数字是网站的唯一标识符Site ID。你在IIS管理器左侧点“应用程序池”下面那一层的“网站”节点右侧列表里每个站点名称旁边就有一列“ID”那个数字就是W3SVC后面的数字。我第一次查日志时对着W3SVC1看了半天心想这跟我服务器的NetBIOS名有什么关系其实它跟站点名毫无关系纯粹是IIS内部给站点分配的编号。一个站点对应一个文件夹互不干扰这点务必要先确认清楚尤其是服务器上搭建了多个站点的人别拿错日志查了半天排查出一个不存在的错误。1.1 从IIS 6到IIS 10默认路径有没有变过先说结论从IIS 6到如今Windows Server 2019/2022自带的IIS 10默认路径一直没有变过始终是%SystemDrive%\inetpub\logs\LogFiles。变的只有启用方式和字段细节路径这块很稳定。不过要注意两个相对隐蔽的默认子目录C:\Windows\System32\LogFiles\HTTPERR—— 这是HTTP.sys层面的错误日志。凡是请求还没进入IIS工作进程就挂掉的比如连接被重置、协议解析异常、内核缓存命中失败之类的都记在这个目录。普通站点的应用层错误不在这里但如果站点完全打不开且IIS日志里又找不到对应记录就得来这里翻一翻。C:\inetpub\logs\FailedReqLogFiles—— 这是“失败请求跟踪”日志目录。IIS 7以上内置的FREBFailed Request Event Buffering功能默认关闭你需要先开启跟踪规则才会在这个目录下生成.xml格式的日志。日常排查中它的作用非常大我们后文细说。还有一点需要留心如果你用netsh http show servicestate这类命令看到的是HTTP.sys层行为而用IIS管理器打开“日志”功能页看到的日志路径不一定是绝对路径。界面上显示的是相对路径W3SVC1之类它是相对于“日志文件目录”这个全局设置而言的。1.2 日志目录按站点ID划分而不是按主机名有朋友可能不理解为什么IIS非要用W3SVCID这种方式命名目录而不像Apache那样直接按域名建目录原因很简单IIS的网站绑定可以同时挂多个主机名host name同一个站点可能绑定a.example.com和b.example.com一个IP加一个端口也可以绑多个域名。如果按主机名拆目录一个站点的日志就被拆碎了反而难以追踪。按Site ID拆目录是IIS从架构层面确立的规则以服务单元为基础记录日志而不是以域名为基础。先把这个默认路径和目录命名彻底理解透后续无论你怎么改路径、怎么查日志才不会被各种“IIS日志找不到”卡住。2. 快速确认日志路径的三种实用方法管理器、命令行、配置文件默认路径知道了但生产环境里没人保证一定是默认路径。很多时候是上一个运维管理员把日志挪到了D盘或者用脚本按天归档。所以你需要学会在任何一台陌生的Windows服务器上快速确认“当前这个站点到底写到哪个目录去了”。下面三个方法由易到难覆盖有界面和无界面两种场景。2.1 在IIS管理器中确认日志路径及格式设置这是最直观的方法适合有远程桌面或管理控制台权限的场景打开“Internet Information Services (IIS) 管理器”。如果你是在Windows Server桌面版上直接从“服务器管理器”的“工具”菜单进入如果是Server Core或没有图形会话可以用inetmgr命令拉起管理器但需要本机或跳板机上有完整GUI支持。左侧连接树中选中要查看的网站节点注意选的是具体“网站”不是服务器根节点。在中间区域找到“IIS”分组下的“日志”图标双击进入。看“日志文件”部分的“目录”输入框默认显示%SystemDrive%\inetpod\logs\LogFiles但它不是完整的最终路径——最终的完整路径其实是“这里的全局目录 W3SVC站点ID子目录”。有一个细节在这里很容易给新手造成困扰在站点级的“日志”界面里目录输入框默认是灰色的、不可编辑只有把左侧选中到“服务器根节点”这一层时“目录”才可以修改。站点级默认是“继承自服务器”也就是你在服务器根节点设一次所有站点都遵循同一个目录规则子目录按W3SVC ID自动区分。所以如果你想给其中一个站点单独指定日志路径要在站点级的日志设置里勾掉“继承”然后再填自己的路径。日常运维中我给重要站点单独分配日志磁盘时经常用这个办法防止日志把C盘塞满。在同一个界面上还要看两个关键选项“格式”默认W3C这是最完整的文本格式按字段记录请求信息。“计划”默认“每天”也就是每个自然日生成一个新log文件。还有“每小时”“每周”“每月”以及“最大文件大小达到即滚动”等选项。生产环境我建议保持“每天”然后再配合“最大文件大小字节”限定单个文件体积具体数值下文会讲。2.2 无界面场景用命令行快速读取日志目录不巧的是很多Windows服务器是云厂商的默认镜像或者平时只能用PowerShell远程管理串口登录根本没有图形桌面。这种情况别慌我用得最多的就是以下三条命令。查看所有站点的基本信息包括Site IDGet-Website | Format-Table Name, Id, State, PhysicalPath得到每个站点的Id之后结合Get-ItemProperty读取IIS配置中的日志路径。这里需要管理员权限运行PowerShellImport-Module WebAdministration Get-ItemProperty IIS:\Sites\你的站点名 | Select-Object -ExpandProperty logFile输出结果里就能看到directory字段比如C:\inetpub\logs\LogFiles。这个命令会展示该站点的日志目录、格式、周期等属性。如果你安装的是IIS 10PowerShell模块WebAdministration已经内置但注意它是32位和64位各有对应版本建议用64位PowerShellx64去操作。还有一种更底层的方式直接查IIS的配置文件——这种方法不依赖任何管理模块任何情况都可以用。2.3 直接读配置文件最底层的确认方式IIS所有配置最终都会落到这个XML文件里C:\Windows\System32\inetsrv\config\applicationHost.config这个文件的权限很高默认只有Administrators和SYSTEM能读你以管理员身份打开的记事本可以看。搜索关键字logFile你会看到类似下面的内容site name我的站点 id1 serverAutoStarttrue application path/ virtualDirectory path/ physicalPathC:\wwwroot\mysite / /application bindings binding protocolhttp bindingInformation*:80:www.example.com / /bindings logFile directoryD:\IISLogs periodDaily formatW3C / /site请注意这条配置中的directory就是该站点最终生效的完整日志目录写什么就是什么不存在路径拼接问题。如果没有单独在站点级指定directory那么全局配置节点长这样log centralLogFileModeSite/centralLogFileMode siteLogDirectory%SystemDrive%\inetpub\logs\LogFiles/siteLogDirectory /logcentralLogFileMode的值有三种Site每个站点各存各的、CentralW3C集中存到同一目录、CentralBinary集中二进制格式。日常遇到的大多数情况都是前者Site也就是我们前面说到的W3SVC子目录方案。从底层配置确认路径看起来步骤多一点但好处是它能一次性看清全局和站点级的所有设置而且完全不需要图形界面。我远程排查服务器问题时直接在命令行里notepad C:\Windows\System32\inetsrv\config\applicationHost.config就完事比反复点鼠标快得多。3. 日志文件命名规则与字段含义懂得看才能查得快找到目录之后会发现里面躺着大量类似u_ex250117.log的文件。这些文件名是有固定规则的理解了规则你一眼就能判断这是哪个站点、哪一天的日志、记录了什么级别的内容。3.1 文件名里的门道u_ex、u_fr、u_in分别是什么IIS日志文件名的常见格式如下前缀含义示例u_ex普通站点日志W3C格式最常用u_ex250117.logu_fr失败请求跟踪日志FREBu_fr2501171234.xml带时间戳u_in未格式化/原始日志较少见u_in250117.loghttperrHTTP.sys层错误日志httperr250117.log250117的解读规则是两位年份、两位月份、两位日期。比如u_ex250117.log就是2025年1月17日当天生成的站点日志。如果日志计划设置的是“每小时”文件名可能是u_ex25011712.log这种在日期后面多出两位小时数。如果设置的是“最大文件大小”那么达到阈值后会自动新建文件文件名为u_ex250117.log、u_ex250117_1.log、u_ex250117_2.log这样递增编号。一个容易忽略的点这个日期是“日志生成的日期”不是“日志记录的日期”。如果你把计划改为“每周”文件名上的日期是该周期开始的日期如果服务器时区设的不是UTC且你用的是默认写法文件名的日期可能和本地自然日有一丁点偏差。下面字段部分会提到日志内容里的时间戳默认是UTC时间这一点非常重要。3.2 W3C字段逐列拆解时间、IP、状态码都藏在哪用记事本打开u_ex250117.log开头几行是以#开头的头信息关键的是这一行#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken这一行定义了下文所有记录列的字段名。常见的列含义如下date、time请求日期和时间。注意IIS默认记录的time 是UTC时间不是服务器本地时间。中国时区UTC8下日志里的时间比北京时间慢8个小时。比如北京时间下午3点收到的请求日志可能记录的是早上7点。这是排查“为什么日志里这个时间段没有记录”时最容易踩的大坑。s-ip服务器的IP地址。多网卡服务器上可以判断请求进入的是哪张网卡。cs-methodHTTP方法GET、POST、HEAD等。cs-uri-stem请求的路径比如/index.html注意它不包含域名部分。cs-uri-queryURL的查询字符串比如?id123没有查询参数时是-。s-port服务器端口80还是443。cs-username通过身份验证的用户名匿名访问时是-。c-ip客户端IP地址。这是定位攻击来源、筛选重点用户的关键字段。cs(User-Agent)客户端浏览器或爬虫标识。cs(Referer)来源页面URL可用来分析流量来源。sc-statusHTTP状态码200正常404未找到500服务器错误403禁止访问等。sc-substatus子状态码IIS特有的能进一步细化错误比如404.2表示“ISAPI筛选器阻止了请求”。sc-win32-statusWin32状态码。这个值常被忽略但它是排查IIS与Windows底层交互问题的重要线索。比如客户端看到连接被重置日志里sc-win32-status是64就说明网络层有连接被删除的错误。time-taken处理请求耗时单位是毫秒。哪些接口慢一排序就知道。记住这个逻辑你就不需要背每个字段cs-开头表示客户端到服务器的信息sc-开头是服务器返回客户端的信息s-是服务器自身信息c-是客户端自身信息。这套前缀很规则碰到不认识的字段可以快速推理。3.3 日志里出现“100”这个值的网络热词我看到最近有个热词叫“日志文件包含100”其实日常运维里更常见的是状态码100它的全称是100 Continue。HTTP协议里客户端发送大请求体之前会先发一个Expect: 100-continue的请求头服务端返回100表示“可以继续发送数据”。这个状态码是正常协议交互但如果日志里大量的100出现且伴随time-taken偏高往往说明客户端和服务端在“继续发送”这个环节上卡顿了值得用网络抓包进一步定位。顺带一提日志里偶尔会出现sc-status200但sc-win32-status64这种“成功但底层有错”的组合往往被忽略。我处理过一个诡异现象网页能打开但CSS和JS资源偶尔加载不出来查IIS日志全是200最后定位到是服务器网卡驱动与虚拟化平台兼容性问题导致连接被重置但HTTP状态码已经发出。这类问题只看HTTP状态码永远查不出来必须结合Win32状态码分析。4. 排查实录常见IIS日志疑难杂症的完整还原光知道日志在哪、字段怎么看还不够真正实践中最让人头疼的是“日志文件呢”和“日志文件怎么这么大”这两类问题。这一节我把过去真实处理过的问题串起来按排查链条一步步说清楚不是直接给结果而是让你能复现我的判断思路。4.1 问题一站点明明在跑但日志目录是空的现象访问网站一切正常打开C:\inetpub\logs\LogFiles\W3SVC1一看里面只有个u_ex250101.log但今天是17号最新日志却停留在一周前甚至整个文件夹直接不存在。排查链路第一步先确认站点真的启用了日志记录。打开IIS管理器选中服务器根节点双击“日志”看日志文件部分有没有勾选“启用”。有个容易忽略的小坑这里的启用只是“允许”站点级的设置里还有个“启用”开关两者同时开启才会写日志。如果某一级把日志停了自然没有记录。第二步检查磁盘空间。日志写入失败不会弹出任何界面提示但系统日志里会记录错误。打开事件查看器Windows日志 - 应用程序筛选来源为IIS-W3SVC-WP的事件错误ID2274表示“日志文件写入失败”。如果磁盘满了IIS会直接停止写日志但站点的业务请求依然正常处理所以从功能上完全察觉不到。第三步确认进程有没有权限往目录里写。如果日志目录被人手动改到了某个只有Administrators才能写的路径而IIS工作进程w3wp.exe默认是用IIS AppPool\站点名这个虚拟账户运行的它就写不进去。此时事件查看器里同样会有对应报错。解决办法是给该目录赋予IIS AppPool\站点名的“修改”权限。第四步看看是不是W3SVC编号对不上。这类问题最常见的原因是你删除了站点又重建了同名站点站点ID变了日志目录变成了新的W3SVC新ID老ID文件夹里的日志就成了“看起来很久没更新”。想要验证就回到2.2的方法用PowerShell查一下目标站点的实际Id再按W3SVCId去找日志目录。这里有一个实用技巧IIS管理器右侧“操作”面板中的“查看日志文件”按钮点击后会直接打开当前站点实际生效的日志目录——它会自动定位到正确的W3SVC文件夹省去手动查找的麻烦。4.2 问题二日志文件存在但用记事本双击打不开或者显示乱码现象日志文件大小有好几百MB甚至几个GB双击打开卡死或者打开后中文URL乱码再或者打开后显示“无法访问正由另一进程使用”。原因和解决办法打不开的常见原因是文件太大。W3C日志增长快很正常稍微有点流量的站点一天的日志就有几百MB。我不建议用系统自带记事本去开日志文件它加载大文件效率极低。我自己的处理习惯是小文件10MB以内用Notepad或VS Code打开。大文件超过100MB不要直接全量打开用PowerShell或Log Parser按条件筛选后导出见下文第5节。文件被占用的提示通常是你要查看的日志刚好正在被IIS写入。W3C日志虽然默认每一条记录即时写入缓冲区但文件句柄确实被w3wp.exe进程占着。复制一份再打开即可或者用“备用数据流”方式读取但没必要复制文件是最省事的方法。乱码问题IIS日志默认是UTF-8编码还是ANSI取决于applicationHost.config里的siteLogDirectory相关配置。不过更常见的情况是URL里带中文参数IIS记录时把非ASCII字符做了URL编码所以看到%E4%B8%AD%E6%96%87这类串是正常的不是乱码。如果你想在日志中直接看到可读的中文路径可以考虑启用IIS的“字段选择”中的cs-uri-stem时同时把cs-uri-query一起记录并设置日志编码为UTF-8不过这不是必须的实际分析时用解码工具一样能还原。4.3 问题三日志增长太快C盘被塞满这是生产环境中出现频率最高的问题。一个繁忙站点一天产生几个GB日志并不罕见如果服务器C盘默认只有60GB几天就爆了。根因分析日志增长快通常有两大类原因。一是正常高并发流量这种情况下日志体积与PV、带宽正相关没有异常二是异常流量比如被CC攻击、被爬虫疯狂抓取、内部定时任务频繁请求此时日志里同一个IP反复刷某几个URL体积会异常膨胀。处理链路先查看统计在PowerShell里输入以下命令可以看到当天日志文件的尺寸Get-ChildItem C:\inetpub\logs\LogFiles\W3SVC1 | Sort-Object Length -Descending | Select-Object -First 5 Name, Length如果发现单个文件超过200MB基本就是流量异常需要进入第2步。按IP统计请求次数。用PowerShell读取日志注意文件可能很大用.NET的StreamReader逐行读更省内存$log C:\inetpub\logs\LogFiles\W3SVC1\u_ex250117.log Get-Content $log | Where-Object { $_ -notmatch ^# } | ForEach-Object { $fields $_ -split [PSCustomObject]{ IP $fields[8]; Status $fields[13] } } | Group-Object IP | Sort-Object Count -Descending | Select-Object -First 10 Count, Name注意$fields[8]和$fields[13]的下标取决于你日志中#Fields行的字段顺序。不同服务器上如果启用了不同的字段列位置会不一样建议先看#Fields行确认索引。这个脚本只是演示思路字段顺序变了要相应调整。根据统计结果做针对性封禁或限流。IP来源如果是陌生境外地址且请求异常密集大概率是扫描或攻击源在Windows防火墙或云安全组层面封掉即可。长期措施把日志目录迁移到大容量磁盘比如D盘同时启用IIS的日志文件大小限制。在服务器根节点的“日志”设置里把“计划”改为“每天”再把“最大文件大小字节”勾上并设置一个值。我习惯设置104857600100MB这样单个文件超过100MB会自动新建编号文件避免了单个文件无限膨胀导致后续分析困难。日志迁移的具体做法是先在D盘建目录比如D:\IISLogs修改服务器级日志目录指向它然后用robocopy把旧日志搬过去。这一步务必要在IIS管理器里先修改配置再移动文件否则复制大日志文件时可能会遇到正在占用的问题。4.4 问题四站点日志里找不到某些请求现象前端明明发起了请求浏览器F12里也能看到网络请求有响应但对应的IIS日志里就是没有这条记录。这个问题的排查链条经常把新人绕晕实际原因是多方面的请求被HTTP.sys内核缓存直接处理了。IIS有一个“内核缓存”特性静态文件或者配置了“HTTP响应头缓存”的动态请求如果命中缓存响应直接从内核返回不会进入w3wp.exe也就不写W3C日志。这种情况最典型的表现是静态资源图片、JS、CSS在第一次请求后后续相同请求全部不记入日志。这不是故障是IIS的缓存优化策略。启用“失败请求跟踪”的站点FREB日志里会用u_fr开头的文件单独记录失败请求普通的u_ex日志里同样没有。如果你排查某个500错误的请求且已经打开了失败请求跟踪记得去C:\inetpod\logs\FailedReqLogFiles里找xml文件。日志刷新延迟。IIS写日志有缓冲机制高并发下可能延迟几秒到几十秒才落盘你刚发完请求立刻去读文件当然看不到。建议等1-2分钟后再看。URL重写规则把请求转发到了其他站点或外部地址。由URL Rewrite模块发出的内部重定向原始请求可能记录在IIS日志里但重定向后的子请求不一定记在同一份日志中视模块配置而定。遇到“日志缺记录”的问题建议按上面的次序从上往下查大多数情况都能定位到。5. 日志分析的实战操作提取指定时段的错误记录日志在那里躺着怎么把它变成有价值的排障信息才是关键。很多运维朋友还在用记事本打开日志文件然后CtrlF搜索小文件还好大文件完全行不通。这里分享我常用的几个方法从纯手动到半自动挑一个适合自己的。5.1 使用LogParser微软官方的日志分析神器Log Parser 是微软提供的一个命令行工具官方下载地址在微软网站可以搜“Log Parser 2.2”它支持用类似SQL的语法查询IIS日志文件功能极其强大。安装之后在命令行里最基本的查询是LogParser.exe SELECT c-ip, COUNT(*) AS Hits FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log GROUP BY c-ip ORDER BY Hits DESC它能一下子统计出所有日志文件中客户端IP的访问次数。想筛选某个时间段内的500错误LogParser.exe SELECT TO_STRING(TO_TIMESTAMP(date, time), yyyy-MM-dd HH:mm:ss) AS Time, cs-uri-stem, sc-status, sc-win32-status FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex250117.log WHERE sc-status 500注意Log Parser默认把date和time作为两个字段处理要用TO_TIMESTAMP拼接后再格式化输出这是新手最容易卡住的地方。5.2 用PowerShell做轻量分析如果不想额外安装工具PowerShell配合正则表达式也足够应付大部分场景。比如筛选出日志中所有HTTP 500错误行Select-String -Path C:\inetpub\logs\LogFiles\W3SVC1\u_ex250117.log -Pattern 500 | Select-Object -First 20这里用 500 带前后空格是为了避免匹配到1500、5000这种包含数字串的状态码。更严谨的做法是结合#Fields行确认状态码位置后再正则定位但日常快速排查用空格分隔法已经够用。如果需要对命中结果做字段拆分用前面的-split方式处理就行。5.3 日志归档与定期清理的推荐做法最后提一下容易被忽略的运维日常——日志不能只积累不清理。我的建议是日志保留周期一般保留30-90天。合规要求严格的可以更长但要考虑存储成本。使用计划任务定期执行归档把30天前的日志压缩后转移到冷存储目录或备份磁盘。归档压缩的核心命令robocopy C:\inetpub\logs\LogFiles D:\LogArchive /MIR /MOV powershell -Command Get-ChildItem D:\LogArchive -Recurse -Filter *.log | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-30) } | Compress-Archive -DestinationPath D:\LogArchive\archive.zip -Updaterobocopy的/MOV参数是把文件移动过去而不是复制压缩之后剩下的*.log可以用Remove-Item清除。这个流程放到计划任务里每月跑一次日志目录就不会无限膨胀。6. 几个常被忽略的小细节与个人经验写了这么多最后把实践中反复踩过、最有价值的一些细节集中说一下。这些内容在微软文档里写得分散很少有人一次讲全。第一日志时间字段默认是UTC不是本地时间。这一条我再强调一遍因为它坑过很多人。如果你在中国时区日志里的文件时间和内容时间差8小时是正常的。分析“下午高峰期”的日志时记得把本地时间减去8小时再去看记录。如果你希望日志直接按本地时间记录可以在服务器级“日志”设置里把“时间”相关的选项调整但IIS的W3C格式底层到底能不能改时区要看版本IIS 10里我测试过部分版本可以通过修改注册表或配置实现但不建议为了看日志方便去改还是自己脑内补足时差更稳妥避免影响其他依赖UTC时间的服务。第二子状态码比主状态码更有价值。比如403.18表示请求被URL授权规则拒绝404.2表示ISAPI筛选器阻止500.0表示模块处理器错误500.21表示模块不识别。这些子状态码直接指引你往哪个方向排查。查日志时不要只看sc-status一定要同时看sc-substatus。第三IIS日志是写文本不是写数据库。因此单条记录里如果字段值本身包含空格IIS会用引号包起来比如cs(User-Agent)和cs(Referer)字段分析时如果简单按空格-split很容易把这些字段拆乱。我在文本里演示的拆分逻辑在遇到带引号的字段时需要用正则或更严谨的解析方式。如果只是统计IP或状态码影响不大一旦要分析User-Agent就得专门处理引号了。第四W3C日志默认输入缓冲区是4KB。高并发下日志批量写入磁盘如果服务器突然断电或强制重启可能会丢失最后一小段时间秒级的日志。对排障来说这点损失通常可以接受如果是金融、公检法等对日志完整性要求极高的业务场景可以考虑用集中日志方案如Windows内建的Event Tracing或第三方采集做冗余。第五备份IIS日志的常见误区是把整个LogFiles目录直接复制走。文件复制过程中如果IIS还在写入容易复制到不完整的文件。更稳妥的做法是用robocopy先同步一遍等待几秒再同步一次把差异部分补上然后对已经不再变化的日志文件做压缩备份。这个技巧本质是利用 robocopy 的多轮增量同步保证一致性我在日常备份脚本里用得很顺手。第六配合失败请求跟踪FREB日志一起看。当IIS日志显示某个请求返回500但你搞不清楚具体是哪个模块报错时开启失败请求跟踪可以捕获请求经过IIS管线每一步的状态。FREB日志是XML格式里面记录了从进入、认证、模块处理、输出整个周期的详细事件。微软文档中叫“Failed Request Tracing”它在IIS 7以上版本内置需要在服务器功能里开启“跟踪”服务然后为站点添加跟踪规则跟踪规则可以按状态码比如500和耗时比如超过5秒触发。开启后访问一次出错的URL去C:\inetpub\logs\FailedReqLogFiles\W3SVC1目录找到新生成的XML文件里面能看到请求在哪个模块花费了多少毫秒、抛出了什么错误比盲猜高效得多。这项功能就是专门为IIS的“黑盒”状态设计的生产环境建议长期开着只对特定站点、特定URL生效不影响正常流量性能损耗可以忽略。第七日志目录权限不能随便收紧。IIS工作进程需要对该目录有写权限但也不要给到Everyone。最安全的是只赋予IIS AppPool\站点名账户的修改权限和Administrators的完全控制权限。曾经见过有人把整个inetpub目录设为Everyone完全控制结果被上传了WebShell服务器被当跳板。日志文件本身也是重要的安全审计数据权限给得太宽等于把攻击痕迹送给攻击者删除。第八分析日志时先确认站点绑定的域名和实际访问的域名。如果服务器上绑定了多个域名日志里cs-uri-stem只有路径不含域名要结合cs(Host)字段如果你启用了该字段来区分是哪个域名的请求。默认W3C字段里没有cs(Host)如果需要要在日志字段选择里手动勾上。这个字段对分析“同一IP 80端口绑多个站点”的场景特别重要。以上这些点都是我这些年处理Windows服务器IIS问题过程中真正遇到过的每一个背后都对应过一次不小的折腾。日志这东西平时不显山不露水一旦出问题它就是破案的第一现场。把路径记牢、字段看懂、工具用熟再做分析时才算真正有了抓手。如果你手头正好有服务器建议现在就去看看日志目录长什么样趁没有故障的时候把它玩透等出问题时才能做到心里有数。
IIS日志文件位置与排查实战：从默认路径到分析技巧
1. 日志文件的默认存放位置先找到它再说其他很多人在接触IIS排障时第一反应是去事件查看器翻系统日志翻半天才发现事件查看器里只记录了服务级错误真正的HTTP请求明细、客户端IP、访问路径、状态码全在IIS自己的日志文件里。那这份日志到底落在哪个目录答案很固定默认情况下IIS日志文件存放在%SystemDrive%\inetpub\logs\LogFiles下其中%SystemDrive%通常就是C:\。也就是说最常见的路径是C:\inetpub\logs\LogFiles但这个目录下不是直接堆放.log文件而是按站点准确说是按站点ID分子目录典型的目录结构长这样C:\inetpub\logs\LogFiles\W3SVC1 C:\inetpub\logs\LogFiles\W3SVC2 C:\inetpub\logs\LogFiles\W3SVC873984423W3SVC后面的数字是网站的唯一标识符Site ID。你在IIS管理器左侧点“应用程序池”下面那一层的“网站”节点右侧列表里每个站点名称旁边就有一列“ID”那个数字就是W3SVC后面的数字。我第一次查日志时对着W3SVC1看了半天心想这跟我服务器的NetBIOS名有什么关系其实它跟站点名毫无关系纯粹是IIS内部给站点分配的编号。一个站点对应一个文件夹互不干扰这点务必要先确认清楚尤其是服务器上搭建了多个站点的人别拿错日志查了半天排查出一个不存在的错误。1.1 从IIS 6到IIS 10默认路径有没有变过先说结论从IIS 6到如今Windows Server 2019/2022自带的IIS 10默认路径一直没有变过始终是%SystemDrive%\inetpub\logs\LogFiles。变的只有启用方式和字段细节路径这块很稳定。不过要注意两个相对隐蔽的默认子目录C:\Windows\System32\LogFiles\HTTPERR—— 这是HTTP.sys层面的错误日志。凡是请求还没进入IIS工作进程就挂掉的比如连接被重置、协议解析异常、内核缓存命中失败之类的都记在这个目录。普通站点的应用层错误不在这里但如果站点完全打不开且IIS日志里又找不到对应记录就得来这里翻一翻。C:\inetpub\logs\FailedReqLogFiles—— 这是“失败请求跟踪”日志目录。IIS 7以上内置的FREBFailed Request Event Buffering功能默认关闭你需要先开启跟踪规则才会在这个目录下生成.xml格式的日志。日常排查中它的作用非常大我们后文细说。还有一点需要留心如果你用netsh http show servicestate这类命令看到的是HTTP.sys层行为而用IIS管理器打开“日志”功能页看到的日志路径不一定是绝对路径。界面上显示的是相对路径W3SVC1之类它是相对于“日志文件目录”这个全局设置而言的。1.2 日志目录按站点ID划分而不是按主机名有朋友可能不理解为什么IIS非要用W3SVCID这种方式命名目录而不像Apache那样直接按域名建目录原因很简单IIS的网站绑定可以同时挂多个主机名host name同一个站点可能绑定a.example.com和b.example.com一个IP加一个端口也可以绑多个域名。如果按主机名拆目录一个站点的日志就被拆碎了反而难以追踪。按Site ID拆目录是IIS从架构层面确立的规则以服务单元为基础记录日志而不是以域名为基础。先把这个默认路径和目录命名彻底理解透后续无论你怎么改路径、怎么查日志才不会被各种“IIS日志找不到”卡住。2. 快速确认日志路径的三种实用方法管理器、命令行、配置文件默认路径知道了但生产环境里没人保证一定是默认路径。很多时候是上一个运维管理员把日志挪到了D盘或者用脚本按天归档。所以你需要学会在任何一台陌生的Windows服务器上快速确认“当前这个站点到底写到哪个目录去了”。下面三个方法由易到难覆盖有界面和无界面两种场景。2.1 在IIS管理器中确认日志路径及格式设置这是最直观的方法适合有远程桌面或管理控制台权限的场景打开“Internet Information Services (IIS) 管理器”。如果你是在Windows Server桌面版上直接从“服务器管理器”的“工具”菜单进入如果是Server Core或没有图形会话可以用inetmgr命令拉起管理器但需要本机或跳板机上有完整GUI支持。左侧连接树中选中要查看的网站节点注意选的是具体“网站”不是服务器根节点。在中间区域找到“IIS”分组下的“日志”图标双击进入。看“日志文件”部分的“目录”输入框默认显示%SystemDrive%\inetpod\logs\LogFiles但它不是完整的最终路径——最终的完整路径其实是“这里的全局目录 W3SVC站点ID子目录”。有一个细节在这里很容易给新手造成困扰在站点级的“日志”界面里目录输入框默认是灰色的、不可编辑只有把左侧选中到“服务器根节点”这一层时“目录”才可以修改。站点级默认是“继承自服务器”也就是你在服务器根节点设一次所有站点都遵循同一个目录规则子目录按W3SVC ID自动区分。所以如果你想给其中一个站点单独指定日志路径要在站点级的日志设置里勾掉“继承”然后再填自己的路径。日常运维中我给重要站点单独分配日志磁盘时经常用这个办法防止日志把C盘塞满。在同一个界面上还要看两个关键选项“格式”默认W3C这是最完整的文本格式按字段记录请求信息。“计划”默认“每天”也就是每个自然日生成一个新log文件。还有“每小时”“每周”“每月”以及“最大文件大小达到即滚动”等选项。生产环境我建议保持“每天”然后再配合“最大文件大小字节”限定单个文件体积具体数值下文会讲。2.2 无界面场景用命令行快速读取日志目录不巧的是很多Windows服务器是云厂商的默认镜像或者平时只能用PowerShell远程管理串口登录根本没有图形桌面。这种情况别慌我用得最多的就是以下三条命令。查看所有站点的基本信息包括Site IDGet-Website | Format-Table Name, Id, State, PhysicalPath得到每个站点的Id之后结合Get-ItemProperty读取IIS配置中的日志路径。这里需要管理员权限运行PowerShellImport-Module WebAdministration Get-ItemProperty IIS:\Sites\你的站点名 | Select-Object -ExpandProperty logFile输出结果里就能看到directory字段比如C:\inetpub\logs\LogFiles。这个命令会展示该站点的日志目录、格式、周期等属性。如果你安装的是IIS 10PowerShell模块WebAdministration已经内置但注意它是32位和64位各有对应版本建议用64位PowerShellx64去操作。还有一种更底层的方式直接查IIS的配置文件——这种方法不依赖任何管理模块任何情况都可以用。2.3 直接读配置文件最底层的确认方式IIS所有配置最终都会落到这个XML文件里C:\Windows\System32\inetsrv\config\applicationHost.config这个文件的权限很高默认只有Administrators和SYSTEM能读你以管理员身份打开的记事本可以看。搜索关键字logFile你会看到类似下面的内容site name我的站点 id1 serverAutoStarttrue application path/ virtualDirectory path/ physicalPathC:\wwwroot\mysite / /application bindings binding protocolhttp bindingInformation*:80:www.example.com / /bindings logFile directoryD:\IISLogs periodDaily formatW3C / /site请注意这条配置中的directory就是该站点最终生效的完整日志目录写什么就是什么不存在路径拼接问题。如果没有单独在站点级指定directory那么全局配置节点长这样log centralLogFileModeSite/centralLogFileMode siteLogDirectory%SystemDrive%\inetpub\logs\LogFiles/siteLogDirectory /logcentralLogFileMode的值有三种Site每个站点各存各的、CentralW3C集中存到同一目录、CentralBinary集中二进制格式。日常遇到的大多数情况都是前者Site也就是我们前面说到的W3SVC子目录方案。从底层配置确认路径看起来步骤多一点但好处是它能一次性看清全局和站点级的所有设置而且完全不需要图形界面。我远程排查服务器问题时直接在命令行里notepad C:\Windows\System32\inetsrv\config\applicationHost.config就完事比反复点鼠标快得多。3. 日志文件命名规则与字段含义懂得看才能查得快找到目录之后会发现里面躺着大量类似u_ex250117.log的文件。这些文件名是有固定规则的理解了规则你一眼就能判断这是哪个站点、哪一天的日志、记录了什么级别的内容。3.1 文件名里的门道u_ex、u_fr、u_in分别是什么IIS日志文件名的常见格式如下前缀含义示例u_ex普通站点日志W3C格式最常用u_ex250117.logu_fr失败请求跟踪日志FREBu_fr2501171234.xml带时间戳u_in未格式化/原始日志较少见u_in250117.loghttperrHTTP.sys层错误日志httperr250117.log250117的解读规则是两位年份、两位月份、两位日期。比如u_ex250117.log就是2025年1月17日当天生成的站点日志。如果日志计划设置的是“每小时”文件名可能是u_ex25011712.log这种在日期后面多出两位小时数。如果设置的是“最大文件大小”那么达到阈值后会自动新建文件文件名为u_ex250117.log、u_ex250117_1.log、u_ex250117_2.log这样递增编号。一个容易忽略的点这个日期是“日志生成的日期”不是“日志记录的日期”。如果你把计划改为“每周”文件名上的日期是该周期开始的日期如果服务器时区设的不是UTC且你用的是默认写法文件名的日期可能和本地自然日有一丁点偏差。下面字段部分会提到日志内容里的时间戳默认是UTC时间这一点非常重要。3.2 W3C字段逐列拆解时间、IP、状态码都藏在哪用记事本打开u_ex250117.log开头几行是以#开头的头信息关键的是这一行#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken这一行定义了下文所有记录列的字段名。常见的列含义如下date、time请求日期和时间。注意IIS默认记录的time 是UTC时间不是服务器本地时间。中国时区UTC8下日志里的时间比北京时间慢8个小时。比如北京时间下午3点收到的请求日志可能记录的是早上7点。这是排查“为什么日志里这个时间段没有记录”时最容易踩的大坑。s-ip服务器的IP地址。多网卡服务器上可以判断请求进入的是哪张网卡。cs-methodHTTP方法GET、POST、HEAD等。cs-uri-stem请求的路径比如/index.html注意它不包含域名部分。cs-uri-queryURL的查询字符串比如?id123没有查询参数时是-。s-port服务器端口80还是443。cs-username通过身份验证的用户名匿名访问时是-。c-ip客户端IP地址。这是定位攻击来源、筛选重点用户的关键字段。cs(User-Agent)客户端浏览器或爬虫标识。cs(Referer)来源页面URL可用来分析流量来源。sc-statusHTTP状态码200正常404未找到500服务器错误403禁止访问等。sc-substatus子状态码IIS特有的能进一步细化错误比如404.2表示“ISAPI筛选器阻止了请求”。sc-win32-statusWin32状态码。这个值常被忽略但它是排查IIS与Windows底层交互问题的重要线索。比如客户端看到连接被重置日志里sc-win32-status是64就说明网络层有连接被删除的错误。time-taken处理请求耗时单位是毫秒。哪些接口慢一排序就知道。记住这个逻辑你就不需要背每个字段cs-开头表示客户端到服务器的信息sc-开头是服务器返回客户端的信息s-是服务器自身信息c-是客户端自身信息。这套前缀很规则碰到不认识的字段可以快速推理。3.3 日志里出现“100”这个值的网络热词我看到最近有个热词叫“日志文件包含100”其实日常运维里更常见的是状态码100它的全称是100 Continue。HTTP协议里客户端发送大请求体之前会先发一个Expect: 100-continue的请求头服务端返回100表示“可以继续发送数据”。这个状态码是正常协议交互但如果日志里大量的100出现且伴随time-taken偏高往往说明客户端和服务端在“继续发送”这个环节上卡顿了值得用网络抓包进一步定位。顺带一提日志里偶尔会出现sc-status200但sc-win32-status64这种“成功但底层有错”的组合往往被忽略。我处理过一个诡异现象网页能打开但CSS和JS资源偶尔加载不出来查IIS日志全是200最后定位到是服务器网卡驱动与虚拟化平台兼容性问题导致连接被重置但HTTP状态码已经发出。这类问题只看HTTP状态码永远查不出来必须结合Win32状态码分析。4. 排查实录常见IIS日志疑难杂症的完整还原光知道日志在哪、字段怎么看还不够真正实践中最让人头疼的是“日志文件呢”和“日志文件怎么这么大”这两类问题。这一节我把过去真实处理过的问题串起来按排查链条一步步说清楚不是直接给结果而是让你能复现我的判断思路。4.1 问题一站点明明在跑但日志目录是空的现象访问网站一切正常打开C:\inetpub\logs\LogFiles\W3SVC1一看里面只有个u_ex250101.log但今天是17号最新日志却停留在一周前甚至整个文件夹直接不存在。排查链路第一步先确认站点真的启用了日志记录。打开IIS管理器选中服务器根节点双击“日志”看日志文件部分有没有勾选“启用”。有个容易忽略的小坑这里的启用只是“允许”站点级的设置里还有个“启用”开关两者同时开启才会写日志。如果某一级把日志停了自然没有记录。第二步检查磁盘空间。日志写入失败不会弹出任何界面提示但系统日志里会记录错误。打开事件查看器Windows日志 - 应用程序筛选来源为IIS-W3SVC-WP的事件错误ID2274表示“日志文件写入失败”。如果磁盘满了IIS会直接停止写日志但站点的业务请求依然正常处理所以从功能上完全察觉不到。第三步确认进程有没有权限往目录里写。如果日志目录被人手动改到了某个只有Administrators才能写的路径而IIS工作进程w3wp.exe默认是用IIS AppPool\站点名这个虚拟账户运行的它就写不进去。此时事件查看器里同样会有对应报错。解决办法是给该目录赋予IIS AppPool\站点名的“修改”权限。第四步看看是不是W3SVC编号对不上。这类问题最常见的原因是你删除了站点又重建了同名站点站点ID变了日志目录变成了新的W3SVC新ID老ID文件夹里的日志就成了“看起来很久没更新”。想要验证就回到2.2的方法用PowerShell查一下目标站点的实际Id再按W3SVCId去找日志目录。这里有一个实用技巧IIS管理器右侧“操作”面板中的“查看日志文件”按钮点击后会直接打开当前站点实际生效的日志目录——它会自动定位到正确的W3SVC文件夹省去手动查找的麻烦。4.2 问题二日志文件存在但用记事本双击打不开或者显示乱码现象日志文件大小有好几百MB甚至几个GB双击打开卡死或者打开后中文URL乱码再或者打开后显示“无法访问正由另一进程使用”。原因和解决办法打不开的常见原因是文件太大。W3C日志增长快很正常稍微有点流量的站点一天的日志就有几百MB。我不建议用系统自带记事本去开日志文件它加载大文件效率极低。我自己的处理习惯是小文件10MB以内用Notepad或VS Code打开。大文件超过100MB不要直接全量打开用PowerShell或Log Parser按条件筛选后导出见下文第5节。文件被占用的提示通常是你要查看的日志刚好正在被IIS写入。W3C日志虽然默认每一条记录即时写入缓冲区但文件句柄确实被w3wp.exe进程占着。复制一份再打开即可或者用“备用数据流”方式读取但没必要复制文件是最省事的方法。乱码问题IIS日志默认是UTF-8编码还是ANSI取决于applicationHost.config里的siteLogDirectory相关配置。不过更常见的情况是URL里带中文参数IIS记录时把非ASCII字符做了URL编码所以看到%E4%B8%AD%E6%96%87这类串是正常的不是乱码。如果你想在日志中直接看到可读的中文路径可以考虑启用IIS的“字段选择”中的cs-uri-stem时同时把cs-uri-query一起记录并设置日志编码为UTF-8不过这不是必须的实际分析时用解码工具一样能还原。4.3 问题三日志增长太快C盘被塞满这是生产环境中出现频率最高的问题。一个繁忙站点一天产生几个GB日志并不罕见如果服务器C盘默认只有60GB几天就爆了。根因分析日志增长快通常有两大类原因。一是正常高并发流量这种情况下日志体积与PV、带宽正相关没有异常二是异常流量比如被CC攻击、被爬虫疯狂抓取、内部定时任务频繁请求此时日志里同一个IP反复刷某几个URL体积会异常膨胀。处理链路先查看统计在PowerShell里输入以下命令可以看到当天日志文件的尺寸Get-ChildItem C:\inetpub\logs\LogFiles\W3SVC1 | Sort-Object Length -Descending | Select-Object -First 5 Name, Length如果发现单个文件超过200MB基本就是流量异常需要进入第2步。按IP统计请求次数。用PowerShell读取日志注意文件可能很大用.NET的StreamReader逐行读更省内存$log C:\inetpub\logs\LogFiles\W3SVC1\u_ex250117.log Get-Content $log | Where-Object { $_ -notmatch ^# } | ForEach-Object { $fields $_ -split [PSCustomObject]{ IP $fields[8]; Status $fields[13] } } | Group-Object IP | Sort-Object Count -Descending | Select-Object -First 10 Count, Name注意$fields[8]和$fields[13]的下标取决于你日志中#Fields行的字段顺序。不同服务器上如果启用了不同的字段列位置会不一样建议先看#Fields行确认索引。这个脚本只是演示思路字段顺序变了要相应调整。根据统计结果做针对性封禁或限流。IP来源如果是陌生境外地址且请求异常密集大概率是扫描或攻击源在Windows防火墙或云安全组层面封掉即可。长期措施把日志目录迁移到大容量磁盘比如D盘同时启用IIS的日志文件大小限制。在服务器根节点的“日志”设置里把“计划”改为“每天”再把“最大文件大小字节”勾上并设置一个值。我习惯设置104857600100MB这样单个文件超过100MB会自动新建编号文件避免了单个文件无限膨胀导致后续分析困难。日志迁移的具体做法是先在D盘建目录比如D:\IISLogs修改服务器级日志目录指向它然后用robocopy把旧日志搬过去。这一步务必要在IIS管理器里先修改配置再移动文件否则复制大日志文件时可能会遇到正在占用的问题。4.4 问题四站点日志里找不到某些请求现象前端明明发起了请求浏览器F12里也能看到网络请求有响应但对应的IIS日志里就是没有这条记录。这个问题的排查链条经常把新人绕晕实际原因是多方面的请求被HTTP.sys内核缓存直接处理了。IIS有一个“内核缓存”特性静态文件或者配置了“HTTP响应头缓存”的动态请求如果命中缓存响应直接从内核返回不会进入w3wp.exe也就不写W3C日志。这种情况最典型的表现是静态资源图片、JS、CSS在第一次请求后后续相同请求全部不记入日志。这不是故障是IIS的缓存优化策略。启用“失败请求跟踪”的站点FREB日志里会用u_fr开头的文件单独记录失败请求普通的u_ex日志里同样没有。如果你排查某个500错误的请求且已经打开了失败请求跟踪记得去C:\inetpod\logs\FailedReqLogFiles里找xml文件。日志刷新延迟。IIS写日志有缓冲机制高并发下可能延迟几秒到几十秒才落盘你刚发完请求立刻去读文件当然看不到。建议等1-2分钟后再看。URL重写规则把请求转发到了其他站点或外部地址。由URL Rewrite模块发出的内部重定向原始请求可能记录在IIS日志里但重定向后的子请求不一定记在同一份日志中视模块配置而定。遇到“日志缺记录”的问题建议按上面的次序从上往下查大多数情况都能定位到。5. 日志分析的实战操作提取指定时段的错误记录日志在那里躺着怎么把它变成有价值的排障信息才是关键。很多运维朋友还在用记事本打开日志文件然后CtrlF搜索小文件还好大文件完全行不通。这里分享我常用的几个方法从纯手动到半自动挑一个适合自己的。5.1 使用LogParser微软官方的日志分析神器Log Parser 是微软提供的一个命令行工具官方下载地址在微软网站可以搜“Log Parser 2.2”它支持用类似SQL的语法查询IIS日志文件功能极其强大。安装之后在命令行里最基本的查询是LogParser.exe SELECT c-ip, COUNT(*) AS Hits FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log GROUP BY c-ip ORDER BY Hits DESC它能一下子统计出所有日志文件中客户端IP的访问次数。想筛选某个时间段内的500错误LogParser.exe SELECT TO_STRING(TO_TIMESTAMP(date, time), yyyy-MM-dd HH:mm:ss) AS Time, cs-uri-stem, sc-status, sc-win32-status FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex250117.log WHERE sc-status 500注意Log Parser默认把date和time作为两个字段处理要用TO_TIMESTAMP拼接后再格式化输出这是新手最容易卡住的地方。5.2 用PowerShell做轻量分析如果不想额外安装工具PowerShell配合正则表达式也足够应付大部分场景。比如筛选出日志中所有HTTP 500错误行Select-String -Path C:\inetpub\logs\LogFiles\W3SVC1\u_ex250117.log -Pattern 500 | Select-Object -First 20这里用 500 带前后空格是为了避免匹配到1500、5000这种包含数字串的状态码。更严谨的做法是结合#Fields行确认状态码位置后再正则定位但日常快速排查用空格分隔法已经够用。如果需要对命中结果做字段拆分用前面的-split方式处理就行。5.3 日志归档与定期清理的推荐做法最后提一下容易被忽略的运维日常——日志不能只积累不清理。我的建议是日志保留周期一般保留30-90天。合规要求严格的可以更长但要考虑存储成本。使用计划任务定期执行归档把30天前的日志压缩后转移到冷存储目录或备份磁盘。归档压缩的核心命令robocopy C:\inetpub\logs\LogFiles D:\LogArchive /MIR /MOV powershell -Command Get-ChildItem D:\LogArchive -Recurse -Filter *.log | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-30) } | Compress-Archive -DestinationPath D:\LogArchive\archive.zip -Updaterobocopy的/MOV参数是把文件移动过去而不是复制压缩之后剩下的*.log可以用Remove-Item清除。这个流程放到计划任务里每月跑一次日志目录就不会无限膨胀。6. 几个常被忽略的小细节与个人经验写了这么多最后把实践中反复踩过、最有价值的一些细节集中说一下。这些内容在微软文档里写得分散很少有人一次讲全。第一日志时间字段默认是UTC不是本地时间。这一条我再强调一遍因为它坑过很多人。如果你在中国时区日志里的文件时间和内容时间差8小时是正常的。分析“下午高峰期”的日志时记得把本地时间减去8小时再去看记录。如果你希望日志直接按本地时间记录可以在服务器级“日志”设置里把“时间”相关的选项调整但IIS的W3C格式底层到底能不能改时区要看版本IIS 10里我测试过部分版本可以通过修改注册表或配置实现但不建议为了看日志方便去改还是自己脑内补足时差更稳妥避免影响其他依赖UTC时间的服务。第二子状态码比主状态码更有价值。比如403.18表示请求被URL授权规则拒绝404.2表示ISAPI筛选器阻止500.0表示模块处理器错误500.21表示模块不识别。这些子状态码直接指引你往哪个方向排查。查日志时不要只看sc-status一定要同时看sc-substatus。第三IIS日志是写文本不是写数据库。因此单条记录里如果字段值本身包含空格IIS会用引号包起来比如cs(User-Agent)和cs(Referer)字段分析时如果简单按空格-split很容易把这些字段拆乱。我在文本里演示的拆分逻辑在遇到带引号的字段时需要用正则或更严谨的解析方式。如果只是统计IP或状态码影响不大一旦要分析User-Agent就得专门处理引号了。第四W3C日志默认输入缓冲区是4KB。高并发下日志批量写入磁盘如果服务器突然断电或强制重启可能会丢失最后一小段时间秒级的日志。对排障来说这点损失通常可以接受如果是金融、公检法等对日志完整性要求极高的业务场景可以考虑用集中日志方案如Windows内建的Event Tracing或第三方采集做冗余。第五备份IIS日志的常见误区是把整个LogFiles目录直接复制走。文件复制过程中如果IIS还在写入容易复制到不完整的文件。更稳妥的做法是用robocopy先同步一遍等待几秒再同步一次把差异部分补上然后对已经不再变化的日志文件做压缩备份。这个技巧本质是利用 robocopy 的多轮增量同步保证一致性我在日常备份脚本里用得很顺手。第六配合失败请求跟踪FREB日志一起看。当IIS日志显示某个请求返回500但你搞不清楚具体是哪个模块报错时开启失败请求跟踪可以捕获请求经过IIS管线每一步的状态。FREB日志是XML格式里面记录了从进入、认证、模块处理、输出整个周期的详细事件。微软文档中叫“Failed Request Tracing”它在IIS 7以上版本内置需要在服务器功能里开启“跟踪”服务然后为站点添加跟踪规则跟踪规则可以按状态码比如500和耗时比如超过5秒触发。开启后访问一次出错的URL去C:\inetpub\logs\FailedReqLogFiles\W3SVC1目录找到新生成的XML文件里面能看到请求在哪个模块花费了多少毫秒、抛出了什么错误比盲猜高效得多。这项功能就是专门为IIS的“黑盒”状态设计的生产环境建议长期开着只对特定站点、特定URL生效不影响正常流量性能损耗可以忽略。第七日志目录权限不能随便收紧。IIS工作进程需要对该目录有写权限但也不要给到Everyone。最安全的是只赋予IIS AppPool\站点名账户的修改权限和Administrators的完全控制权限。曾经见过有人把整个inetpub目录设为Everyone完全控制结果被上传了WebShell服务器被当跳板。日志文件本身也是重要的安全审计数据权限给得太宽等于把攻击痕迹送给攻击者删除。第八分析日志时先确认站点绑定的域名和实际访问的域名。如果服务器上绑定了多个域名日志里cs-uri-stem只有路径不含域名要结合cs(Host)字段如果你启用了该字段来区分是哪个域名的请求。默认W3C字段里没有cs(Host)如果需要要在日志字段选择里手动勾上。这个字段对分析“同一IP 80端口绑多个站点”的场景特别重要。以上这些点都是我这些年处理Windows服务器IIS问题过程中真正遇到过的每一个背后都对应过一次不小的折腾。日志这东西平时不显山不露水一旦出问题它就是破案的第一现场。把路径记牢、字段看懂、工具用熟再做分析时才算真正有了抓手。如果你手头正好有服务器建议现在就去看看日志目录长什么样趁没有故障的时候把它玩透等出问题时才能做到心里有数。
