1. Linux 日志查看的基础
日志系统的架构与数据源
在运维实战中，理解日志系统的架构是第一步。Linux 的日志来源包括内核环形缓冲区、系统守护进程、以及各类服务产生的日志。内核日志通过 dmesg、/proc/kmsg 等渠道进入系统日志栈，而用户态的日志通常由 rsyslog、syslog-ng、以及 systemd 的 journal 共同维护。掌握这些来源有助于定位问题的起点。
为了快速理解日志来源的关系，可以先看一个简单的对比：本地日志文件（如 /var/log/messages、/var/log/syslog）通常以文本形式存在，便于人工阅读；而 systemd 日志（journal）以二进制格式存储，支持高效的筛选与结构化输出。下面的代码演示了常用的本地与内核日志查看方式：
dmesg | tail -n 100
tail -n 200 /var/log/syslog本地与远程日志的区别
本地日志是指保存在服务器本机的日志文件，便于离线查看与归档；远程日志则通过集中日志服务器将日志汇聚在一起，便于跨主机统一分析。理解两者的区别，有助于设计有效的日志策略与排错流程。集中化日志通常能显著提高检索效率和问题溯源能力。
在日常运维中，可以通过远程日志实现统一告警与检索。以下命令用于快速查看本地日志的滚动内容，确保你能在任何时刻获取最近的日志数据：
tail -n 200 /var/log/syslog2. journalctl 入门与核心用法
基本语法与对象
journalctl 是 systemd 日志体系的核心工具，适用于查看 系统日志、单元（unit）的输出以及按引导加载的日志。掌握其基本语法，可以快速定位问题的时间线与事件源。单位、引导、消息级别是其核心对象。
初学者可以先执行最简单的查看命令，以感受日志的结构与输出格式。基本语法的理解，是后续进阶筛选的基础。
journalctl常用选项
在实际运维场景中，常用选项如 -u（按服务/单元过滤）、-b（按本次启动过滤）、-p（按优先级过滤）、-f（跟随新日志）等，非常实用。结合这些选项，能快速聚焦到问题窗口内的关键信息。
示例中，使用不同选项组合进行日志提取，帮助你迅速定位失败点或异常点。以下命令展示了几种常见场景的用法：
journalctl -u nginx.service
journalctl -b -p err时间范围筛选
生产环境的问题往往发生在最近一段时间，因此掌握时间筛选能力非常重要。通过 --since、--until 等参数，可以限定日志的时间范围，提升排错效率。
为了获得更细粒度的历史片段，可以将时间区间与输出格式结合使用，如输出 JSON，便于后续自动化分析与二次加工：
journalctl --since "1 hour ago" --until "now"
journalctl -o json | head -n 503. 结合 grep/awk 等工具进行日志分析
关键词筛选与高亮
在海量日志中筛选关键字，是最常见的分析手段之一。通过将 journalctl 与文本工具组合，可以快速定位错误、告警或特定事件。关键词过滤是第一步。
结合管道与正则，能实现对特定错误类型的快速聚焦，提升排错的响应速度。
journalctl -u httpd.service | grep -i "error"结构化输出与字段提取
使用 -o json 将日志输出为结构化的 JSON，随后借助 jq 等工具提取字段（如 MESSAGE、_PID），可以实现跨主机的跨字段分析。
结构化输出使得后续的统计、聚合和可视化变得非常高效。
journalctl -o json | jq -r '.MESSAGE, ._PID'日志轮转与持久化存储策略
为了避免日志无限膨胀，需要对 journald 的存储策略进行配置，常见做法是开启 Storage=persistent，并设置合理的 SystemMaxUse、SystemMaxFileSize 等参数。合适的轮转策略能确保历史日志保留与磁盘使用之间的平衡。
配置完成后，记得重启 journald 服务以使改动生效，并通过 systemctl status systemd-journald 观察运行状态。
sudo bash -c 'sed -i "s/^#?Storage=.*/Storage=persistent/" /etc/systemd/journald.conf'
sudo systemctl restart systemd-journald4. 常见场景下的日志排错流程
服务启动失败排错流程
在服务启动失败时，最直接的排错路径是查看 unit 状态与最近的日志输出。通过 systemctl status 与 journalctl -u 能迅速定位失败点、依赖关系及启动顺序中的异常。
完整的排错流程通常包括：检查服务状态、重点查看最近启动周期的日志、对比配置变更记录、并结合系统资源日志判断是否因资源约束导致启动失败。以下命令帮助你快速进入排错场景：
systemctl status nginx.service
journalctl -u nginx.service --since "5 minutes ago"性能与资源相关排错
性能相关的问题常伴随资源告警、慢响应、吞吐下降等表现。此时需要从日志中筛选 告警级别、以及与资源相关的事件，例如 OOM、内存不足、CPU 限制等。结合内核日志和服务日志，可以全景定位瓶颈。
排错时，关注 警告级别日志、并结合系统级日志与应用日志进行横向对比。下面的命令可用于快速查看近期的警告信息以及资源相关的日志：
journalctl -p warning -b
dmesg | grep -i -E "oom|memory|cpu"