Linux中用tail -f配合grep -q --max-count=1检测日志中Ready关键字可判断服务就绪，需结合timeout防挂起，并校验文件存在性、读权限，支持journalctl替代、多关键词匹配及CI/CD集成。
在 Linux 中，用 Shell 脚本检测应用日志里是否出现 Ready 关键字，是判断服务部署就绪的常用方式。核心思路是：持续读取日志（尤其是追加内容），匹配到关键字后退出并返回成功状态，超时则报错。
使用 tail -f 配合 grep 实时监听
这是最轻量、最常用的方法，适合日志持续写入的场景（如容器启动、Spring Boot 启动日志）：
- tail -f 实时跟踪日志末尾新增内容，避免反复打开文件
- grep -q "Ready" 静默匹配，只关心是否找到，不输出内容
- --max-count=1 确保匹配一次即退出，防止重复触发
- 配合 timeout 命令限制最长等待时间，避免无限挂起
示例脚本片段：
#!/bin/bash LOG_FILE="/var/log/myapp/app.log" TIMEOUT=300 # 最多等5分钟 <p>if timeout $TIMEOUT tail -f "$LOG_FILE" | grep -q --max-count=1 "Ready"; then echo "✅ 应用已就绪" exit 0 else echo "❌ 超时未检测到 Ready，部署可能失败" exit 1 fi
处理日志尚未生成或权限不足的情况
生产环境中，日志路径可能不存在、为空，或当前用户无读取权限，需提前校验：
- 用 [ -f "$LOG_FILE" ] 检查文件是否存在且为普通文件
- 用 [ -r "$LOG_FILE" ] 确认有读取权限
- 若日志由 systemd 管理（如 journalctl），改用 journalctl -u myapp.service -f 替代 tail
- 可加 sleep 1 避免刚启动时日志还没落地就开监听
增强健壮性：支持多关键词与上下文判断
单靠 “Ready” 可能误判（比如日志中历史残留或调试语句）。建议组合条件：
- 匹配带时间戳的行，例如 grep -q "INFO.*Ready" 或 grep -E "READY|Started.*application"
- 用 awk 提取最近 N 行再判断：tail -n 100 "$LOG_FILE" | awk '/Ready/ && /started/ {found=1} END{exit !found}'
- 记录首次匹配时间，避免因日志轮转导致重复匹配
集成到部署流程（如 CI/CD 或 systemd 服务）
该检测逻辑常嵌入自动化流程：
- 在 systemd service 中，用 ExecStartPost= 调用检测脚本，失败则自动 restart
- CI/CD（如 GitHub Actions）中，作为部署后的验证步骤，失败则标记 job 失败
- 搭配重试机制更稳妥，例如循环 3 次，每次间隔 10 秒：for i in {1..3}; do ... || sleep 10; done
