Envio健康200但数据落后？核按链进度、秒/毫秒与两次指标快照
链小知 · 进阶 · 核验 · 依官方文档整理
把存活、到头、endBlock完成和等待原因分开，避免将回填速度或旧累计计数当当前实时延迟。
开始前准备
- 准备自己已有的脱敏配置、材料或响应记录，保留产品版本、网络、字段和采样时间；缺项保持未知。
1. 先分服务存活与数据就绪
/healthz在服务启动后返回200，是liveness，不保证每条链已追到头。按_meta.chainId核progressBlock、eventsProcessed、bufferBlock、sourceBlock、isReady、readyAt和endBlock；progressBlock与eventsProcessed在批写事务中一起进入数据库，buffer/source/ready字段在事务外节流更新，可能稍晚。
检查结果：健康200、数据库进度与节流元数据分列；按同一chainId判状态。
2. 区分到头和有限历史完成
isReady/readyAt表示完成历史同步或达到endBlock，不必然持续实时更新。v3.12新增envio_progress_block_time_seconds与_meta.progressBlockTime，用已处理块的时间戳判now()-progress_block_time；达到endBlock会冻结该值，须排除实时lag告警。旧实例或总览样例缺新字段时保持未知，不能用块高代填时间；进度延迟envio_progress_latency单独以毫秒报。
检查结果：endBlock、运行版本、块时间和采样时钟清楚；秒与毫秒没有混算。
3. 两次快照算同链回填吞吐
用自己已有的两次envio_progress_events和envio_process_elapsed_seconds快照，吞吐=(事件数差)/(运行秒差)。官方样例158205到262000、45.8到105.8秒，约1730事件/秒；这是样例而非本人性能。两次须同一未中断运行、相同chainId；全索引器先各快照按链相加再做差。重启重置elapsed，回滚或计数下降需重新核基线；到头后的低吞吐反映新块供给，不适合作回填性能结论。
检查结果：版本/chainId与进程连续性有记录；差值和分母有效，样例未当实测。
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标签，不把累计大数直接当当前慢或把并行耗时比例当互斥份额相加。
检查结果：累计值、整段份额与区间速率分别标注；等待原因对应字段和标签。
5. 同范围比较后再决定下一步
保存待核瓶颈及官方建议方向：获取慢核数据源与并发，写入慢核实体更新和数据库，handler慢核每次调用时间。比较修正前后要同块范围、相似事件构成并一次只改一个因素；内存/GC上升可能只是延后工作。Cloud与本地基准不能直接互代，Development最多30天且无可用性/持久性保证，缺前后快照或本人服务条件时不宣称问题已解决。
检查结果：范围、事件构成、单项变化与运行环境已对齐；缺后验时保留待验证结果。
怎样确认完成
- 保存输入、字段/单位、判定结果及待核差异；官方方法已核，实际客户端行为和本人服务权限未验证。
常见错误与边界
- progress_latency是已处理事件到存储的毫秒延迟，不等所有链头年龄。
- 仅看供应商性能倍数、运行累计时间或健康探针，无法定位当前数据滞后。