Legacy Edge Lab 阶段记录

发表于 2026-09-08 分类于 Observability 阅读次数：本文字数： 8.8k 阅读时长 ≈ 32 分钟

记录在WSL2中搭建Prometheus/Grafana以应用家用旧设备进行边缘监控实践与退役决策

Legacy Edge Lab 阶段全记录：旧设备的边缘监控实践与退役决策

记录范围：2026 年 9 月 4 日至 9 月 8 日。文中时间均为北京时间，除非另有注明。

本文依据项目清单、实现说明和阶段验证记录整理。版本号、性能数据和设备状态描述的是本次实验环境，不代表最新软件版本，也不代表同型号设备普遍具备这些能力。外观和操作体验来自现场反馈，系统信息来自实际查询，连续性数据来自采集记录与 Prometheus。

1. 项目起点：给旧设备找到边界清楚的工作

Legacy Edge Lab 的起点是一组闲置设备：小米手机 3、小米平板 1、Kindle、旧 iPhone 和旧笔记本。项目希望用它们学习边缘采集、网络可观测性、故障恢复、跨平台差异和设备生命周期管理。

最终得到的结果并不是五台设备全部上线。截至本轮收尾，小米 3 已成为通过验证的受控 Android 边缘探针；小米平板 1 和旧笔记本退役；Kindle 与旧 iPhone 保留为尚待评估的候选设备。

这个结果符合项目最初的工程顺序：简单、稳定、可逆、低资源、可维护、可观测、容易恢复，并适配旧硬件。每增加一层组件，都需要说明它解决了什么已观察到的问题。

设备承担边缘采集、显示或兼容性测试，重计算留在主 Homelab。本轮没有把 Prometheus、Grafana 后端、数据库或容器平台搬到旧手机和平板上，也没有为了找到用途去 root、解锁或刷机。

2. 阶段路线与最终架构

各设备的阶段编号独立。例如，小米 3 的 Phase 3C 完成后，小米平板仍从自己的 Phase 0 开始。

阶段	要回答的问题	实际结果
小米 3 Phase 0 / 0B	真机是什么状态，能否继续观察？	完成只读清单、基础网络检查和 30 分钟基线
小米 3 Phase 1	现有运行时能做什么？	选择系统 Shell、已有 Python 2.6.2 和主机 ADB 采集
小米 3 Phase 2A	最小探针是否可运行？	有界测量、稳定 JSON 和独立失败处理得到验证
小米 3 Phase 2B	USB 断开后会怎样？	断开期间持续输出，重新连接后自动恢复；修正失败分类
小米 3 Phase 2C	接入真实 VPS 后能连续运行吗？	两小时、121 次采集全部完成，零测量执行失败
小米 3 Phase 2D	更长运行中能否区分网络事件与探针故障？	八小时、481 次采集完整，外网异常自动恢复
小米 3 Phase 3A	怎样接入指标系统且不让抓取等待 ADB？	实现主机端后台采集与快照读取分离的 exporter
小米 3 Phase 3A.1	真正的 Prometheus 能否正确抓取、识别故障？	实际入库、PromQL、陈旧数据和恢复语义得到验证
小米 3 Phase 3B	完整链路能否持续运行一天？	精确 24 小时窗口内 2,881 次抓取完整，无传输或采集器故障
小米 3 Phase 3C	仪表盘能否解释实际发生过的问题？	完成 Grafana 集成，用历史异常验证诊断视图
小米平板 Phase 0A—0C	能否成为低维护显示终端？	完成清单，确认 Chrome 的 Grafana 脚本解析障碍和 HTTPS 信任问题
小米平板 Phase 0D	是否进入首次显示稳定性测试？	未开始；轻量页面测试访问再次中断，停止继续投入
设备生命周期收尾	哪些设备仍值得保留为 Lab 资源？	平板和无法开机的旧笔记本正式退役

最终已经验证的小米 3 路径如下：

小米 3
  ├─ Wi-Fi：实际发出 ICMP、DNS、TCP 测量
  └─ 系统 Shell / 已有 Python 2.6.2
          │
          │ USB / ADB：主机发起临时命令并读取结果
          ▼
主 Homelab 的 Windows / WSL
  └─ collector：约每 60 秒采集一次
          ▼
     exporter：后台采集 + 有界内存快照
          │ 127.0.0.1:9108/metrics
          ▼
     Prometheus：每 30 秒抓取
          │ 本机 TSDB
          ▼
     Grafana：本机回环访问，保留登录认证
          ▼
     电脑浏览器

