服务器日志平时基本不会有人主动查看，可一旦故障发生，日志就是最靠谱的排查线索。它记录系统、各类服务、应用程序运行期间产生的行为，报错信息大多保存在日志内。准备定位故障的时候，不要直接翻阅日志，先确定两件基础信息，故障大致发生的时间段，还有可能关联到哪些服务。网站打不开，可能涉及Nginx、应用进程和数据库；服务器运行卡顿，优先查看系统日志和内核消息；账号登录失败，重点查看认证相关日志。
Linux系统日志大多存放于/var/log目录。CentOS的系统消息日志路径是/var/log/messages，Ubuntu和Debian一般放在/var/log/syslog。登录认证记录保存在/var/log/secure或者/var/log/auth.log。搭载systemd的系统，可以用journalctl查看服务日志，journalctl -u nginx查看单个服务输出，journalctl --since "2026-09-15 10:00"筛选指定时间段日志。Web服务日志通常在/var/log/nginx/或者/var/log/httpd/，access.log记录所有访问请求，error.log保存错误信息。应用日志位置不固定，有的放在/var/log/应用名/目录，也有的直接放在项目目录下logs文件夹，具体取决于部署方式。
Windows服务器主要依靠事件查看器。打开之后，Windows日志分类包含应用程序、安全、系统三类。应用程序日志可以找到程序崩溃、服务启动失败记录；系统日志记录驱动、硬件、服务控制管理器相关故障。如果部署IIS，还需要查看IIS日志，默认路径C:inetpublogsLogFiles，日志按照站点和日期分文件夹存放。PowerShell也支持日志查询，Get-EventLog -LogName Application -EntryType Error能够筛选应用程序内的错误事件，Get-WinEvent的查询功能更加灵活。
查看日志最常用的操作是实时跟踪和关键词检索。Linux中tail -f 文件名可以持续读取文件末尾，新产生的日志会实时刷新，适合复现问题的时候观察。less 文件名用来打开大日志文件，按下/输入关键词检索，n键跳转下一条匹配内容。grep是检索常用工具，grep -i "error" 文件名忽略大小写检索错误，grep -n同时展示行号。日志体量很大时可以组合命令，示例grep "2026-09-15 10:2" 应用日志 | grep -i "exception"。
定位报错的核心思路就是缩小检索范围。依据用户反馈或者监控告警锁定时间点，只检索该时间段日志。时间尽量精确，服务器每秒可能生成几十上百条日志。找到第一条异常记录，不要只看这一行，向上翻看几行查看请求来源，向下查看后续连锁反应。很多错误日志只提示连接失败，真正根源在前面，比如数据库连接池耗尽或者磁盘空间占满，上下文内容往往比单条报错行更有价值。
检索关键词的选择也有讲究。除了error、fail、exception，还可以尝试timeout、refused、denied、unreachable、reset、oom、segfault、panic。部分程序会输出中文报错，像失败、超时、拒绝，检索的时候不要只使用英文关键词。日志级别也要留意，DEBUG和INFO一般不属于故障，WARN大多是提醒信息，ERROR和FATAL才是重点关注对象。但部分程序会把严重问题记录在WARN级别，不能直接忽略。
一台服务器运行多个服务，最好顺着请求链路串联查看日志。用户访问网站，请求先经过Nginx，转发到应用程序，应用再查询数据库。Nginx的access.log记录请求时间、状态码、响应耗时，error.log记录转发失败原因。应用日志能看到业务代码在哪一步出错。数据库日志可以找到慢查询或者连接异常。把多份日志按时间对齐，就能还原完整故障过程。
Windows排查故障，除了事件查看器，还能使用筛选功能。事件查看器右侧筛选当前日志，能够按事件级别、来源、事件ID、时间段过滤。比如IIS返回500错误，可以查看系统日志里WAS或者W3SVC的警告。程序崩溃，查找来源为.NET Runtime或者Application Error的事件。事件ID是重要线索，微软以及很多软件厂商文档都解释了常见事件ID含义。
日志轮转很容易被忽略。Linux环境logrotate会压缩归档旧日志，生成类似access.log.1.gz、access.log.2.gz这类文件。只查看当前日志文件，就找不到历史记录。检索压缩日志使用zgrep或者zcat | grep。Windows的IIS日志按日期拆分文件，事件查看器日志存在大小上限，旧事件会被覆盖。排查历史故障，要先确认日志保存周期。
时区问题经常造成无效排查。服务器可能使用UTC时区，应用日志使用本地时间，数据库又是另一种时间标准。发现时间对不上，统一核对各个组件时区设置，换算成同一时区再检索。多台服务器分布式部署，日志分散在不同机器，建议搭建集中日志平台，例如ELK、Loki、Graylog。没有集中日志系统，就手动ssh登录各台服务器查询，或者用rsync把日志统一拉取到本地。
权限方面，不少日志文件仅root或者特定用户具备读取权限。普通账号打开提示Permission denied，并不是日志损坏，只是权限不足，添加sudo或者切换有权限账号即可。日志文件正在写入时，直接cp或者cat读取基本没问题，但编辑器打开可能出现文件内容变动，这种场景优先选用tail、less。
定位故障很难一次找到线索。检索没有结果，大概率是关键词不对、时间范围选错，或是日志本身没有记录这条报错。这时可以检查服务日志配置，确认日志级别设置过高，过滤掉错误信息。实在找不到线索，可以手动复现故障，同时用tail -f实时监控相关日志，这种方式比翻历史日志效率更高。日志分析依靠耐心串联线索，不是死记命令。多实践几次，就能快速判断该查看哪些日志文件、用什么关键词检索。