跳到主要内容

APPLICATION & RUNTIME · LAYER 03

应用与运行时故障诊断

从进程状态、错误日志、资源曲线和最小复现定位应用崩溃、内存异常、事件循环阻塞与请求堆积,避免以重启代替诊断。

本层已发布
2 篇
内容标准
隔离复现 · 证据复核
广告状态
栏目页不加载广告

FIRST-RESPONSE GUIDE

本层负责什么

应用与运行时层关注进程是否存活、是否还能及时处理请求,以及代码和依赖在什么条件下失败。崩溃、内存耗尽、线程池饱和、事件循环阻塞和外部依赖变慢都可能表现为接口超时。首先要保存失败现场并建立时间关联,再用最小负载验证具体瓶颈。

常见症状

这些现象用于判断排查入口,不代表已经确定根因。先记录原始错误和时间,再执行首轮检查。

  • 进程退出、被信号终止,或启动后很快再次失败
  • 健康接口超时,但 CPU、线程或事件循环出现持续阻塞
  • 内存持续增长、触发 OOM,或垃圾回收停顿显著增加
  • 只有特定接口、输入或依赖调用导致错误率和延迟升高

首轮检查清单

按顺序执行并保存输出。每一步只改变一个变量,避免让恢复动作覆盖真正的失败证据。

  1. 保存失败现场先记录退出码、信号、异常栈、进程启动参数和失败前后的应用日志。
  2. 关联资源时间线对齐 CPU、内存、线程/句柄、事件循环延迟与请求错误率,确认先后关系。
  3. 缩小触发条件按接口、输入、版本和依赖逐步收敛,在隔离环境复现而不是直接在线试错。
  4. 验证恢复标准修复后同时检查错误率、延迟和进程资源稳定性,避免只以“进程在运行”作为结论。

操作边界

采集日志、状态和低开销指标通常可在线执行;堆转储、跟踪器和压力测试可能显著增加负载。未评估磁盘、性能和敏感数据风险前,不应直接在生产进程开启高开销诊断。

何时升级或切换层级

当证据指向其他系统边界,立即带着时间、环境和原始输出交接,避免在当前层重复执行无关操作。

  • 进程因容器限制或调度策略被终止:转入容器与编排层。
  • 阻塞发生在数据库或缓存调用:携带调用时间线转入数据层。
  • 系统级内存、句柄或磁盘耗尽影响多个服务:转入系统与安全层。

PUBLISHED & VERIFIED

该层已发布的验证文章

这里只列出已发布且通过 V2CE 证据门禁的文章;草稿和未验证内容不会进入列表。

2 条可执行路径
03
已验证 最后复核 2026-08-06

Node.js 进程还在,健康检查为什么超时?定位事件循环阻塞

用并发健康请求和事件循环延迟证明主线程被 CPU 工作占用,再评估分片、输入上限与 Worker Thread 池。

适用环境
Node.js 22.20.0 Alpine / Worker Threads / Docker 24.0.7
验证耗时
约 12 分钟
风险边界
指标和短时 profile 为低风险;Worker 池必须限制并发、队列、输入和超时,回滚前安全处理在途写任务
查看证据与诊断步骤 →
03
已验证 最后复核 2026-08-03

systemd 提示 Start request repeated too quickly:真正的退出原因在哪里

先保存 ExecMainStatus、NRestarts 和首次失败日志,再核对生效 unit、服务身份和环境;修复根因后才…

适用环境
systemd 247.3 / Debian GNU/Linux 11 / Linux cgroup v2
验证耗时
约 10 分钟
风险边界
状态与日志读取为低风险;停止或重启生产服务前先摘流,unit 变更必须备份并通过 systemd-analyze verify
查看证据与诊断步骤 →

NOT SURE YET?

仍无法确定故障层级?

回到诊断地图,从用户看到的第一个异常开始;按“解析 → 连接 → 网关 → 应用 → 数据 → 系统”的顺序保存证据。

返回六层诊断地图 →