测量从手机的网络栈发出，结果通过 USB 返回主机。它仍有 Android 边缘观测价值，但不是已经脱离主机、能自主联网发送指标的独立探针。

3. 小米 3 Phase 0：先查实机，再讨论用途

3.1 硬件与系统基线

2026 年 9 月 4 日，通过已授权的只读 ADB 查询得到以下基线：

项目	实测结果
制造商 / 型号 / 代号	Xiaomi / MI 3 / `pisces`
Android / API	4.4.4 / 19
MIUI / 构建	V8 / `V8.0.1.0.KXCCNDG` / `KTU84P`
安全补丁属性	2016-08-01
构建类型 / 标签	`user` / `release-keys`
内核	Linux 3.4.35-g8f1d7b1
CPU / ABI	ARMv7 Processor rev 2，四个逻辑处理器；`armeabi-v7a`，兼容 `armeabi`
系统可用总 RAM	2,015,048 kB，约 1.92 GiB
Swap 总量	786,428 kB
数据与共享存储	`/data` 约 3.4 GiB；`/storage_int` 约 9.1 GiB
屏幕	Android 报告 1080×1920、480 dpi
USB	`mtp,adb`，连接已授权
已有浏览器	小米浏览器 8.1.6

没有把产品宣传页的规格直接填进清单。准确的 SoC 营销型号、物理闪存标称容量、实际 Wi-Fi 频段能力等，没有在本轮得到足够证据。

ADB Shell 是 UID 2000；查询时没有发现常见位置的 su，构建为 user/release-keys。这些观察不能证明 bootloader 已锁定，也不能证明设备从未改动过。

3.2 安全与 30 分钟基线

用户反馈手机外观正常，无异味、无变形，使用原有配件。初次电池遥测为 13%、40.3°C；这一瞬时读数被保留，没有直接解释为电池故障，也没有把系统返回的 good 当成真实健康认证。

随后在 17:17—17:47 做了四次约间隔 10 分钟的只读采样：

ADB 和 Wi-Fi 持续可用，uptime 单调增加，没有重启证据。
电量由 22% 增至 33%，USB 充电持续。
电池温度为 34.5—34.8°C，没有上升趋势。
内存、缓存和 Swap 存在波动，没有在这个短窗口内表现出持续恶化。

这是低负载基线，不是显示测试、满负载测试或续航测试。安全等级定为 YELLOW：可以继续受控实验，尚未批准无人值守运行。

3.3 最小网络能力

实际验证了当前 Wi-Fi 连接上的 IPv4、到默认网关的有界 ICMP，以及公共域名解析后进行 IPv4 探测的路径。

IPv6 在内核层面没有被禁用，但当时只有回环和链路本地地址，没有全局 IPv6 地址。这个结论只描述所测连接，不能推导为设备完全不支持 IPv6。

首次检查还发现 awk 不可用，相关初始结果被丢弃，改用实际存在的工具重新验证。旧 Android 上不能假设一个看似普通的 Unix 命令一定存在。

4. Phase 1：把已有运行时用在它能胜任的范围内

手机上有 mksh、ping、ping6 和一个裁剪过的 Python 2.6.2。Python 能导入 socket、threading、select 等模块，但缺少 ssl、常见 HTTP 库以及 json；系统也没有查到 curl、wget、OpenSSL 或独立的通用 timeout。

因此，不能看到“有 Python”就按完整 Python 环境设计，也不能假定现代 Termux 可以直接安装使用。

路线	本轮判断
系统 Shell	用于设备检查、执行和解析有界 ping，开销低
已有 Python 2.6.2	限定用于 DNS、TCP socket 和诊断性明文 HTTP
增加兼容用户态工具	当时作为补齐现代 TLS 的可能路线，未在本轮执行
自行开发 APK	维护成本更高，没有进入实现

最终选择 Shell 与已有 Python 的小组合，由主机通过 ADB 调度并生成 JSON。手机没有新增软件或持久化脚本。

Phase 1 曾记录一个“验证兼容 HTTPS 客户端”的候选实验，后续实际工作选择了先验证非 TLS 探针的可靠性。本文不把这个历史建议记成已完成安装；小米 3 的现代 HTTPS 测量至今仍未建立。

