先读指标名称及其类型
一张区块链TPS指标图如果只保留数字而删掉字段名，可能连统计对象都说不清。Caliper 0.7.1监控文档分别列出caliper_tx_submitted、caliper_tx_finished这两个counter，以及caliper_tx_e2e_latency这个histogram。提交、完成与延迟不是同一个量，也不能共用一个没有解释的“性能值”列。
本文只讨论读取监控记录，不运行负载或访问任何节点。尤其不要仅凭finished这个字段名，就自行加上“业务全部成功”“已达最终性”等解释。报告还需要交代完成判定和连接器的统计范围；缺少这类上下文时，保留原字段比替它下结论更准确。
累计值不能直接当作每秒值
Prometheus把counter说明为累计计数：它通常只增加，也可能在重启时归零。因此，某一时刻读到1200，不能直接标成1200 TPS。讨论一段区间的平均速率，首先需要明确同一条序列在区间内增加多少，以及区间实际持续多久。
假设一份完整教学记录在相隔60秒的两次采样中，从1200增加到1320，且明确期间没有重置、口径变化或缺失，则这段区间增加120，平均每秒增加2。这只是算术示意。如果第二次反而变成20，就不能简单写成负吞吐量；应先调查重启或序列变化，也不要凭两个点编造重置之前丢失的增长量。
合并数据前对齐轮次与工作进程
Caliper这份文档列出了roundLabel、roundIndex和workerIndex等默认标签，用来区分测试轮次和上报工作进程。看起来同名的指标，可能属于不同轮次或不同worker。导出数据时一并保留标签，才能判断两行数据是不是本来就该放在一起。
例如，同一窗口内两个各自负责不同交易的worker分别新增60和90，确认统计范围不重叠后才可讨论合计150。若只是同一序列被重复导出了两份，相加就会重复计算。这里的独立性须来自报告说明，而不是靠worker编号看起来不同来猜测；上一轮累计值也不能直接接到下一轮当作连续增长。
延迟分桶也不能冒充完成速率
Prometheus文档区分counter与histogram，并说明经典直方图的桶是按上界累计的：较小桶中的观测也会包含在更大桶中。因而不能把各桶数直接相加当作不同请求总数。若要读延迟分布，应先确认直方图类型、桶边界和单位，不把桶计数画成每秒成功交易数。
整理一张可复核的表，可以保留原指标名、类型、完整标签、起止时刻、原值、派生结果和缺失说明。这个清单是本文的阅读建议，不是工具自动生成的验收结论。把累计量、速率和延迟分开之后，仍需了解业务负载与测试环境；本文没有任何公链排名、本站实测成绩或长期容量保证。