Linux系统日志需分层分析，优先查看systemd-journald日志因其结构化、纳秒级时间戳及跨服务统一性；关键字段包括\_COMM、PRIORITY、UID、\_EXE等上下文信息；定位问题需结合时间轴、资源状态与依赖关系综合判断。

Linux系统日志不是“翻翻就懂”的流水账，而是分层、多源、有时序依赖的诊断线索。直接 grep error 很可能漏掉前置征兆，或误判无关告警。

systemd-journald 日志为什么比 /var/log/messages 更优先看？

journald 是 systemd 管理下所有服务的统一日志入口，自带结构化字段（_PID、_COMM、SYSLOG_IDENTIFIER）、纳秒级时间戳、自动轮转和二进制索引，查询效率远高于文本日志。尤其在容器、临时服务、失败 unit 启动场景下，/var/log/messages 常常根本没记录。

• 查某服务最近 10 行：

  journalctl -u nginx.service -n 10

• 查启动失败原因（含依赖失败）：

  journalctl --boot --priority=3 -u mysql.service

• 过滤特定进程名 + 错误级别：

  journalctl _COMM=sshd PRIORITY=3

• 注意：journalctl 默认不持久化跨重启日志，需确认 Storage= 在 /etc/systemd/journald.conf 中设为 persistent，否则 --since yesterday 可能查不到东西

常见错误日志里哪些字段真正关键？

日志行里真正有用的不是第一眼看到的 ERROR 或 failed，而是紧邻的上下文字段。例如：

• Failed to start The Apache HTTP Server. —— 这只是结果，重点看前一行的 See 'systemctl status httpd.service' and 'journalctl -xe' for details.
• Connection refused 出现在 curl 日志里？先确认是目标端口未监听（ss -tlnp | grep :8080），还是防火墙拦截（iptables -L -n -v），而不是急着改应用配置
• Permission denied 类错误，必须结合 UID= 和 _EXE= 字段判断是哪个进程、以哪个用户身份尝试访问哪个路径（比如 _EXE=/usr/bin/python3 + UID=1001 + /etc/ssl/private/key.pem）
• 磁盘满导致服务异常时，journalctl 本身可能写不进日志，要立刻用 df -h /run/log/journal 和 du -sh /var/log/journal/* 查空间

如何快速定位“刚出问题”的时间窗口？

别从头 tail -f /var/log/syslog 盲等。真实故障往往有链式反应：内核报 Out of memory: Kill process → 某个 java 进程被杀 → 随后大量 Connection reset by peer 出现在 nginx 日志里。必须按时间轴串起来看。

• 用 journalctl --since "2025-05-20 14:23:00" 定点查（支持自然语言，如 "2 hours ago"）
• 用 journalctl -S "@1716214980" 按 Unix 时间戳查（避免时区歧义）
• 跨服务对齐时间：

  journalctl -u redis-server -u webapp.service --since "2025-05-20 14:23:00" | head -50

• 注意系统时间是否漂移：timedatectl status 查 System clock synchronized: 是否为 yes；若否，journalctl 的时间戳不可信

日志本身不会说“哪里错了”，它只说“当时发生了什么”。真正难的不是读日志，而是把 _PID、_COMM、MESSAGE、系统资源状态、服务依赖关系这四条线，在正确的时间点上拧成一股诊断逻辑——而这一步，没有任何工具能自动帮你完成。

# mysql  # 端口  # app  # 防火墙  # nginx  # apache  # go  # redis  # java  # python  # linux  # 工具