5. Phase 2A：最小 ADB 探针

采集器位于主机，提供稳定、带版本号的 JSON 输出。真正的目标值只从 Git 忽略的本地配置读取，输出使用 gateway、internet、vps 三个固定逻辑名称。

第一版包含 ICMP 延迟与丢包、全局 IPv6 状态、DNS 成功率与耗时、TCP 建连结果与耗时，以及 uptime、电池和 Wi-Fi 等低成本状态。原始 socket 的明文 HTTP 只作诊断，默认关闭。

有界执行是这一阶段的核心要求：

ping 同时使用次数、总 deadline 和回复等待上限。
DNS 通过带 join deadline 的工作线程约束，避免只设置 socket timeout 却无法限制名称解析。
每次设备侧操作外面还有主机的 ADB 超时。
单个目标失败后，后续目标仍继续测量。

正常单次测量约需 7—8 秒；可选明文 HTTP 验证约需 8.6 秒；组合故障测试在 18.4 秒内结束。独立主机 JSON 解析器能够读取输出，三次约 60 秒间隔的循环也保持了相同结构。

这里的 vps 代码路径最初用公共替代目标验证，不能算作真实 VPS 连通性验证。这个缺口在 Phase 2C 才补上。

6. Phase 2B：两小时 USB 中断与恢复

2026 年 9 月 5 日 14:36—16:36，采集器安排了 121 次测量：开始立即执行一次，随后每 60 秒一次。

第一次健康采集之后，用户执行了一次物理 USB 断开。线缆保持断开期间，第 2—53 次共 52 个周期不可用；重新连接后，第 54 次成功，恢复发生在连接可用后的第一个计划周期。

52 个失败周期反映线缆断开的时长，不是恢复耗时。

项目	结果
预期 / 输出 / 可解析记录	121 / 121 / 121
成功执行记录	69，其中 1 次有 DNS 测量失败
ADB 传输失败	52
采集器故障	0
成功周期耗时中位数 / 最大值	6.649 秒 / 11.818 秒
传输失败周期耗时	0.118—0.150 秒
温度	31.0—34.4°C

重新连接没有要求重启手机、重启 ADB 服务或再次授权。但这也暴露了架构代价：USB 是真实依赖，自动恢复不能弥补线缆断开期间没有测量数据。

6.1 一个值得修正的实现问题

Schema v1 在传输不可用时，把没有执行的网络测量列为失败，并设置 partial_failure=true。这会让仪表盘把“没测到”误读成“网络都坏了”。

测试后做了聚焦修正，升级到 schema v2：

传输失败：
  transport_failure = true
  failure_class = "transport"
  measurement failure list = []

测量失败：
  ADB 和设备执行路径仍然可用
  partial_failure 只表示已经执行的测量中存在失败

修复使用主机端不可用 ADB 路径和独立 DNS 故障进行验证，没有重新设计调度，也没有为了修复分类再制造一次长时间物理断连。

这次两小时测试证明了恢复机制，但因为存在很长的传输空窗，不能代替连续两小时工作基线。

7. Phase 2C：真实 VPS 的连续两小时基线

同日 17:27—19:27，用 schema v2 和本地真实 VPS 配置运行连续测试。USB 保持连接，没有计划中断。

项目	结果
完整记录	121 / 121
传输故障 / 采集器故障 / 测量执行失败	0 / 0 / 0
调度间隔	所有 120 个间隔均为记录中的 60 秒
测量耗时中位数 / 最大值	10.157 秒 / 13.913 秒
DNS / TCP 成功次数	121 / 121，各自均为全部成功
真实 VPS ICMP	每轮至少收到一个回复
电池 / USB	电量全程 100%，持续 USB 供电
温度	32.9—34.4°C

“零测量执行失败”不表示“零丢包”。121 轮中，网关、Internet、VPS 分别有 11、18、48 轮报告非零丢包。VPS 每轮平均 RTT 的中位数为 421.720 ms，TCP 建连耗时中位数为 422.018 ms。

短 ping 批次存在丢包，同时 TCP 每轮都成功，这些是有意义的路径观察。它们不能直接用来诊断某个设备或链路的具体故障，也不应被当作采集器失效。

内存与缓存上下波动，未表现为单调泄漏；这仍不能排除更慢的泄漏。完整结果支持进入八小时阶段。

8. Phase 2D：八小时测试中捕获真实网络事件

