provide/stat如何监控CID提供队列？

内容已经pin在Kubo节点，却迟迟不能从其他节点通过CID发现。除了网络可达性，provider record是否入队、何时发布、是否按期reprovide以及worker是否积压都可能影响结果。provide/stat把这套后台系统第一次较完整地暴露出来，但它仍处于实验阶段。

先按生命周期组织指标

CID进入提供队列后，由worker执行发现或发布操作，记录在路由系统中并在有效期内可供查询；到期前需要重新提供。监控若只看最终队列长度，会漏掉worker停滞、错误率升高、调度落后和网络不可达。

本地内容 → 首次入队 → worker处理 → provider record传播
    ↑                                      ↓
内容仍受保护 ← 定期扫描与reprovide ← 记录接近过期

提供系统发布CID到Peer ID的provider records，记录有有效期，因此需要按计划reprovide。

provider record把CID映射到Peer ID并有生命周期。即使某次提供成功，节点长期离线、地址不可达或之后未按期reprovide，远端可发现性仍会退化。

Kubo 0.43的provide/stat是实验接口，可显示提供系统统计并可能随版本变化。

Kubo 0.43文档明确将provide/stat标为实验。采集器把版本、provider类型、请求选项和原始JSON写入样本；解析采用允许新增字段、拒绝关键类型错误的策略。升级前在测试实例跑相同请求，比较字段和单位。

实验接口不可用时，应把监控状态标为unsupported或unknown，不填成全零。全零会被误解成“没有积压且系统健康”，比明确缺数更危险。

接口提供connectivity、network、schedule、timings、workers、operations和queues等可选分区。

全量all视图适合人工诊断，日常高频采集选择少量稳定分区，减少响应与解析成本。告警附带原始分区和版本，避免只有一条“provider异常”。

默认Sweep provider与Legacy provider的统计能力和调度方式不同，监控必须同时保存provider类型与Kubo版本。

Sweep provider按DHT键空间区域安排工作，目标是更均匀地处理大量CID；Legacy provider更接近逐CID查找与周期任务。两种实现的吞吐、队列、调度和可用统计不同。迁移实现时给时间序列打断点，不能把指标突变直接归因业务流量。

配置里还要保存Provide.Strategy，因为提供全部内容、仅pin内容或其他策略会改变CID集合。业务期望与实际策略不一致时，即使worker完全健康，也可能永远不会发布目标CID。

队列短时增长可能只是批量导入，只有持续高于正常区间、worker利用率高且操作吞吐跟不上时才升级容量事件。错误率上升结合connectivity退化，更像网络或DHT问题；调度时间漂移而系统时钟异常，则先修时间同步。

为重要CID建立小规模探针：本地证明内容存在，从独立查询节点定时findprovs，必要时实际读取。内部统计绿色但探针失败时，状态仍不能判为可用；内部统计异常而探针暂时成功，也要在记录过期前修复。

清空队列会改变待处理状态，却不修复网络、worker或错误CID根因，也不会撤回已经发布的记录。任何破坏性队列操作先导出统计、配置和失败样本，在隔离环境验证后再决定。积压时优先限制新增批量、修复瓶颈并观察收敛。

一份发布可用性报告应同时给出本地保护策略、队列与操作统计、最后成功提供时点、独立findprovs结果和实际读取。只有这条证据链闭合，才能对外说目标内容目前可发现。

提供系统监控要从入队一直走到独立节点发现。固定Kubo版本与provider实现，保存实验接口原始JSON；字段变化时先更新解析器，不能把缺字段补成零继续告警。

资料访问时间为2026-08-07。当前仍需按部署核验：实验字段和Sweep实现仍会演进，仪表盘解析必须容忍新增字段并固定版本。

相关站内主题：bitswap stat、swarm peers、stats bw。本文用于技术教育与节点运维参考，不构成投资、收益或资产安全承诺。