IIS7网站监控：别等用户骂了才去看日志
凌晨两点十七分，站监我的站监手机突然震动。不是站监闹钟，是站监监控脚本发来的邮件——某个客户的IIS7站点挂了，HTTP 503。站监我揉着眼睛爬起来，站监打开笔记本，站监远程登录服务器。站监IIS管理器里那个网站图标显示“已停止”，站监像一台熄火的站监发动机。重启应用程序池，站监三秒后恢复。站监整个过程不到五分钟，站监但如果不是站监监控在盯着，最早发现问题的站监可能是明天早上九点第一个点开网页的访客。
IIS7的监控，说穿了就三件事：进程活着吗？响应快不快？请求有没有异常堆积。但很多人把这三件事做成了三座孤岛。进程死了靠人工巡检，响应慢了靠用户投诉，请求异常了靠事后翻日志。这种被动模式在流量小的站点上还能凑合，一旦并发上来，一次故障就能让你从“技术还行”变成“怎么搞的”。
我见过最典型的翻车案例：某电商站做促销，提前一周压测过，一切正常。促销当天上午十点，页面开始卡顿，运维小哥盯着任务管理器看CPU，一直没到100%，觉得没事。结果十二点整，网站直接白屏。重启IIS后好了，但黄金三小时已经过去。后来查原因，是某个第三方组件的线程池泄漏，CPU不高但线程耗尽。如果当时监控了“当前连接数”和“工作进程线程数”，一眼就能看出来不对劲。
监控IIS7，别只盯Windows自带的任务管理器。那玩意儿看总量可以，看细节就是瞎子。你需要看的是W3SVC性能计数器——Web服务相关的那些：当前连接数、每秒请求数、请求执行时间、排队请求数。排队请求数尤其要命。一旦这个数值持续大于零，说明请求已经堵住了，哪怕CPU和内存看起来都正常，离崩溃也不远了。
还有事件日志。IIS7在应用程序池崩溃时会在系统日志里留下事件ID 5002之类的记录。很多人不看这个，等用户反馈了才去翻。我习惯写个小脚本，定时扫事件日志，发现新的错误级别记录就推送通知。微信机器人和邮件都行，关键是别让它躺着睡觉。
配置文件也别忽略。IIS7的applicationHost.config是核心，但很多人改完就忘。我吃过一次亏：某次改完连接池设置，没备份，结果重启后站点起不来，查了半天才发现是配置语法错误。后来我加了个每日自动备份——把整个C:\Windows\System32\inetsrv\config目录打包存到另一台机器。这个习惯救过我至少三次。
监控不是越复杂越好。我见过有人上了全套APM，分布式追踪、调用链分析、链路拓扑图，结果日常维护成本比网站本身还高。IIS7这种老伙计，用轻量级方案就够了——一个定时任务跑PowerShell脚本，检查服务状态、抓性能计数器、读事件日志，有异常就发通知。二十行代码能覆盖80%的故障场景，剩下20%靠人工判断。
最后说个反常识的：监控IIS7，别只监控IIS本身。它的状态依赖很多外部因素——数据库连接池、共享文件权限、甚至DNS解析。我有一次排查站点间歇性卡顿，最后发现是另一个站点的高CPU占用拖垮了整台服务器的线程调度。所以监控要加一层——看同一台机器上其他进程的资源占用。IIS7再稳，也架不住邻居打架。
监控这活儿，做得好是隐形防线，做得差是事后诸葛亮。别等用户骂了才去看日志——那时候你看到的只是事故后的灰烬，而不是起火的那一瞬间。