IIS .NET Core应用服务器日志分析及宕机原因排查求助

从你提供的日志格式来看，这是标准的IIS W3C扩展日志。针对200个日志文件的批量分析需求，以下是无需服务器权限、可本地执行的高效方案：

1. 充分利用LogParser 2.2批量处理（不用逐个打开文件） #

LogParser本身支持批量匹配文件，完全不需要逐个操作。直接用命令行执行以下查询：

• 筛选所有错误请求（4xx/5xx状态码）：

  logparser.exe "SELECT * FROM 'G:\LogFiles\*\2022-11-*.log' WHERE sc-status >=400 ORDER BY date, time"
  

• 统计5xx错误Top请求路径（快速定位可能引发宕机的接口）：

  logparser.exe "SELECT cs-uri-stem, COUNT(*) AS ErrorCount FROM 'G:\LogFiles\*\2022-11-*.log' WHERE sc-status >=500 GROUP BY cs-uri-stem ORDER BY ErrorCount DESC"
  

• 导出错误日志到CSV（方便后续用Excel做可视化分析）：

  logparser.exe "SELECT date, time, cs-uri-stem, sc-status, c-ip INTO 'error_summary.csv' FROM 'G:\LogFiles\*\2022-11-*.log' WHERE sc-status >=400"
  

  替换命令中的路径为你的实际日志文件夹路径即可。

2. PowerShell批量分析（Windows自带，无需额外工具） #

用PowerShell可以灵活定制分析逻辑，适合快速筛选和统计：

• 提取所有5xx错误日志到单独文件：

  Get-ChildItem "G:\LogFiles\*\2022-11-*.log" | ForEach-Object {
      Get-Content $_.FullName | Where-Object { 
          $_ -match ' (\d{3}) ' -and [int]$matches[1] -ge 500 
      }
  } | Out-File "G:\LogFiles\5xx_errors_202211.txt"
  

• 统计触发错误的高频IP：

  Get-ChildItem "G:\LogFiles\*\2022-11-*.log" | ForEach-Object {
      Get-Content $_.FullName | Where-Object { 
          $_ -match ' (\d{3}) ' -and [int]$matches[1] -ge 400 
      } | ForEach-Object {
          $fields = $_.Split(' ', [System.StringSplitOptions]::RemoveEmptyEntries)
          [PSCustomObject]@{
              IP = $fields[11]
              StatusCode = $fields[16]
          }
      }
  } | Group-Object IP | Sort-Object Count -Descending | Select-Object Name, Count
  

3. Excel可视化批量分析（适合非技术人员） #

如果更习惯图形化操作，用Excel就能完成：

• 打开Excel，点击「数据」选项卡 → 「获取数据」→ 「从文件」→ 「从文件夹」
• 选择日志所在的父文件夹，点击「确定」后，在弹出的界面中添加筛选：文件名包含2022-11-
• 点击「合并&加载」，选择分隔符为「空格」，并勾选「连续分隔符视为单个」
• 加载完成后，对「状态码」列（对应示例中最后几个数字前的200字段）添加筛选，筛选出4xx和5xx的记录
• 用数据透视表统计不同时间段、请求路径、IP的错误分布，快速定位宕机前后的异常请求

4. 轻量级图形化工具辅助 #

• LogParser Studio：微软官方推出的LogParser图形化前端，直接拖放所有日志文件，通过可视化界面配置筛选条件，无需记忆命令行语法，支持导出分析结果
• Notepad++ 批量搜索：打开Notepad++，点击「搜索」→ 「在文件中查找」，输入搜索关键词（比如5\d{2}匹配所有5xx状态码），选择所有2022-11-*.log文件，导出搜索结果到文本，快速定位错误行

分析重点提示 #

• 优先关注5xx状态码的集中出现时间段，这通常是服务器内部错误的直接表现，可能和宕机直接相关
• 检查宕机前后的请求量变化，如果突发大量请求（比如爬虫、批量调用），可能是资源耗尽导致宕机
• 留意异常的请求路径（比如不存在的接口）或用户代理（UA），这类请求可能触发错误或消耗资源
• 关注日志末尾的响应时间字段（示例中最后四个数字，单位毫秒），大量长响应时间的请求可能预示服务器资源不足

内容的提问来源于stack exchange，提问作者cdub