CYBERSWAT / 开发部自由练习 · v0.4.1

U10 · 失败一次，与一直失败，是两回事

v0.4 · 先修：手册 12、15、22–25；工作台。产品参考：Uptime Kuma。本节新做单目标实验，不重建整套监控产品。

一个本地服务今天能打开，并不代表下一次也能打开。我们定期检查自己建立的目标，记录每次结果，再观察从正常到失败、从失败到恢复的变化。通知先写本地日志，不接短信、邮件或真实运维系统。

动手路线：每一步都有文件和结果

先完成 统一启动与恢复手册 的首次准备。以下命令均在自己的练习根目录执行；原文中的 api/web/desktop 概念对应本节列出的现成文件，不需要猜测如何搭空项目。

  1. 打开 u10/starter/model.ts，按 classify → recordSample 的顺序逐个实现。下面第1节起解释规则；每完成一个函数就重跑样例/测试。
  2. 执行以下三条，分别核对样例、行为和类型。未完成的 TODO 应失败，全部实现后测试应为 fail 0：
node tools/try.mjs u10
node tools/check.mjs u10
npm run check

  1. 打开 runtime/src/u10.ts、runtime/web/u10.js，找到对自己规则函数的调用。先用一句话记录输入从哪里来、结果写到哪里；读不懂的语法回到本节先修对应章节。

  2. 先运行 node tools/lab.mjs db up，等待迁移完成。另开终端运行 node tools/lab.mjs target 并保持打开。构建并启动自己的作品：

node tools/build-app.mjs u10
node tools/lab.mjs start u10
  1. 实际操作：启动模拟目标，点开始监测、停止监测；停止超过3秒显示数据过期。接口验收切换成功、失败与超时，状态连续失败不反复记录变化。

在第二个终端运行 node tools/probe.mjs u10。脚本会添加合成数据并报告每组检查；不清空自己的数据。 首次通过后停止并重新启动服务，再运行 node tools/probe.mjs u10 --resume；数据库单元同时按统一手册重启数据库。

  1. 解释与再做一次：循环为什么在本轮结束后再安排下一轮？最后一次 up 为什么不能永久显示为当前正常？ 在自己的 LEARNING.md 先写答案，再选本节末尾的变式，列一个新失败例子后修改。保持原用例通过。仅跑通配套界面、没有完成规则与解释，记录为“参考演示已观察”，不记录为自己完成作品。

卡在规则时按“函数输入→分支条件→返回值→参考实现”逐级看提示；卡在运行时按 故障表 定位。若想单独观察参考成品，在构建命令后加 --reference；页面会明确标出参考演示。观察完再去掉该参数重建，继续自己的 starter。

1. 先统一一次检查的含义

打开 u10/starter/model.ts。Sample 有时刻、up/down、延迟；没有收到有效响应时延迟可记录 null。本练习将 2xx 且延迟严格小于超时阈值视为 up，其他情况为 down。这是本题约定，不代表所有业务都只看 HTTP 状态。

完成 classify，注意“正好达到超时”属于 down；负延迟与无效超时输入拒绝。完成 recordSample：记录时刻递增，保留最近 max 条，只有与上一次状态不同才 changed=true；第一次观测不冒称“恢复”。

2. 先用固定时钟观察序列

运行 sample 与核心测试。构造 up→up→down→down→up，预期变化只有两次。不要在循环里每看到 down 就重复输出“刚刚故障”。保留历史的上限也要验证，不让页面一直增长。

3. 建一台可以故意失败的本地目标

配套 tools/target.mjs 绑定本机3401，提供 /health；默认up返回200，down返回503，slow延迟1500毫秒。node tools/probe.mjs u10 通过本地 /mode?value=up|down|slow 切换并检查三种模式，不需另建目标程序。

只监控这个固定目标，不扫描内网或陌生主机。状态切换仅作用于这个本地模拟目标；连接拒绝实验则用 Ctrl+C 停掉该目标。

4. 写检查循环，避免重叠请求

在 runtime/src/u10.ts 中跟踪 fetch，设置 AbortSignal.timeout。收到响应记录状态和耗时，异常记录 down 与原因。一次完成后再等待到下一轮，不用无条件 setInterval 堆叠尚未结束的慢请求。状态分类交给核心，当前时间与网络交给外层。

先用核心样例观察 sample 与 changed，再运行已经接数据库的采样入口；页面单次采样、开始监测、停止监测分别调用 sample/start/stop。开始监测才进入循环，重启API后需要重新点击开始。

5. 接持久化与看板

沿手册 18–20 保存 at/status/latency/reason 的合成监控记录，reason 不含秘密；列表接口限制读取条数。Vue 看板显示最新状态、最后检查时间和最近记录。超过约定时长没有新样本时显示“数据已过期/监控可能停止”，不能继续把上次绿色状态当成当前正常。

停止监控程序，让目标继续运行，验证过期提示；恢复监控后提示消失。这里验证的是监控自身是否还在工作，不只看目标故障。

6. 完成检查与独立变式

记录200、503、超时、连接拒绝、连续失败不重复变化、恢复、历史条数上限和监控停止后数据过期。核心测试没有实际发网络请求，必须保留 target 与 monitor 的真实运行结果。

独立变式：连续两次 down 才判故障，但恢复仍一次 up 即恢复。先画 expected 序列，再改状态机；保留原始样本与派生告警状态，不把它们混成同一字段。

暂停时停止 target、monitor 和看板服务；README 写出它们各自目录与端口。学习 Uptime Kuma 源码时只追一条目标检查链路，现成镜像启动成功不计作本节编程完成。