最近客户遇到windows服务器出问题了一时半会不知道怎么办？出问题最好的办法就是看日志，但是我平常分享的都是linux系统的排查，今天就来盘盘windows服务器的！

我记得刚入行那会儿，遇到服务器问题就是一顿乱操作，重启、重装，能折腾的都折腾一遍（重启能解决90%的问题）。后来被师傅骂了好几次才明白，日志才是解决问题的关键。今天就跟大家分享一下Windows Server环境下如何查看和排查日志，这些都是我这些年踩坑总结出来的经验。

事件查看器 - 你的第一站

Windows的事件查看器就像是服务器的"黑匣子"，记录着系统运行的方方面面。打开方式很简单，Win+R输入eventvwr.msc就行，或者在服务器管理器里也能找到。

进去之后你会看到左边有个树状结构，主要分为几个大类：

Windows日志这块是重点关注的地方。应用程序日志记录的是各种软件的运行情况，我经常在这里找到数据库连接失败、Web服务异常之类的问题。系统日志更多是硬件和系统级别的事件，比如磁盘错误、内存问题等等。

安全日志这个就比较有意思了，记录着登录失败、权限变更这些敏感操作。有一次我们服务器被人暴力破解密码，就是通过安全日志发现的，里面密密麻麻全是登录失败的记录，IP地址还都是国外的。

应用程序和服务日志这里面的内容就更丰富了，各种角色和功能都有自己的日志。比如你装了IIS，就会有IIS相关的日志；装了SQL Server，也会有对应的日志分类。

看日志的时候要注意几个关键信息：时间、事件ID、来源、级别。级别分为信息、警告、错误、严重错误几种，一般我们重点关注警告和错误级别的事件。

事件ID这个东西特别有用，每种错误都有固定的ID，你可以直接拿这个ID去微软官网搜索，基本都能找到详细的解释和解决方案。比如事件ID 1074表示系统重启，6005表示事件日志服务启动，这些都是有规律可循的。

还可以通过事件id来查日志信息：

Windows 服务器常见事件 ID 列表

类别

事件 ID

描述

系统事件

1

系统时间已更改

6

系统启动

7

系统关闭

12

操作系统启动

13

操作系统关闭

41

系统崩溃重启

1074

系统关机/重启

安全事件

4624

账户成功登录

4625

账户登录失败

4634

账户注销

4648

显式凭据登录

4672

使用特权登录

4720

创建用户账户

4724

重置密码尝试

4725

禁用用户账户

4728

将成员添加到安全组

4732

将成员添加到本地安全组

4740

用户账户被锁定

4776

域控制器尝试验证账户凭据

应用程序事件

1000

应用程序错误

1001

Windows 错误报告

1002

应用程序挂起

1005

应用程序终止

服务事件

7000

服务无法启动

7009

服务超时

7022

服务正常启动

7023

服务异常终止

7024

服务无法启动

7031

服务尝试重启

7034

服务意外终止

7035

服务发送控制

7036

服务状态改变

Active Directory 事件

1644

目录服务无法分配相对标识符

2886

目录服务暂停

2887

目录服务已恢复

5137

目录服务对象创建

5141

目录服务对象删除

DNS 服务器事件

4013

DNS 服务器启动

4015

DNS 服务器暂停

6702

DNS 事件

文件复制服务

13508

文件复制服务无法与主域控制器建立会话

13509

文件复制服务成功与主域控制器建立会话

磁盘和存储事件

51

磁盘错误

55

文件系统结构损坏

7

设备驱动程序错误

PowerShell - 命令行的威力

虽然图形界面看起来直观，但有时候用PowerShell查日志效率更高，特别是需要筛选大量数据的时候。

Get-EventLog这个命令是基础中的基础：

Get-EventLog -LogName System -Newest 100

这样就能看到系统日志的最新100条记录。如果你想看特定时间段的日志：

Get-EventLog -LogName Application -After "2024-01-01" -Before "2024-01-02"

更强大的是Get-WinEvent命令，功能比Get-EventLog丰富多了：

Get-WinEvent -FilterHashtable @{LogName='System'; Level=2,3}

这里Level=2表示错误，Level=3表示警告，这样就只显示有问题的事件，不用在一堆信息级别的日志里翻来翻去。