2026 年 9 月 5 日 22:05 至次日 06:05，连续运行 481 次采集。

项目	结果
输出与解析	481 / 481 完整
ADB 传输失败 / 采集器故障	0 / 0
包含测量失败的周期	12
耗时中位数 / 最大值	9.568 秒 / 26.367 秒
DNS 成功	479 / 481
TCP 成功	469 / 481
电池与温度	全程 100%、USB 供电；32.1—32.9°C

这次最有价值的发现是 02:20—02:29 的连续外部连接事件：TCP 在十个周期内失败，Internet 与 VPS 的 ICMP 在后九轮完全丢失，DNS 在最后两轮也失败。与此同时，网关 ICMP、ADB、Wi-Fi 状态采集、设备状态和 JSON 输出保持健康。

所有受影响测量随后无需干预就恢复，并继续运行约 3 小时 36 分钟，没有新的测量失败周期。另有两次早期孤立 TCP 失败，共同构成 12 次测量失败。

这支持将事件解释为所观测的外部路径异常，而不是采集器故障；具体故障设备或运营商原因并未确定。

八小时门槛通过后，才开始添加主机监控后端。手机仍是 YELLOW，未因阶段通过而自动获得无人值守许可。

9. Phase 3A：把采集与 Prometheus 抓取解耦

探针可能花费几秒到二十多秒。如果每次 Prometheus 访问 /metrics 都启动一轮 ADB，抓取延迟和设备测量就会绑在一起。

本轮 exporter 采用 Python 标准库实现：后台线程每 60 秒调用现有 collector；HTTP 服务只读取最新有界内存快照。抓取不会触发 ADB，也不会等待当前测量完成。

状态只保留最近一次尝试、最近一次传输健康时的测量及少量健康字段，没有持续增长的内存队列，也不写手机存储或连续访问日志。

9.1 故障语义要能解释现实

事件	应该看到的信号
单个 DNS/TCP/ping 测量失败	传输与执行仍成功，partial failure 为 1，对应测量失败
ADB 不可用	传输与执行为 0；不制造一组虚假的网络测量失败
无法得到新测量	保留之前传输健康时的测量，同时明确增加数据年龄
数据超过 150 秒未更新	stale 为 1；首次有效测量之前也为 stale
主机调用 collector 意外异常	exporter collection success 为 0，错误计数增加
exporter 进程消失	Prometheus 自身的抓取 `up` 为 0

保留旧值必须同时显示年龄和陈旧状态。否则一个仍然返回 HTTP 200 的接口，可能长期展示已经失效的“正常”数据。

9.2 指标与基数控制

项目实际使用 legacy_edge_ 前缀，时间统一按秒、丢包和电量按比例暴露。部分关键指标如下：

legacy_edge_probe_transport_up
legacy_edge_probe_execution_success
legacy_edge_probe_partial_failure
legacy_edge_probe_duration_seconds
legacy_edge_probe_age_seconds
legacy_edge_probe_stale
legacy_edge_exporter_collection_success
legacy_edge_exporter_collection_errors_total
legacy_edge_ping_success
legacy_edge_ping_rtt_seconds
legacy_edge_ping_packet_loss_ratio
legacy_edge_dns_success
legacy_edge_dns_duration_seconds
legacy_edge_tcp_success
legacy_edge_tcp_connect_duration_seconds
legacy_edge_ipv6_global_available
legacy_edge_device_battery_temperature_celsius

exporter 样本只使用固定设备标签，ping 额外使用三个固定目标标签。实际地址、时间戳、动态错误字符串、请求 ID 和完整 URL 不作为标签。Prometheus 后续会增加自己的 job、instance 标签。

Android 内存诊断值没有直接进入首批指标。MemFree、缓存与 Swap 可以辅助观察，但当时不足以提供清晰的“应用可用内存”语义，贸然画成告警指标容易误导。

9.3 这一阶段到底验证了什么

真实 /metrics 返回 HTTP 200，包含 21 个指标族、27 个样本，HELP/TYPE 元数据完整。初次响应约 13.427 ms，在后台 ADB 正执行时的响应约 1.148 ms。六个单元测试覆盖单位、元数据、启动陈旧状态和不同故障类型。

当时环境没有 Prometheus 或 promtool。因此 Phase 3A 只能声称“指标暴露及语义已验证”，不能声称“真实 Prometheus 已抓取”。后者单独进入 Phase 3A.1。

