iis日志分析工具

服务器一崩，志分运维第一反应是析工查IIS日志。问题是志分，Windows那套日志格式真不友好——纯文本、析工字段靠空格分隔、志分UTC时间戳、析工还有那堆SC-Status和CS-Status的志分十六进制代码。用记事本打开一个500MB的析工日志文件？等着卡死吧。

我见过太多人还在用findstr硬扛。志分不是析工说不行，小站点一天几千条请求，志分凑合能用。析工但只要日PV过十万，志分日志文件动辄几百兆甚至上G，析工findstr跑一次十几分钟，志分还只能做最简单的字符串匹配。想看某个IP在哪个时间段访问最频繁？想统计哪些URL返回了500错误？findstr做不到，你得自己写脚本解析。

几款真正能用的工具

Log Parser是微软自己出的，算是官方答案。它用SQL语法查日志，比如 SELECT TOP 10 cs-uri-stem, COUNT(*) FROM ex.log GROUP BY cs-uri-stem ORDER BY COUNT(*) DESC，直接出结果。功能确实强，支持IIS、事件日志、CSV等多种格式。但它的痛点也明显：命令行操作，SQL语法有自己的怪癖，而且微软2005年之后基本没怎么更新了。装是能装，用起来总觉得像在开一辆二十年前的车。

Log Parser Studio是Log Parser的图形化前端，社区里有个叫Gabriel的哥们一直在维护。它把常用查询做成了模板，点几下就能出报表。我拿它查过一轮慢请求，筛选time-taken大于5000毫秒的记录，再按URL聚合，十分钟定位到一个有问题的API接口。这东西好用在省事，但底层还是Log Parser，遇到超大文件一样慢。

Splunk和ELK当然能吞IIS日志，功能也强到没边。但为了一台IIS服务器上Splunk？太重了。免费版每天限500MB索引量，稍微大点的站点直接超。ELK倒是开源，可你得维护Elasticsearch集群、Logstash管道、Kibana面板——运维成本比IIS本身还高。适合已经有ELK基础设施的团队，单独为IIS日志搭一套，不划算。

冷门但好用的选择

有个叫IISLogAnalyzer的小工具，界面简陋得像Windows 98时代的产物，但解析速度意外地快。它用的是内存映射文件读取，1GB的日志大概十几秒能扫完。支持按状态码、IP、URL、时间范围过滤，还能导出CSV。缺点是不支持自定义查询，只能用它预设的几组过滤条件。够用，但不够灵活。

另一个思路是用PowerShell自己写。Import-Csv配合Where-Object和Group-Object，几行代码就能做基础统计。比如统计状态码分布：

Import-Csv ex.log -Delimiter ' ' | Group-Object sc-status | Sort-Object Count -Descending

慢是慢了点，但胜在零依赖、完全可控。我有个朋友管着三十多台IIS，他就是用PowerShell脚本每天凌晨跑一遍日志分析，结果写进SQLite，早上到公司打开网页看报表。土办法，但稳定跑了三年没出过问题。

选工具的逻辑

日志量决定一切。日均十万请求以下，Log Parser Studio足够。百万级以上，要么上ELK，要么自己写脚本做预处理。别迷信“一站式解决方案”，很多所谓的大数据日志分析平台，部署完发现80%的功能用不上，剩下的20%还不如findstr直接。

还有一点：IIS日志默认是UTC时间。分析的时候记得转换时区，不然你会发现“凌晨三点”的访问高峰其实是你自己的时区没设对。这个坑我踩过，查了半天以为是爬虫，结果是时间偏移了八小时。

工具选对了，排查问题的速度能快一个数量级。选错了，就是在用勺子挖隧道。

很赞哦!（4）