有时候我需要查找包含特定关键词的日志：

Get-WinEvent -FilterHashtable @{LogName='Application'} | Where-Object {$_.Message -like "*SQL*"}

这样就能找到所有消息中包含"SQL"的事件，对于定位特定应用的问题很有帮助。

IIS日志 - Web服务的秘密

如果你的服务器跑着Web服务（一般用windows服务器都会跑这个服务吧！），IIS日志绝对是排查问题的重要工具。默认情况下，IIS日志存放在C:\inetpub\logs\LogFiles目录下。

IIS日志的格式一般是W3C扩展格式，看起来像这样：

2024-01-15 10:30:25 192.168.1.100 GET /api/users - 80 - 192.168.1.200 Mozilla/5.0... 200 0 0 1250

这里面包含了访问时间、客户端IP、请求方法、URL、状态码、响应时间等信息。状态码是重点关注的，200表示正常，404是找不到页面，500是服务器内部错误。

我经常用一些工具来分析IIS日志，比如Log Parser Studio，可以用SQL语句来查询日志：

SELECT TOP 10 cs-uri-stem, COUNT(*) as hits FROM [logfile] WHERE sc-status >= 400 GROUP BY cs-uri-stem ORDER BY hits DESC

这样就能找出错误最多的页面，对于定位问题很有帮助。

当然，如果你喜欢用PowerShell，也可以这样分析：

Import-Csv "C:\inetpub\logs\LogFiles\W3SVC1\u_ex240115.log" -Delimiter " " | Where-Object {$_."sc-status" -ge 400} | Group-Object "cs-uri-stem" | Sort-Object Count -Descending性能监视器 - 系统健康的体检报告

除了事件日志，性能监视器也是个好东西。虽然它主要是监控性能指标，但也会记录一些日志信息。

打开perfmon.msc，你可以看到实时的性能数据，也可以创建数据收集器集来长期监控系统状态。我一般会关注几个关键指标：

CPU使用率持续过高可能表示有程序占用过多资源；内存使用率如果接近100%，系统就会开始使用虚拟内存，性能会明显下降；磁盘队列长度如果经常大于2，说明磁盘IO成为瓶颈了。

有一次我们的Web服务响应特别慢，通过性能监视器发现磁盘队列长度经常超过10，后来查到是数据库日志文件和数据文件放在同一个磁盘上，IO冲突导致的。

应用程序特定日志

不同的应用程序都有自己的日志记录方式，这些也不能忽视。

SQL Server的日志一般在SQL Server Management Studio里查看，也可以直接看文件，通常在SQL Server安装目录的Log文件夹下。SQL Server的错误日志记录着数据库启动、连接、查询错误等信息，对于数据库问题排查很重要。

.NET应用程序如果没有特殊配置，一般会把日志写到事件查看器的应用程序日志中。但很多应用会使用NLog、Log4Net这些日志框架，把日志写到自定义的文件里。

自定义应用程序的日志位置就五花八门了，有的放在程序目录下，有的放在ProgramData文件夹，还有的直接写数据库。这就需要你了解具体应用的日志配置了。

日志分析的一些技巧

看日志不是简单的从头看到尾，需要一些技巧。

时间关联是最重要的，当用户报告某个时间点出现问题时，你要在各个日志中找到对应时间段的记录，看看系统、应用、网络各个层面发生了什么。

关键词搜索也很有用，比如"error"、"exception"、"failed"、"timeout"这些词汇经常出现在问题相关的日志中。

模式识别需要一定经验，比如看到大量的登录失败记录，可能是暴力破解攻击；看到内存不足的警告后紧跟着应用程序崩溃，基本可以确定是内存问题。

有时候问题不是单一原因造成的，需要综合分析多个日志源。我遇到过一次奇怪的问题，Web应用偶尔会卡死，单看应用日志没发现异常，后来结合系统日志发现是网卡驱动有问题，偶尔会丢包，导致数据库连接超时。

日志级别的理解也很关键。信息级别的日志通常记录正常操作，比如服务启动、用户登录成功等；警告级别表示有潜在问题但不影响正常运行；错误级别就是明确的问题了，需要重点关注；严重错误通常意味着系统或服务即将崩溃。

