查看日志与健康摘要

目标

读取应用的运行时日志，并通过健康摘要一次性了解部署、运行时、代理和访问地址的综合状态。

适用场景

应用启动失败或行为异常，需要看它自己打印了什么。
需要判断”接下来该重试、修复配置还是回滚”。

前置条件

至少有一次部署尝试（成功或失败均可）。

输入与默认值

输入	说明	默认值
`--tail`	只看最近 N 行日志	全部（建议显式指定，避免输出过长）
`--checks`	健康检查时附带详细检查项	关闭
`--public-access-probe`	健康检查时附带一次公网访问探测	关闭
`--runtime-probe`	在 live 模式下检查当前 Docker 运行时实例	关闭

CLI 操作步骤

# 读取最近 100 行运行时日志
appaloft resource logs res_web --tail 100

# 读取 live 健康摘要，并核对当前运行时与公网访问
appaloft resource health res_web --live --checks --runtime-probe --public-access-probe

HTTP/API 操作步骤

GET /api/resources/res_web/runtime-logs?tailLines=100
GET /api/resources/res_web/health?mode=live&includeChecks=true&includeRuntimeProbe=true&includePublicAccessProbe=true

预期输出与状态

运行时日志来自应用进程的 stdout/stderr，适合回答：应用是否启动、启动命令是否执行、监听端口是否正确、配置/环境变量是否缺失、应用代码是否抛出运行时异常。日志不适合判断域名所有权或证书就绪——那些应该看访问相关状态。

健康摘要把以下信息合并在一次调用中返回：最近部署状态和失败阶段、运行时进程状态、健康检查策略和最近检查结果、网络 Profile 和代理目标、生成访问地址状态、自定义域名和 TLS 就绪摘要。

资源详情页会在 live 刷新时检查当前运行时。即使最近一次部署是 succeeded，如果 Docker 明确确认当前运行时所属的容器已不存在，当前资源状态也会显示为 stopped。失败的替换部署仍是历史记录，不会取代仍在提供服务的较早成功运行时。如果只是 SSH、Docker daemon 或探测超时导致无法观察，状态保持 unknown 并附带 resource_runtime_inspection_failed；Appaloft 不会把“看不到”误报成“已停止”。项目列表和侧栏使用紧凑健康状态，不会为每个资源各启动一次远程运行时探测。

验证

对照下表判断根因：

现象	恢复方向
日志显示端口冲突	修正网络 Profile或启动命令
日志显示缺少环境变量	修正配置优先级中设置的变量后重新部署
健康检查超时	调整健康检查路径、超时时间、重试次数或启动等待期
最近部署成功，但当前状态为 stopped	当前运行时实例已经不存在；检查日志与部署时间线，然后按恢复就绪状态选择 Redeploy、Retry 或 Rollback
当前状态为 unknown，且错误是 `resource_runtime_inspection_failed`	先恢复 SSH/Docker 可观测性并刷新；不要仅凭这次探测失败判断容器已停止
应用健康但生成访问地址失败	查看代理就绪和访问状态

回滚 / 恢复

如果只是想让当前运行时重启一下（不会重新构建、不会刷新配置/密钥/依赖绑定），使用运行时控制：

appaloft resource runtime restart res_web

Restart 不等于 Redeploy——如果你修改了源码、环境变量、密钥、Runtime/Network/Health Profile、存储挂载或依赖绑定，必须使用 Redeploy、Retry 或 Rollback（见回滚与恢复），Restart 不会应用这些变更。

如果 Start 操作被阻塞（例如运行时元数据缺失或过期、资源已归档、存在并发部署），健康摘要会给出被阻塞的原因；此时应该改用 Redeploy 让最新配置形成一次新部署，而不是反复重试 Start。