journalctl 排查微服务心跳超时需聚焦时间点、服务单元和异常模式：先确认 unit 名称（如 user-service.service、nacos.service），再用 -u、--since/--until、-p err..warning 限定范围，结合 -g 搜索 heartbeat/health/register 等关键词，并交叉验证启动周期与系统资源事件。
排查微服务心跳超时，关键不是“翻日志”，而是用 journalctl 精准定位时间点、服务单元和异常模式。心跳超时通常表现为服务注册失败、健康检查被拒绝、或客户端反复重连——这些都会在服务自身、注册中心（如 Nacos、Consul）、网关（如 Spring Cloud Gateway、Nginx Proxy Manager）或系统网络组件的日志中留下痕迹。
确认目标服务与关联组件的 unit 名称
微服务本身一般以自定义名运行（如 user-service.service），但心跳行为往往依赖外部组件。先查清实际运行单元：
- 运行 systemctl list-units --type=service | grep -E "(nacos|consul|eureka|gateway|nginx|npm)" 找注册中心或网关服务名
- 查你的微服务：例如 systemctl list-units --all | grep "user-service"，确认是否为 user-service.service（注意 .service 后缀）
- 若用 Docker 容器化但由 systemd 管理（如 docker.service 或自定义 wrapper），也要纳入排查范围
聚焦超时发生时段，按优先级过滤错误日志
心跳超时极少孤立出现，常伴随连接拒绝、DNS 解析失败、SSL 握手超时或 HTTP 503/408 响应。优先锁定错误和警告：
- 查指定服务在故障窗口内的高优日志：journalctl -u user-service.service --since "2026-09-15 14:00" --until "2026-09-15 14:30" -p err..warning
- 同时查注册中心（如 Nacos）同一时段日志：journalctl -u nacos.service --since "2026-09-15 14:00" --until "2026-09-15 14:30" -p err
- 加 --output=short-iso --show-cursor 让时间戳更清晰，便于与监控告警对齐
结合关键词与实时跟踪验证行为模式
单纯看错误不够，要确认“心跳请求是否发出、发往何处、收到什么响应”：
- 搜索典型心跳关键词：journalctl -u user-service.service -g "heartbeat\|health\|ping\|register\|deregister" --since "10 minutes ago"
- 若怀疑网络层问题，追查内核或代理日志：journalctl -u nginx-proxy-manager.service -g "timeout\|upstream\|504\|connect failed" -f
- 实时观察新心跳是否恢复：journalctl -u user-service.service -f -o short-iso | grep -i "heartbeat\|health"
交叉验证启动周期与系统资源瓶颈
心跳中断有时源于服务重启、OOM Killer 杀进程或磁盘满导致日志写入失败：
- 查该服务本次启动全过程：journalctl -u user-service.service -b，看是否有 “Started” 后立刻报错或崩溃
- 查系统级资源事件：journalctl -b -p err -g "killed process\|Out of memory\|No space left"
- 确认日志是否持久化：ls /var/log/journal/；若为空且未配置 Storage=persistent，重启后旧日志已丢失，需立即补配置
