# Envio健康200但数据落后？核按链进度、秒/毫秒与两次指标快照

整理：链小知（AI 辅助）
资料核对日期：2026-10-14
引用地址：https://lianxiaozhi.com/tools/guides/envio-hyperindex-health-progress-lag-bottleneck-check
难度：进阶
核验方式：官方文档整理，未执行真实账户操作

把存活、到头、endBlock完成和等待原因分开，避免将回填速度或旧累计计数当当前实时延迟。

## 使用工具
- [Envio HyperIndex](https://lianxiaozhi.com/tools/envio) · [官方入口](https://envio.dev/)

## 前置条件
- 准备自己已有的脱敏配置、材料或响应记录，保留产品版本、网络、字段和采样时间；缺项保持未知。

## 1. 先分服务存活与数据就绪

/healthz在服务启动后返回200，是liveness，不保证每条链已追到头。按_meta.chainId核progressBlock、eventsProcessed、bufferBlock、sourceBlock、isReady、readyAt和endBlock；progressBlock与eventsProcessed在批写事务中一起进入数据库，buffer/source/ready字段在事务外节流更新，可能稍晚。

核对结果：健康200、数据库进度与节流元数据分列；按同一chainId判状态。
依据：[Envio：健康探针、链状态与Prometheus字段](https://docs.envio.dev/docs/HyperIndex/observability.md)

## 2. 区分到头和有限历史完成

isReady/readyAt表示完成历史同步或达到endBlock，不必然持续实时更新。v3.12新增envio_progress_block_time_seconds与_meta.progressBlockTime，用已处理块的时间戳判now()-progress_block_time；达到endBlock会冻结该值，须排除实时lag告警。旧实例或总览样例缺新字段时保持未知，不能用块高代填时间；进度延迟envio_progress_latency单独以毫秒报。

核对结果：endBlock、运行版本、块时间和采样时钟清楚；秒与毫秒没有混算。
依据：[Envio：健康探针、链状态与Prometheus字段](https://docs.envio.dev/docs/HyperIndex/observability.md)
依据：[Envio：9月更新的progressBlockTime与endBlock边界](https://docs.envio.dev/blog/developer-update-september-2026)

## 3. 两次快照算同链回填吞吐

用自己已有的两次envio_progress_events和envio_process_elapsed_seconds快照，吞吐=(事件数差)/(运行秒差)。官方样例158205到262000、45.8到105.8秒，约1730事件/秒；这是样例而非本人性能。两次须同一未中断运行、相同chainId；全索引器先各快照按链相加再做差。重启重置elapsed，回滚或计数下降需重新核基线；到头后的低吞吐反映新块供给，不适合作回填性能结论。

核对结果：版本/chainId与进程连续性有记录；差值和分母有效，样例未当实测。
依据：[Envio：同一次运行的吞吐与瓶颈基准](https://docs.envio.dev/docs/HyperIndex/benchmarking.md)
依据：[Envio：健康探针、链状态与Prometheus字段](https://docs.envio.dev/docs/HyperIndex/observability.md)

## 4. 把累计等待转成比例或区间速率

envio_processing_stalled_on_fetch_seconds指无事件可处理的获取等待，特意排除到头等新块；stalled_on_storage_write_seconds指写队列过多导致处理暂停。两者是累计秒，官方可除process_elapsed_seconds看整段运行份额，或用同区间差分/Prometheus rate看当前变化。再结合storage_write_seconds、source_request_seconds_total的source/chainId标签，不把累计大数直接当当前慢或把并行耗时比例当互斥份额相加。

核对结果：累计值、整段份额与区间速率分别标注；等待原因对应字段和标签。
依据：[Envio：健康探针、链状态与Prometheus字段](https://docs.envio.dev/docs/HyperIndex/observability.md)
依据：[Envio：同一次运行的吞吐与瓶颈基准](https://docs.envio.dev/docs/HyperIndex/benchmarking.md)

## 5. 同范围比较后再决定下一步

保存待核瓶颈及官方建议方向：获取慢核数据源与并发，写入慢核实体更新和数据库，handler慢核每次调用时间。比较修正前后要同块范围、相似事件构成并一次只改一个因素；内存/GC上升可能只是延后工作。Cloud与本地基准不能直接互代，Development最多30天且无可用性/持久性保证，缺前后快照或本人服务条件时不宣称问题已解决。

核对结果：范围、事件构成、单项变化与运行环境已对齐；缺后验时保留待验证结果。
依据：[Envio：同一次运行的吞吐与瓶颈基准](https://docs.envio.dev/docs/HyperIndex/benchmarking.md)
依据：[Envio：健康探针、链状态与Prometheus字段](https://docs.envio.dev/docs/HyperIndex/observability.md)
依据：[Envio Cloud：开发环境寿命、付费与取消](https://docs.envio.dev/docs/HyperIndex/hosted-service-billing.md)

## 常见错误
- progress_latency是已处理事件到存储的毫秒延迟，不等所有链头年龄。
- 仅看供应商性能倍数、运行累计时间或健康探针，无法定位当前数据滞后。

## 完成检查
- 保存输入、字段/单位、判定结果及待核差异；官方方法已核，实际客户端行为和本人服务权限未验证。

## 相关知识

## 官方依据
- [Envio：健康探针、链状态与Prometheus字段](https://docs.envio.dev/docs/HyperIndex/observability.md)
- [Envio：同一次运行的吞吐与瓶颈基准](https://docs.envio.dev/docs/HyperIndex/benchmarking.md)
- [Envio：9月更新的progressBlockTime与endBlock边界](https://docs.envio.dev/blog/developer-update-september-2026)
- [Envio Cloud：开发环境寿命、付费与取消](https://docs.envio.dev/docs/HyperIndex/hosted-service-billing.md)