我习惯先看错误和严重错误，再看警告，最后才看信息。这样能快速定位到问题的核心。

常见问题的日志特征

经过这么多年的运维经验，我总结了一些常见问题在日志中的表现特征。

内存不足通常会在系统日志中看到事件ID 2004（资源不足）或者1001（Windows错误报告），应用程序日志中可能会有OutOfMemoryException相关的错误。

磁盘空间不足会产生事件ID 2013（磁盘空间不足警告）或者55（文件系统错误），这时候应用程序可能会出现各种奇怪的问题。

网络连接问题在系统日志中可能看到事件ID 4201（网络适配器连接丢失）或者DNS解析失败的错误，应用程序日志中会有连接超时、无法连接到远程服务器之类的错误。

权限问题通常在安全日志中有记录，事件ID 4625表示登录失败，4648表示使用显式凭据登录，这些都可能与权限相关。

服务启动失败会在系统日志中产生事件ID 7000系列的错误，具体的错误信息通常会指出是什么原因导致服务无法启动。

故障排查的实战案例

说了这么多理论，来个实际案例吧。

前段时间我们有个客户的Web应用突然变得很慢，用户投诉不断。我按照惯例开始查日志：

首先看IIS日志，发现响应时间确实比平时长很多，而且有不少500错误。然后看应用程序日志，发现大量的数据库连接超时错误。

接着查看SQL Server日志，发现数据库本身没什么异常，但是有一些死锁的记录。再看系统日志，发现磁盘IO等待时间异常高。

最后通过性能监视器确认，磁盘队列长度经常超过10，平均响应时间也比正常情况高出好几倍。

问题定位到了磁盘IO，进一步检查发现是数据库的事务日志文件增长过快，而且没有定期备份和截断，导致磁盘空间紧张，IO性能下降。

解决方案就是立即备份事务日志，释放空间，然后调整数据库的备份策略，避免类似问题再次发生。

整个排查过程用了不到一个小时，如果没有日志的帮助，可能要花好几倍的时间才能找到根本原因。

监控和告警的重要性

被动地查看日志效率不高，更好的做法是建立主动的监控和告警机制。

Windows Performance Toolkit中的工具可以帮助建立性能基线，当系统偏离正常范围时及时告警。

SCOM（System Center Operations Manager）是微软的企业级监控解决方案，可以监控整个Windows环境，包括服务器、应用程序、网络设备等。

对于中小型环境，PRTG或者Zabbix这些开源工具也是不错的选择。我之前用过Zabbix监控Windows服务器，配置相对简单，而且免费。

关键是要设置合理的告警阈值。我见过有些环境告警设置得太敏感，一天能收到几十条告警邮件，最后管理员都麻木了，真正的问题反而被忽略。

比如CPU使用率告警，我一般设置为连续5分钟超过80%才告警，偶尔的峰值是正常的。内存使用率可以设置为超过90%告警，磁盘空间剩余不足10%时告警。

写在最后

Windows服务器的日志排查是个系统性工程，需要掌握多种工具和技巧。从基础的事件查看器到高级的PowerShell命令，从单机日志分析到分布式日志管理，每个层面都有其价值。

关键是要养成良好的习惯：遇到问题先看日志，定期检查系统状态，建立合理的监控告警机制。日志不会说谎，每个问题都会在某个地方留下痕迹，耐心分析总能找到答案。

现在的IT环境越来越复杂，微服务、容器、云原生这些新技术带来了新的挑战，但日志分析的基本思路是不变的：收集、存储、分析、告警。掌握了这些基础技能，不管技术怎么发展，你都能游刃有余。

记住，成为日志分析专家不是一朝一夕的事情，需要在实践中不断积累经验。每次排查问题后都要总结，建立自己的知识库，这样遇到类似问题时就能快速解决。

希望这篇文章对大家有帮助，如果你觉得有用的话，别忘了点个赞转发一下。有什么问题或者想法，也欢迎在评论区交流讨论！

如果这篇文章对你有帮助，别忘了点赞转发支持一下！想了解更多运维实战经验和技术干货，记得关注@运维躬行录，领取学习大礼包！！！我会持续分享更多接地气的运维知识和踩坑经验。让我们一起在运维这条路上互相学习，共同进步！

：运维躬行录

个人博客：躬行笔记