10. Phase 3A.1：真实 Prometheus 入库与故障验证

2026 年 9 月 6 日，在 WSL 主机安装并验证了 Prometheus 3.13.2 LTS 的官方 Linux amd64 独立发行包。第一次下载不完整，校验和与归档检查失败，因此没有安装；完整重传通过校验后才解压使用。

环境的 PID 1 不是 systemd。安装使用用户目录，没有引入 Docker、Kubernetes、系统包管理或自启动服务。

组件	本轮配置
collector / exporter	每 60 秒采集；监听 `127.0.0.1:9108`
Prometheus	每 30 秒抓取；监听 `127.0.0.1:9090`
陈旧阈值	150 秒，即当前采集间隔的 2.5 倍
TSDB 保留限制	7 天、1 GiB
运行状态	保存在 Git 外；前台进程手动启动

promtool 配置检查通过，真实 target 为 UP，PromQL 能查到所需指标，抓取约 2 ms。

随后进行两种不同故障验证：

短暂拔掉 USB。 exporter HTTP 仍可访问，Prometheus up=1，但传输状态变为 0；旧测量保留，年龄增长，在约 157.5 秒的观察点已超过阈值，stale 为 1。恢复 USB 后，下一个成功周期恢复传输和新鲜状态。
停止 exporter。 Prometheus 本身仍运行，下一次抓取将 up 置为 0；重新启动 exporter 后恢复。

这证明接口可用、设备传输可用和测量新鲜度是不同层次。这里验证的是状态指标，还没有实现告警规则或通知流程。

11. Phase 3B：完整链路的 24 小时验证

精确分析窗口为 2026 年 9 月 6 日 13:42:25 至 9 月 7 日 13:42:25，共 86,400 秒。由于人工返回时间较晚，实际进程约运行了 25 小时 42 分钟；核心连续性统计严格限定在原来的 24 小时内。

11.1 采集与抓取连续性

指标	24 小时结果
预期 / 实际 Prometheus 抓取	2,881 / 2,881
抓取间隔	30 秒，无缺口
独立探针快照	1,441
Prometheus target UP	100%
ADB 传输 / 执行成功	100% / 100%
exporter 采集错误	0
stale 事件	0
包含测量失败的快照	30，占 2.08%，分为 10 个事件段
探针耗时：中位数 / p95 / 最大值	9.771 / 13.016 / 27.369 秒
抓取耗时：中位数 / p95 / 最大值	1.789 / 1.979 / 2.594 ms
数据年龄最大值	52.384 秒，低于 150 秒阈值

记录包含时间窗口两端的采样点，因此 24 小时、30 秒间隔会得到 2,881 个点；这些抓取也不等同于同样数量的独立手机测量。

11.2 网络测量并没有“全绿”

下表中“非零丢包轮次”与“全部丢包轮次”按每个短探测批次统计。RTT 表示有回复批次的平均 RTT 分布，不能当作整天所有单包时延的分布。

路径	非零丢包轮次	全部丢包轮次	RTT 中位数 / p95 / 最大值
网关	98 / 1,441	3	31.782 / 133.072 / 455.652 ms
Internet	179 / 1,441	22	116.196 / 431.199 / 2,197.906 ms
VPS	463 / 1,441	25	419.713 / 561.327 / 2,281.889 ms

DNS 成功 1,427 / 1,441 次，TCP 成功 1,416 / 1,441 次。整个窗口内没有观测到全局 IPv6 可用。

两次明显的外部连接事件发生在 01:30—01:39 和 06:56—07:05，各持续十个探针周期。Internet/VPS 的 ICMP 与 TCP 同时受影响，部分周期 DNS 也失败；网关、ADB、exporter 和 Prometheus 保持健康。

接近窗口结束时，还有一次持续两个周期、连网关也受影响的事件。它在额外运行窗口中自行恢复，因此“恢复”证据和“精确 24 小时统计”分开保留。

这些测量失败没有被清洗成成功，也没有被记成监控链路中断。四个六小时段中的部分测量失败数分别为 3、11、11、5，没有表现出随时间单调恶化。

11.3 设备、主机资源和存储

手机电量与 USB 供电状态在所有探针快照中保持 100% 和已供电，uptime 持续增加。电池温度为 32.3—35.0°C，中位数 33.4°C，没有持续上升趋势。

