误区一：接口可访问就代表节点正常
接口能返回响应，只能说明请求链路在当时可用，不能单独证明节点已经同步，也不能证明依赖它的业务数据完整。监控应区分服务可访问、链数据更新和业务查询可用，避免用一个在线标记概括所有状态。
以太坊节点文档说明，节点由执行客户端与共识客户端协作运行，验证者软件则是可选组件。因此，适用于这类架构的监控需要覆盖两类客户端及其协作状态；没有运行验证者，不等于节点异常。
误区二：区块高度增长就说明同步完成
比特币 getblockchaininfo 接口区分已验证区块高度 blocks 与已验证区块头数量 headers，并提供验证进度估计 verificationprogress 和初始区块下载状态估计 initialblockdownload。这些字段描述不同侧面，不能互相替代。
高度持续增长也可能是节点仍在追赶历史数据。判断时应结合字段之间的差异及持续变化，而不是仅看一次采样。进度估计接近完成，也不应被解释为所有查询能力都已就绪。具体字段与返回格式应按实际客户端版本核对。
误区三：全节点必然保存全部历史状态
以太坊节点文档区分全节点与归档节点，历史状态保存能力是重要差别。完整验证能力不等于所有历史状态都能立即从本地读取。
对于需要历史状态查询的系统，监控应单独检查所需数据是否可用。历史查询失败时，需要区分数据保留策略、查询能力限制与运行故障，不能一律归为节点宕机，也不能把归档能力当作所有监控场景的必需条件。
误区四：节点统计就是全网真实规模
以太坊节点文档明确指出，去中心化网络中的爬虫只能获得有限视图，不同追踪工具可能给出不同结果。因此，监控页面上的节点数量应被理解为特定观测范围内的结果，而非完整清单。
比较统计结果时，应核对观测对象和统计口径。单一观测源发现的节点减少，不足以独立证明全网发生故障；同样，本地节点正常也不足以证明整个网络正常。
常见问题：能否用统一规则监控所有链
可以统一服务可用性、数据新鲜度和查询成功率等监控维度，但不能直接照搬字段含义或判定条件。以太坊的双客户端架构与比特币的链处理状态接口，并不是同一套健康模型。
告警规则应说明适用网络、客户端版本、节点用途与数据保留模式，并区分单次异常和持续异常。监控系统提供的是定位问题的证据，不是对全网安全或业务正确性的绝对保证。