journalctl的--since/--until是基于二进制索引的时间戳跳转查询，毫秒级响应，非文本扫描；配合服务单元、优先级和启动上下文可实现TB级日志秒级精准定位。

在 TB 级日志中靠 tail -f 或全文 grep 查故障，就像用放大镜找流星——耗时、漏关键、还容易卡死。journalctl 的 --since 和 --until 不是“加个时间条件”那么简单，它是基于二进制索引的**时间戳跳转查询**，只要日志已持久化，无论总量多大，定位都是毫秒级响应。

时间参数本质是索引寻址，不是文本扫描

journald 把每条日志的时间戳作为结构化元数据写入索引（类似数据库主键），--since 并非从头遍历日志文件，而是直接定位到第一个不早于该时间戳的索引位置，再按需读取后续条目。这意味着：

• 查“10分钟前至今”，不管日志总大小是 100MB 还是 2TB，响应时间基本一致；
• 即使日志存了半年，只要启用了持久化（Storage=persistent），--since "2025-12-01" 依然秒出结果；
• 避免使用模糊时间如 today 或 yesterday 做高频排查——它们每次都要解析当前日期，不如固定格式稳定。

精准缩小范围：组合过滤比单靠时间更高效

光靠时间范围，在 TB 日志里仍可能返回数万行。真正“秒级定位”，要叠加服务单元和优先级：

• 先锁定服务：journalctl -u nginx.service --since "2026-05-19 10:30:00" --until "2026-05-19 10:35:00"；
• 再聚焦错误：journalctl -u nginx.service -p err --since "10 min ago"；
• 若怀疑某次重启引发问题，加 -b（本次启动）或 -b -1（上一次启动）进一步隔离上下文。

实战技巧：让时间表达式真正可控

别依赖自然语言解析，尤其在线上环境。推荐以下写法：

• 用绝对时间戳（带秒）：--since "2026-05-19 10:42:15"，避免时区/夏令时歧义；
• 相对时间慎用 now，改用 "10 min ago" 更可靠（journald 解析更成熟）；
• 跨时段排查时，--since "2 hours ago" --until "1 hour ago" 比两次命令更准，避免中间遗漏；
• 配合 --no-pager 和管道，例如：journalctl -u app.service --since "5 min ago" -p err | head -n 20，防止分页器拖慢输出。

前置确认：确保你能查到这些日志

再快的查询也依赖日志存在。TB 级场景下务必检查：

• 是否启用持久化：grep "^Storage=" /etc/systemd/journald.conf，应为 Storage=persistent；
• 日志目录空间：du -sh /var/log/journal/*，避免因磁盘满导致旧日志被自动轮删；
• 最大保留策略：SystemMaxUse= 和 MaxRetentionSec= 在配置中是否合理（例如设为 MaxRetentionSec=3month）。