Linux服务日志定位需先判断是否由systemd管理：systemd服务用journalctl命令查journald日志，如journalctl -u nginx；非systemd或自定义路径则查/var/log/下对应文件，如/var/log/nginx/error.log，并可通过systemctl status、lsof、配置文件搜索等命令实操验证。
Linux服务日志没有统一固定位置，取决于服务管理方式和发行版类型。关键不是“找全所有日志”，而是“按需精准定位”——先判断服务是否由 systemd 管理，再决定查文本文件还是 journal 日志。
systemd 服务优先用 journalctl
现代主流发行版（Ubuntu 16.04+、CentOS 7+、Debian 9+）默认使用 systemd，服务日志统一由 journald 收集，比翻文本日志更实时、更完整：
- 查看某服务最近日志：`journalctl -u nginx`（替换 nginx 为实际服务名，如 sshd、mysql、docker）
- 只看错误级别及以上：`journalctl -u nginx -p err`（-p err 表示 priority error，含 err/warning/crit/alert/emerg）
- 查本次开机后的报错：`journalctl -b -p err`（-b 表示 this boot）
- 实时跟踪新日志：`journalctl -u nginx -f`（Ctrl+C 退出）
-
确保日志持久化（重启不丢）：创建存储目录并重启 journald：
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
非 systemd 或自定义日志路径查 /var/log/
若服务未被 systemd 管理，或明确配置了日志路径，则日志多落在 /var/log/ 下，常见规律如下：
-
通用系统事件：Ubuntu/Debian 看
/var/log/syslog，RHEL/CentOS 看/var/log/messages -
登录与权限操作：Ubuntu/Debian 查
/var/log/auth.log，RHEL/CentOS 查/var/log/secure -
Web 服务：Nginx 默认在
/var/log/nginx/error.log，Apache 在/var/log/apache2/error.log -
数据库：MySQL 错误日志通常为
/var/log/mysql/error.log或通过journalctl -u mysql查 -
Java/Spring Boot 应用：常配置在
/var/log/myapp/app.log或启动脚本中指定的路径（如 nohup 输出）
快速确认日志位置的实操方法
不依赖记忆，用命令现场验证：
- 查服务是否由 systemd 管理：`systemctl status nginx` —— 若显示 “Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)”，就该用 journalctl
- 查进程打开的日志文件：`sudo lsof -p $(pgrep nginx) | grep log`（适用于正在运行的服务）
-
查配置文件中指定的日志路径：Nginx 查
grep "error_log" /etc/nginx/nginx.conf；MySQL 查mysqld --verbose --help 2>/dev/null | grep "log-error" - 全局搜索 .log 文件：`find /var/log -name "*nginx*" -o -name "*error*.log" 2>/dev/null`
读懂日志里的关键线索
看到一行报错只是开始，真正有用的信息藏在上下文里：
- 时间戳 + 进程名/线程ID：确认是不是当前问题发生时段、哪个实例出错
- 错误前后的几行：用 `grep -C 2 "Connection refused" /var/log/messages` 查前后两行，常能发现端口冲突、依赖服务未启动
- 高频重复模式：比如同一 IP 多次 “Failed password”，说明暴力破解；连续 “OOM killed process”，指向内存不足
- 状态码与返回值：Web 日志中 “404” 是资源不存在，“502 Bad Gateway” 指上游服务不可达，“Connection reset by peer” 常是客户端异常断连