主机端 exporter RSS 从启动时 24,600 KiB 增至约 25.7 小时后的 25,832 KiB，增长约 1.2 MiB。这个变化没有影响工作，但不足以宣称不存在缓慢泄漏。Prometheus RSS 没有呈现持续增长。

TSDB 从启动前的 52,769 字节增至延迟收尾时的 669,423 字节，仍低于 1 MiB。因为收尾超过了精确 24 小时，而且存在压缩整理，这只是较长实际运行范围的存储观察，不能包装成精确的一天增长率。

promtool 对所分析 TSDB 块发现 32 条序列、五个标签名，未见标签 churn。这与 exporter 初始暴露的 27 个业务样本属于不同统计范围，不能直接混算。

11.4 通过测试仍然是 YELLOW

测试前、约 5.3 小时、约 19.8 小时及完成后都有用户外部检查，未报告异常发热、异味、变形、火花或供电不稳。夜间两次物理检查之间约有 12 小时间隔；连续遥测不等于连续人工看护。

阶段结论是：完整链路可继续用于受控 Homelab 实验。旧电池、旧系统、USB 依赖和主机进程生命周期仍然存在，安全等级保留 YELLOW，没有升级为无人值守 24×7 设备。

12. Phase 3C：Grafana 展示真正的故障差异

阶段记录在 9 月 7 日完成 Grafana OSS 13.2.1 的安装与验证，相关提交在 9 月 8 日入库。它同样使用经过校验的用户目录独立安装，仅监听 127.0.0.1:3000，保持登录认证，禁用匿名访问和用户注册。

仪表盘 Legacy Edge — Xiaomi Mi 3 包含五个分区、20 个可视化面板，默认查看 24 小时并每 30 秒刷新：

整体健康：Prometheus、exporter、ADB、执行状态、数据新鲜度。
网络路径：逻辑目标的 ICMP 成功、RTT、丢包，以及全局 IPv6 状态。
DNS 与 TCP：成功状态和耗时。
探针状态：持续时间、数据年龄和部分测量失败。
设备健康：电量、温度、USB 供电和 uptime。

所有面板查询在验证时都返回数据。更重要的是，通过 Grafana 数据源回看 01:30—01:39 的真实事件，20 个抓取样本显示监控链路与网关健康、没有陈旧数据，同时 Internet/VPS/TCP 失败后恢复。

这让仪表盘能回答“网络异常发生时，探针自己是否还在正常工作”，而不仅是展示若干曲线。

20 次连续仪表盘 API 请求的中位耗时为 21.617 ms，最大 45.281 ms；查询后监控链路仍健康，Grafana 进程约占 340 MiB RSS。这些是主机端 API 与资源数据，不是平板页面渲染性能，也不是浏览器完整交互基准。

至此，小米 3 的边缘测量、主机采集、指标暴露、时序存储与可视化形成了完整链路。

13. 小米平板 Phase 0A—0B：先确认“屏幕 + Wi-Fi + 浏览器”的真实基础

平板原本考虑作为 Grafana 或轻量 Homelab NOC 显示屏。后端仍留在主机，平板只负责展示。

用户先完成外部观察：外观完好、无鼓包异味、温度正常、能够开机，USB 接口完好无松动，报告稳定充电，拔掉 USB 后可以用电池运行，但续航未测。

确认已有 USB 调试授权后，才执行只读清单采集。

项目	实测结果
型号 / 代号	Xiaomi MI PAD / `mocha`
Android / API	4.4.4 / 19
MIUI / 构建	`V9.2.4.0.KXFCNEK` / `KTU84P`
安全补丁属性	2016-12-01
CPU / 平台	ARMv7，四个逻辑 CPU；平台 `tegra`，sysfs family 为 `Tegra12`
内存 / Swap	系统总 RAM 约 1.88 GiB；无 Swap
数据分区	设备 df 报告总量 55.4G、剩余 20.2G；非物理闪存容量结论
屏幕	Android 报告 1536×2048、320 dpi
浏览器	小米浏览器 9.3.2；Chrome 62.0.3202.84
WebView	系统库文件存在；独立包未找到，具体引擎版本未验证
网络	Wi-Fi 开启、有 IPv4 地址，无全局 IPv6 地址

电池离散快照为 33%/33.7°C、29%/35.5°C、29%/34.5°C，系统显示 USB 充电。用户确认该段没有拔 USB。这个下降需要被记录，但没有连续功率采样或容量测试，不能断言电池损坏或 USB 供电不足。

