linux Command
journalctl 查看服务日志命令
journalctl 查看 systemd 服务日志的常用命令，journalctl -u <service> -n 200 --no-pager 看近期错误，-f 实时跟踪，--since/--until 按时间窗过滤，-p warning..alert 按优先级过滤，--disk-usage 查看日志占用与 vacuum 清理。
排查 systemd 服务优先用 journalctl -u 服务名 -n 200 --no-pager，再按时间窗口和优先级缩小范围。
Scenario
什么时候用这组命令
这组命令适合在处理“journalctl 查看服务日志命令”时作为第一轮检查模板。使用时先替换占位符，再在目标机器或目标 namespace 中执行，避免在错误环境里得到误导结论。
Input
你需要先准备什么
- 先确定故障资源：CPU、内存、磁盘、网络、权限、文件句柄还是 systemd 生命周期。
- 区分当前状态和故障发生时状态，事故恢复后 free/top 可能已经看不出根因。
- 任何清理或 kill 操作前先记录 PID、命令行、日志和影响范围。
Risk Notes
执行风险
- 生产上不要在来源未确认时 rm -rf 大目录，应先确认目录用途和影响范围。
- kill 进程前先确认它属于哪个服务、是否会触发级联重启，优先使用 SIGTERM 而非 SIGKILL。
- 不要忽略 dmesg 中的 OOM Killer 记录，它往往是应用内存泄漏或配置不当的早期信号。
Commands
命令详解
命令 1: 查看 systemd 日志
用于读取 systemd 或内核在故障时间附近记录的真实错误，比 status 摘要更完整。重点看时间、退出码、权限、路径和依赖失败。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
journalctl -u nginx -n 200 --no-pager命令 2: 查看 systemd 日志
用于读取 systemd 或内核在故障时间附近记录的真实错误，比 status 摘要更完整。重点看时间、退出码、权限、路径和依赖失败。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
journalctl -u nginx -f命令 3: 查看 systemd 日志
用于读取 systemd 或内核在故障时间附近记录的真实错误，比 status 摘要更完整。重点看时间、退出码、权限、路径和依赖失败。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
journalctl -u nginx --since "1 hour ago"命令 4: 查看 systemd 日志
用于读取 systemd 或内核在故障时间附近记录的真实错误，比 status 摘要更完整。重点看时间、退出码、权限、路径和依赖失败。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
journalctl -p warning..alert --since today命令 5: 查看 systemd 日志
用于读取 systemd 或内核在故障时间附近记录的真实错误，比 status 摘要更完整。重点看时间、退出码、权限、路径和依赖失败。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
journalctl --disk-usageWorkflow
建议执行顺序
按顺序执行，不要跳过确认类命令
先用只读命令确认状态，再执行会改变状态的命令。排查 systemd 服务优先用 journalctl -u 服务名 -n 200 --no-pager，再按时间窗口和优先级缩小范围。
- 先查看最近 200 行，确认错误关键词。
- 需要观察复现过程时使用 -f 实时跟踪。
- 问题发生时间明确时加 --since/--until。
- 噪音过多时按 priority 过滤 warning 以上日志。
- 日志占用过大时先看 --disk-usage，再配置保留策略。
journalctl -u nginx -n 200 --no-pager
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"把命令输出变成结论
命令本身不是结论。每次执行后要回答：目标是否存在、状态是否异常、异常是否能解释用户看到的现象。
- 记录关键字段，而不是整屏复制
- 把正常路径和异常路径输出对比
- 输出为空也要解释：是确实没有，还是权限/过滤条件不对
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"
journalctl -p warning..alert --since today执行前替换占位符并控制影响范围
包含 <service>、<pod>、<namespace>、<pid>、<container> 的命令必须先替换。涉及 reload、restart、KILL、vacuum、prune 的命令要确认影响范围。
- 优先在测试环境或只读模式验证
- 生产执行前保留回滚路径
- 把最终可用命令写入工单或 runbook
journalctl -p warning..alert --since today
journalctl --disk-usageVerification
怎么判断命令有效
- 命令已在正确机器、正确用户、正确 namespace 或正确仓库下执行。
- 输出能支撑明确判断：正常、异常、权限不足、目标不存在或需要下一跳排查。
- 对有副作用的命令，已确认执行窗口、影响范围和回滚方式。
Prevention
沉淀到日常流程
- 为关键服务配置日志轮转、资源限制和基础监控，避免等到用户报障才发现问题。
- 把 systemd unit、timer 和环境文件纳入版本管理，确保所有变更可追溯可回滚。
- 对清理动作保留可回滚路径，优先移动/截断/轮转，不盲删。
- 建立系统资源基线监控，一旦 CPU、内存、磁盘或文件句柄超过阈值即可自动告警。
常见问题
为什么 journalctl 没有历史日志？
可能未启用持久化日志，或日志被 vacuum 清理。检查 /var/log/journal 和 journald 配置。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- journalctl 查看服务日志
- systemd 日志查看命令
- journalctl -u 服务名
- journalctl --since 时间过滤
- systemctl status 查日志
- journalctl -f 实时日志
Need More Help
这组命令还不够贴合你的场景？
把你的系统环境、目标操作和报错贴过来，我会优先补充更具体的命令模板。