别再乱看日志了！Linux 日志分析实战指南，从排查到优化一步到位

/var/log/messages：系统通用日志，记录内核消息、系统服务运行状态（如Nginx、MySQL启动/停止）、硬件故障等，是最常用的排查入口；
/var/log/auth.log（Debian/Ubuntu）、**/var/log/secure**（CentOS/RHEL）：认证日志，记录用户登录（ssh、su、sudo）、权限变更等信息，排查暴力破解、权限问题必查；
/var/log/boot.log：系统启动日志，记录开机过程中内核初始化、服务启动顺序及故障，解决开机启动失败问题核心依据；
/var/log/cron：定时任务日志，记录crontab任务的执行时间、结果，排查定时任务不执行、执行失败问题；
应用日志：如Nginx（/var/log/nginx/access.log/error.log）、MySQL（/var/lib/mysql/主机名.err），需结合应用配置确认路径，定位应用层故障。

2. 日志管理工具：rsyslog与journalctl

目前主流Linux发行版均使用rsyslog管理日志，支持日志分类存储、远程转发；而systemd系统（CentOS 7+、Ubuntu 16+）自带journalctl工具，可查看系统与服务的实时日志，无需依赖传统日志文件。如，journalctl -f -u nginx精准查看Nginx的日志。

关键区别：rsyslog日志默认持久化到磁盘，journalctl日志默认存于内存（重启丢失），若需持久化，需配置/etc/systemd/journald.conf中Storage=persistent并重启journald服务。

二、实战：日志分析核心命令与场景

掌握基础命令组合，能大幅提升日志分析效率。以下是高频场景的命令实战，直接套用即可。

1. 基础日志查询命令

按时间过滤：使用grep匹配时间格式，如查询2025-12-29当天的系统错误： grep "2025-12-29" /var/log/messages | grep -i error（-i忽略大小写）；
实时监控日志：排查实时发生的故障（如服务崩溃、用户登录异常），用tail -f： tail -f /var/log/secure（监控登录认证）、journalctl -u nginx -f（实时监控nginx服务日志）；
多条件过滤：结合awk、sed精准匹配，如查询nginx日志中状态码为500的请求： awk '$9=="500"' /var/log/nginx/access.log（$9对应access.log中状态码字段）；
统计高频错误：用sort、uniq -c统计重复错误，定位核心问题： grep -i error /var/log/messages | awk '{print $0}' | sort | uniq -c | sort -nr（按错误出现次数降序排列）。

2. 典型故障排查场景

场景1：ssh登录失败排查

现象：用户反馈ssh无法登录，提示“Permission denied”。
排查步骤：

查看认证日志：grep "sshd" /var/log/secure；
关键错误分析：

若出现“Invalid user xxx”：存在无效用户登录尝试，需检查是否有暴力破解，可结合fail2ban封禁IP；
若出现“Permission denied, please try again”：密码错误或密钥认证失败，检查用户密码、authorized_keys权限（需为600）；
若出现“Too many authentication failures”：认证尝试次数过多被拒绝，可调整sshd_config中MaxAuthTries参数。

场景2：服务启动失败（以Nginx为例）

现象：执行systemctl start nginx提示启动失败。

排查步骤：

查看服务日志（最直接）：journalctl -u nginx -xe（-xe显示详细错误及相关依赖）；
若提示“bind() to 0.0.0.0:80 failed (98: Address already in use)”：80端口被占用，查询占用进程：netstat -tulnp | grep :80，终止占用进程或修改Nginx端口；
若提示“invalid number of arguments in "listen" directive”：配置文件语法错误，执行nginx -t检查配置，修复后重启。

三、进阶：日志分析与性能优化结合

日志不仅能排查故障，还能通过分析资源使用、请求量等数据，定位性能瓶颈。

1. 从日志看系统性能瓶颈

查看/var/log/messages中是否有以下关键字，对应性能问题：

“Out of memory”：内存溢出，需检查进程内存占用（top、free -h），优化应用内存配置或升级硬件；
“CPU soft lockup”：CPU占用过高导致系统无响应，用top -H查看线程占用，定位高负载进程；
“disk full”：盘空间不足，结合df -h、du -sh *清理大日志文件或无用数据。

2. 应用日志性能优化实战（Nginx为例）

问题：高并发场景下，大量access.log写入导致磁盘IO升高，影响服务响应速度。优化方案：

日志切割：使用logrotate定期切割日志，避免单日志文件过大，配置示例（/etc/logrotate.d/nginx）：

/var/log/nginx/*.log {
        daily
        rotate 7
        missingok
        compress
        delaycompress
        notifempty
        create 0640 www-data www-data
        sharedscripts
        postrotate
                if [ -f /var/run/nginx.pid ]; then
                        kill -USR1 cat /var/run/nginx.pid
                fi
        endscript
}

关闭无用日志：对静态资源（js、css、图片）的请求，可在Nginx配置中关闭日志记录：

location ~* \.(js|css|png)$ {
    access_log off;
}

远程日志转发：将日志转发至ELK、Promtail等日志分析平台，减少本地磁盘IO，同时支持海量日志检索与可视化。

四、运维日志分析避坑指南

避免直接修改日志文件：若需清理日志，用echo "" > 日志文件而非rm删除，防止服务继续写入时因文件句柄丢失导致日志无法生成；

日志持久化配置：生产环境务必开启journalctl日志持久化，避免重启后日志丢失，影响故障追溯；

敏感信息脱敏：认证日志、应用日志中可能包含密码、Token等敏感信息，需通过rsyslog或日志平台进行脱敏处理，避免泄露；

定期备份日志：重要业务日志建议备份至对象存储（如OSS、S3），保留至少30天，满足合规要求且便于后续问题追溯。

日志分析是运维工程师的核心技能，关键在于“精准定位场景+熟练运用命令+结合业务优化”。掌握以上方法，能解决80%的日常故障与性能问题。后续大家在日志分析中遇到具体问题，欢迎在评论区留言讨论。

关注我，持续输出运维技术干货与实战经验，让运维工作更高效！

别再乱看日志了！Linux 日志分析实战指南，从排查到优化一步到位