屏幕超时值很大，但没有更改它，也没有据此宣称屏幕永远不会锁定。设备安全状态暂定 YELLOW，没有发现足以判断 RED 的已报告证据。

14. Phase 0C：Grafana 显示为什么没有通过

14.1 HTTPS 证书失败与基本页面渲染分开判断

两个已安装浏览器访问公共 HTTPS 示例页都出现证书问题。Chrome 错误名为 NET::ERR_CERT_AUTHORITY_INVALID；输入 HTTP 示例地址后跳转 HTTPS，仍然失败。

平板与主机时间基本一致，没有明显日期偏差。没有安装证书或绕过警告，也没有仅凭错误名认定为旧根证书、特定 TLS 版本或中间设备所致。

随后公共 HTTP 测试页能够显示，说明至少基础页面加载可用。JavaScript 设置被报告为允许，但“允许脚本”与“脚本已经正确执行”仍是两种证据。

14.2 先用 USB，保留 Grafana 的回环边界

Grafana 原本只监听主机回环，没有为平板测试直接开放 LAN。实验采用桌面 Chrome 的 USB 端口转发，尝试让平板访问主机本机服务。

过程中出现设备信息 stale、标签标题令人误解、inspect 调试窗口长时间空白等现象。后续通过直接调试协议确认 Chrome 62 使用协议 1.2，能够定位到目标标签并读取事件。

这里还有几个需要保留的排障边界：

平板返回桌面的一次事件后来被确认是用户手动退出，不计为崩溃。
am start 的旧系统参数和 Activity 权限限制导致自动打开页面尝试失败，没有绕过权限。
ADB 反向转发的只读查询返回 closed，不能因主机命令存在就认为设备支持。
主机 Grafana 正常、Windows 能访问时，平板曾返回 ERR_CONNECTION_REFUSED，且没有发现平板本地目标端口监听；这一轮属于访问路径问题。
临时用于直接调试的 ADB 转发在每次查询后撤销，没有把它们留成长期部署。

这些现象说明测试工具链也需要验证，不能把所有报错都归到设备性能上。USB 显示即使成功，也不能代替最终 Wi-Fi 部署验证。

14.3 真正捕获到的前端兼容障碍

恢复 Chrome USB 映射后，平板显示：

1	If you're seeing this Grafana has failed to load its application files...

直接调试采集观察到初始 Document、五个 Script 和两个 Stylesheet 返回 HTTP 200，同时多次出现：

