IIS7自带的站监日志功能其实够用，但很多人不知道它默认只记录基础字段。站监上周帮朋友查一个间歇性503错误，站监翻了两小时日志才找到规律——问题出在应用程序池的站监回收时间设置上。如果你也在用Windows Server跑网站，站监下面这些监控手段比装一堆第三方工具实在得多。站监

先搞清楚IIS7日志的站监默认位置：%SystemDrive%\inetpub\logs\LogFiles。每个网站会生成独立文件夹，站监文件名类似u_exYYMMDD.log。站监打开一个日志文件，站监你会看到类似这样的站监行：

2025-03-21 08:12:33 10.0.0.5 GET /api/user 443 - 192.168.1.22 Mozilla/5.0 200 0 0 234

末尾的234是响应时间（毫秒），这个数字比状态码更能暴露问题。站监超过2000毫秒的站监请求如果频繁出现，基本能确定后端有阻塞。站监我习惯用PowerShell快速筛选：

Get-Content u_ex250321.log | Where-Object {  $_ -match ' 200 ' -and [int]($_ -split ' ')[-1] -gt 2000 }

光看日志不够。站监IIS管理器里有个被忽略的功能：“工作进程”面板。点开服务器节点下的“工作进程”，能看到每个应用程序池的CPU占用、私有内存和请求数。有次一个池的内存涨到1.2GB不释放，重启后半小时又涨回去——最后发现是某个第三方组件没正确释放COM对象。这个面板刷新频率不高，但比任务管理器精准得多，因为它只统计IIS自己的进程。

计数器才是实时监控的利器。在“性能监视器”里添加这几个关键项：

• \Web Service(_Total)\Current Connections — 突增往往意味着攻击或连接泄漏
• \ASP.NET Applications(__Total__)\Requests In Application Queue — 大于0就是排队，超过5基本要查代码
• \Process(w3wp)\% Processor Time — 单核跑满100%说明有死循环

我见过一个电商站，每秒请求才30左右，但Requests In Application Queue长期在10以上。后来发现是某个同步锁把线程池耗尽了。这种问题日志里全是200，但用户端就是转圈。

不想装Zabbix或Prometheus？用Windows自带的“数据收集器集”也能凑合。创建一个用户自定义收集器，把刚才那几个计数器加进去，采样间隔设15秒，输出格式选CSV。让它跑一天，用Excel拉个折线图，峰值一目了然。缺点是没告警，得自己写个脚本定时检查CSV最后一行。

小网站还有个土办法：在web.config里开失败请求跟踪。只针对500错误和响应时间超过5秒的请求，日志写到%SystemDrive%\inetpub\logs\FailedReqLogFiles。每个失败请求会生成一个XML，里面详细到每个模块的耗时。我靠这个抓过一个HttpModule在BeginRequest里做了同步HTTP调用，导致每个请求多等800毫秒。

最后说个坑：IIS7的“动态IP限制”功能别乱开。它默认基于并发请求数封IP，但很多正常用户（比如公司出口NAT）会被误伤。要监控异常IP，不如用日志分析工具统计每分钟请求数超过200的IP，再手动加防火墙规则。

监控这件事，工具越简单越容易坚持。别追求大而全的仪表盘，先把日志里的响应时间分布搞清楚，再盯住应用程序队列长度，八成的问题都能提前发现。