Linux 服务日志没有统一固定结构，但主流系统（尤其是使用 systemd 的发行版）普遍采用标准化格式，核心由 时间戳、服务名、进程ID、日志级别、消息主体 构成，理解这个骨架能快速定位问题。
标准 journalctl 日志字段含义
运行 journalctl -u nginx.service -n 5 查看最近 5 条 Nginx 日志，典型行如下：
- Jun 12 10:24:31：系统本地时间（非 ISO 格式），由 journald 自动添加
- server01：主机名，便于多机环境识别来源
- nginx[1248]：服务名 + 方括号内主进程 PID，可关联 /proc/1248/ 查状态
- : 2024/06/12...：服务自身输出的时间戳和内容，journald 不解析、仅透传
传统 syslog 日志（如 /var/log/syslog）的常见变体
未启用 systemd-journald 或兼容老服务时，日志常走 rsyslog 或 syslog-ng，格式更松散但仍有规律：
Jun 12 10:24:31 server01 sshd[987]: Failed password for invalid user admin from 192.168.1.10 port 54322 ssh2- 前 3 字段（月 日 时:分:秒）固定为 syslog 时间格式，无年份（需结合文件名或上下文推断）
-
server01 后紧跟服务名与 PID，如
sshd[987] - 冒号后为原始消息，不含结构化字段，需靠关键词（如
Failed password、Connection closed）人工判断类型
服务自定义日志（如 /var/log/nginx/access.log）的字段控制
Web 服务器、数据库等常绕过系统日志，直接写入独立文件，格式完全由服务配置决定：
- Nginx 的
log_format指令定义 access.log 字段顺序，例如：$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent - PostgreSQL 的
log_line_prefix可插入 %t（时间）、%u（用户）、%d（数据库）等占位符 - 关键点：这类日志不带系统级 PID 和主机名，需从路径（
/var/log/nginx/）和文件名反推服务身份
快速识别日志类型的实操技巧
- 用
head -n 1 /var/log/messages看首行是否有[PID]或:分隔的固定字段组 - 运行
ls -lt /var/log/ | head -5观察活跃日志文件名，含.log且无.journal后缀的多为传统或服务自定义日志 - 对 systemd 服务，优先用
journalctl -u servicename；对非 systemd 服务（如源码编译的程序），直接查其配置指定的日志路径