1	Uncaught SyntaxError: Unexpected token {

资源已被取到，但 Chrome 62 无法解析当前交付的至少部分脚本。精确的语法特性和 bundle 尚未定位，已有证据足以确认当前浏览器组合没通过前端启动门槛。

减少面板数量主要影响进入应用后的负载，无法解决相同 Grafana 前端的启动语法错误。因此没有再为这台平板制作简化 Grafana 仪表盘。

小米浏览器没有实际完成 Grafana 渲染测试，不能把 Chrome 的结果包装成两个浏览器都已实测失败。

15. 静态回退尝试与未开始的 Phase 0D

回退层级预先定义为：

层级	内容	本轮状态
Tier A	完整 Grafana	Chrome 62 下前端启动失败，登录与面板未进入可测阶段
Tier B	更少、更轻的 Grafana 面板	未实施；无法解决已观察到的公共前端语法障碍
Tier C	服务端生成的轻量真实状态页	未实现真实监控集成
Tier D	定期刷新的静态 HTML / 图片	模拟 HTML 初次显示成功，刷新和稳定性未完成验证

为了验证 Tier D，主机临时运行了一个仅监听回环的静态 HTML 测试服务，页面包含明确标为模拟数据的状态卡片、简单时钟、触摸计数和每 60 秒刷新。

用户调整 USB 映射后，平板成功显示了 “LEGACY EDGE LAB” 和中文测试标题。随后，在没有操作的情况下，页面再次变成“无法访问此网站”。本次没有同步采到足以确定根因的错误码或监听状态，不能认定为浏览器崩溃、Wi-Fi 故障或静态 HTML 不兼容。

由于功能与访问路径尚未稳定，原计划的 30 分钟受控显示测试没有开始。没有进行更长测试，没有关闭热保护、电池保护或修改息屏设置。

这时继续投入已经不符合低维护显示终端的目标。临时轻量服务被停止，测试夹具没有变成项目组件。设备最终决定为 retired / not worth further investment，Grafana/NOC 角色及后续静态回退角色均关闭。

退役依据是已经观察到的前端兼容障碍、HTTPS 信任问题和测试访问中断带来的维护投入，而不是一个未证实的硬件故障。项目不再通过 root、ROM、替换浏览器、维修或进一步兼容性工作来保留这台平板的角色。

16. 旧笔记本：从供电约束到非运行状态退役

旧笔记本最初有电池失效或不可用、外部供电可能不稳定的历史记录。因此它原本只被列为有条件的 Linux 实验机、故障测试节点、SSH 跳板、临时 Kubernetes worker、PXE 测试机或网络排障工作站。

2026 年 9 月 8 日，用户报告它现在无法开机，并决定退出 Lab。没有进行新的通电试验、拆机或硬件诊断；具体型号、故障位置和失败部件均未验证。

状态明确记录为 non-operational / retired from the lab，所有历史候选角色关闭。不把无法开机进一步解释为主板、电池或适配器的确定故障，也不启动内部电气维修来维持这些设想。

17. 当前状态、已交付内容与尚未完成的工作

17.1 设备池

设备	收尾状态
小米 3	已验证的受控 Android 边缘可观测性探针；YELLOW
小米平板 1	已退役，不值得继续投入；不再承担显示角色
旧笔记本	无法开机，非运行状态，已退役
Kindle	仍为候选，尚无实机清单或显示可行性验证
旧 iPhone	仍为候选，尚无实机清单或网络/Safari 验证

尚未完成 Android、iOS、Linux 的同网络横向比较。Kindle 的低刷新显示架构和 iPhone 的兼容性测试仍是候选方向，不能当成已经部署的成果。

17.2 仓库交付

AGENTS.md                         项目原则与当前退役约束
inventory/                        真机清单、测试证据、退役理由
docs/device-role-matrix.md         当前设备角色
probes/android/xiaomi-mi3/
  collector.py                    主机 ADB 采集器
  exporter.py                     有界状态与 Prometheus 指标
  test_exporter.py                指标与故障语义验证
  config.example.json             已脱敏配置模板
prometheus/                       实际配置、模板与运行说明
grafana/                          回环配置、启动脚本、数据源与仪表盘 provisioning

密码、真实目标、完整序列号、SSID、MAC、私有网络地址、原始运行日志和 TSDB 不进入博客稿。实际配置与运行状态保存在 Git 外；本文使用的 127.0.0.1 是回环地址，逻辑目标也不暴露真实拓扑。

17.3 当前限制

小米 3 的成功仍有清楚的适用范围：USB/ADB 和 Windows/WSL 是依赖，主机进程手动启动，没有完成进程监督或自启动；Grafana 是回环访问；告警规则和响应流程尚未实现；现代 HTTPS 探针与全局 IPv6 的实际连通性没有得到验证。

现有记录认为，后续有工程价值的工作是主机进程监督，以及在合适条件下对仍在候选池的设备先做清单与安全检查。这些都属于待办，不是本篇已经完成的阶段；退役设备没有保留后续实验任务。

18. 这轮实践留下的工程认识

第一，旧设备是否有价值取决于任务边界。小米 3 的系统虽然老，但已有工具足以完成小规模、低频网络测量；平板能显示网页，也不代表它适合承担当前 Grafana 前端。

第二，可观测性必须包含采集链路本身。网络失败、USB 断开、主机采集异常、exporter 不可达和数据过期，需要不同信号。否则仪表盘可能把完全不同的问题画成同一种红色。

第三，分阶段验证能保留判断依据。30 分钟的低负载观察、两小时恢复测试、连续两小时真实路径、八小时采集以及完整链路 24 小时测试，各自回答不同问题，不能互相替代。

第四，运行时间和恢复行为都重要。一次掉线后能自动恢复，不代表依赖消失；一天没有重启，也不等于电池和供电从此适合无人值守。

第五，停止投入可以成为完整的工程结果。平板的兼容性排查、临时显示路径与维护成本已经超过角色收益；旧笔记本则失去了基本运行能力。保留这些退役理由，比让设备永远停留在“以后还能折腾”的候选表里更有用。

19. 原始记录与复核入口

以下链接固定到本次总结依据的仓库提交 2140421，便于博客留档后复核，避免后续主分支变化改变本文的证据范围：