< 返回
Linux 服务器如何查看日志与排查问题
2026-02-05 20:52
作者：技术部
阅读量：9
Linux 服务器的日志系统是运维和故障排查的核心基础设施。它记录了从内核启动、硬件初始化、服务运行、用户登录到应用异常的几乎所有事件。现代 Linux（几乎所有 2015 年后主流发行版）默认使用 systemd-journald 作为主要日志守护进程，同时保留传统 rsyslog 或 syslog-ng 将部分日志写入纯文本文件。
排查问题的本质思维模型是：
- 先定位“哪个组件出了问题”（服务？内核？网络？应用？）
- 再确定该组件的日志来源（journald？特定文件？）
- 过滤出相关时间窗口 + 关键词
- 观察模式（重复错误、时间相关性、资源耗尽前兆）
- 交叉验证（dmesg、ss、top、free、df 等状态 + 日志）
1. 日志两大体系对比（理解来源是关键）
| 体系 |
存储格式 |
主要查看工具 |
持久化默认情况 |
优点 |
缺点 |
主流发行版默认 |
| systemd-journald |
二进制（结构化） |
journalctl |
内存（volatile）或 /var/log/journal（persistent） |
结构化字段丰富、查询高效、跨服务关联 |
不直观、需 journalctl 查看 |
Ubuntu 16.04+、Fedora、RHEL 7+、Debian 9+、Arch |
| 传统 Syslog |
纯文本 |
less/tail/grep/awk |
持久化（/var/log/*.log） |
简单、兼容性强、可直接 grep |
无结构、旋转后难关联、重启丢失部分上下文 |
老系统、Alpine、部分容器镜像 |
绝大多数现代服务器同时存在两者：journald 捕获所有，rsyslog 把部分转发到 /var/log 文件。
2. journalctl —— 现代服务器排查首选工具
journalctl 是查看 systemd-journald 日志的唯一标准接口。它支持按时间、服务、优先级、进程、引导次数等多维度过滤。
核心过滤参数（高频组合）：
- 时间范围 --since "2026-02-10 18:00"--until "2026-02-11 06:00"-b（本次启动以来） -b -1（上一次启动） -b 0（当前引导，显式写法）
- 服务单元 -u nginx 或 -u nginx.service-u php8.3-fpm、 -u docker
- 优先级（emerg、alert、crit、err、warning、notice、info、debug） -p err（只显示 error 及以上） -p warning..emerg（范围）
- 进程/用户 _PID=1234_UID=1000 或 --user（当前用户）
- 实时跟踪 -f（类似 tail -f）
- 输出格式 -o json-pretty（结构化输出，便于 jq 处理） -o short-precise（带微秒时间戳）
高频组合示例（理论描述，非代码）：
- 查看 nginx 服务从昨天 20:00 开始的所有错误 journalctl -u nginx --since "yesterday 20:00" -p err
- 实时监控 ssh 登录失败尝试 journalctl -u ssh -f -g "Failed password"
- 查看本次启动以来内核相关消息 journalctl -b -p warning..crit _TRANSPORT=kernel
- 比较前后两次重启的启动过程差异 journalctl -b -1 -u initramfs* ; journalctl -b -u initramfs*
3. 传统文本日志位置与含义（/var/log 下）
即使 journald 主导，rsyslog 仍会把关键信息写入纯文本，便于脚本和快速 grep。
常见文件对应关系（2026 年主流发行版）：
- 通用系统消息 Ubuntu/Debian → /var/log/syslog RHEL/Rocky/Alma → /var/log/messages
- 认证与安全事件（登录、sudo、ssh、pam） Ubuntu/Debian → /var/log/auth.log RHEL 系 → /var/log/secure
- 内核环形缓冲（启动、驱动、硬件错误） dmesg（内存中实时）或 journalctl -k / --dmesg
- Web 服务器（Nginx/Apache） /var/log/nginx/{access,error}.log /var/log/apache2/{access,error}.log
- 数据库 /var/log/mysql/error.log 或 /var/log/mariadb/mariadb.log /var/log/postgresql/postgresql-*.log
- 应用自定义日志 通常在 /var/log/应用名/ 或 /opt/应用名/logs/
排查路径建议：
- 服务启动失败 → journalctl -u 服务名 -xe（-x 解释错误码）
- 登录问题 → journalctl -u ssh 或 grep auth.log "Failed"
- 磁盘/IO 问题 → journalctl -u systemd-fsck* 或 dmesg | grep -i error
- OOM killed → journalctl -k | grep -i "out of memory"
- 高负载前兆 → journalctl --since "1 hour ago" | grep -i "high load"
4. 结构化排查流程（推荐闭环）
- 现象确认：是什么症状？何时开始？影响范围？
- 粗筛时间窗口：journalctl -b -p err（本次启动错误）或 -f（实时）
- 锁定嫌疑组件：systemctl status 可疑服务 → journalctl -u 该服务 -n 200
- 关键词过滤：加 -g "error|fail|denied|timeout|oom|crash"
- 交叉验证：
- 资源：top/htop/free -h/df -h/iostat
- 网络：ss -s/netstat/ss -ltnp
- 内核：dmesg -T | tail -50
- 审计：ausearch -m avc -ts recent（如果启用 SELinux/AppArmor）
- 深挖：journalctl _PID=xxx 或 journalctl --since "时间" --until "时间" -o json | jq
- 验证修复：重启服务后立即 journalctl -f -u 服务名 观察
5. 进阶技巧与最佳实践
- 启用持久化 journal（否则重启丢失日志） 创建 /var/log/journal 目录并设置 Storage=persistent
- 限制 journal 大小（防止 /var 爆满） journald.conf 中 SystemMaxUse=2G / RuntimeMaxUse=512M
- 实时多服务监控 multitail /var/log/nginx/.log 或 journalctl -f -u nginx -u php -u mysql
- 结构化输出 + 脚本化 journalctl -o json -f | jq 'select(.PRIORITY <= "3") | {time: .__REALTIME_TIMESTAMP, msg: .MESSAGE}'
- 中央化（生产推荐） 转发到 Loki / ELK / Graylog / OpenObserve / ClickHouse 等，避免单机日志丢失
日志排查的核心不是记住所有路径，而是建立“症状 → 组件 → 日志源 → 过滤条件 → 模式识别”的思考链条。
熟练后，90% 的常见问题（服务挂了、端口不通、权限错误、资源耗尽、配置语法错）都能在 5–15 分钟内通过 journalctl + 几条 grep 定位根因。
网站资讯
关于我们
