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 <code>nginx.service</code> -n 10
- 查启动失败原因（含依赖失败）：
journalctl --boot --priority=3 -u <code>mysql.service</code>
- 过滤特定进程名 + 错误级别：
journalctl _COMM=<code>sshd</code> 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 "2024-05-20 14:23:00"定点查（支持自然语言，如"2 hours ago"） - 用
journalctl -S "@1716214980"按 Unix 时间戳查（避免时区歧义） - 跨服务对齐时间：
journalctl -u <code>redis-server</code> -u <code>webapp.service</code> --since "2024-05-20 14:23:00" | head -50
- 注意系统时间是否漂移：
timedatectl status查System clock synchronized:是否为yes；若否，journalctl的时间戳不可信
日志本身不会说“哪里错了”，它只说“当时发生了什么”。真正难的不是读日志，而是把 _PID、_COMM、MESSAGE、系统资源状态、服务依赖关系这四条线，在正确的时间点上拧成一股诊断逻辑——而这一步，没有任何工具能自动帮你完成。
