生产跑 Solana 应用,监控告诉你东西是不是真在工作。大多数团队在 RPC 侧具体监控不够——他们看 app 面向用户的指标,但没有决定交易是否真上链的那一层 RPC 可见性。这篇覆盖跟踪什么、为什么、把不透明 RPC 行为变成可行可见性的仪表板。
"RPC 监控"实际意味什么
三类监控:
服务商侧服务器指标。 RPC 服务商该暴露延迟仪表板、错误率、容量。质量看服务商。
应用侧客户端指标。 你 app 调 RPC 时看到的。P50/P95/P99 延迟、错误率、重试率。
结果侧指标。 交易实际上链了吗?什么价格?成本是什么?
生产可观测性,三个都要。服务商侧告诉容量;客户端侧告诉你体验;结果侧告诉应用是不是真在工作。
重要指标
延迟百分位。 不是平均。RPC 调用 round-trip 延迟 P50、P95、P99。随时间跟踪。
错误率。 RPC 调用什么百分比失败?按错误类型拆。
重试率。 你代码多频繁重试?高重试率暗示底层问题。
提交成功率。 多少 sendTransaction 调用返回签名无错?
上链率。 多少提交交易实际链上上链(跟"提交成功"不同)。
负载下尾部延迟。 高峰时段 P99 延迟。跟非高峰对比。
每笔上链交易成本。 总费 + tip ÷ 成功发送数。
三明治被夹敞口。 交易负载。AMM 数学预期 vs 实际 fill。
连接池统计。 高量代码。池大小、用中连接、等待时间。
每笔交易该跟踪什么
每笔提交交易记录:
- 时间戳
- 签名
- 设的 Compute budget
- 设的 Priority fee
- 用的 blockhash
- 提交延迟(HTTP round-trip)
- 确认结果(上链、失败、过期)
- 确认延迟(签名到上链)
- 包含的 slot
- 付的费(消耗 CU × CU 价格 + 基础)
- 付的 tip(Jito 或其他)
- 设的滑点容差
- 实际收到的输出(swap)
- 预期的输出(swap)
- 失败的错误码
这就是每笔签名级别的遥测。没有它,你既没法 debug 具体的失败、也没法做聚合性能分析。
搭遥测
合理的 schema(TypeScript):
interface TxTelemetry {
signature: string;
submittedAt: number;
landedAt?: number;
outcome: 'pending' | 'landed' | 'failed' | 'expired';
errorCode?: string;
cuLimit: number;
cuPrice: number;
tipLamports?: number;
blockhash: string;
slot?: number;
feesPaid?: number;
intent: 'swap' | 'transfer' | 'mint' | string;
expectedOutput?: number;
actualOutput?: number;
}
存数据库或日志聚合(Datadog、Honeycomb、ELK、自定义)。最少保留 30 天给趋势分析。
高量机器人,可能抽样(完整详情日志 1% 交易;聚合其他)。低量 app,记一切。
有用的仪表板
一小套仪表板覆盖大多数需求:
延迟仪表板。 提交和确认延迟 P50/P95/P99。随时间趋势。多 RPC 就分开看。
错误拆解。 按类型分类失败。具体错误类型峰值信号环境问题。
成本仪表板。 每笔上链交易费 + tip。随时间趋势。对比收入(交易负载)。
三明治被夹敞口仪表板(交易)。 预期和实际 fill 间平均差距。趋势。
容量仪表板。 连接池利用率、每秒请求、重试率。告诉你是不是撞限。
结果漏斗。 提交 → RPC 接受 → 上链 → 盈利(交易)。交易在哪掉?
告警
值得告警的:
P95 延迟 > 阈值。 你负载特定。HFT 亚秒级;通用 app 几秒。
错误率峰值。 任何具体错误类别突然增加。
上链率掉。 成功上链突然减少。
三明治被夹敞口峰值。 交易,预期 vs 实际差距突然增加。
成本峰值。 一段时期总成本超预期。
服务商问题。 服务商侧状态页或你自己的探针。
具体自定义异常。 每个 app 有独特的值得告警的条件。
别什么都告警。告警在"有人需要醒"的条件上。其他都去仪表板。
常见监控错误
监控平均而不是百分位。 平均延迟不告诉你生产行为什么。
只监控成功。 出错的比对的更信息丰富。
轮询而不是推。 把日志拉进仪表板慢;从你应用推。
没告警计划。 你收集指标但没人看,直到东西坏。
告太多。 狼来了的告警会被忽略。
不保留历史。 不存够 30 天以上,就没法做趋势分析、也没法跟 baseline 对比。
没每笔签名级别粒度。 聚合指标告诉你"东西错了";每笔签名级别告诉你"什么错了"。
这周可以做什么
改善监控:
- 从每笔签名级别遥测开始。 这是基础;其他都从它聚合。
- 搭延迟仪表板。 随时间 P50/P95/P99。
- 搭错误拆解。 分类失败率。
- 设基础告警。 P95 延迟、错误率峰值、上链率掉。
- 看数据。 趋势、baseline、异常。数据只有你真看时才有用。
- 把"正常"长什么样写下来。 有了 baseline 你才能识别异常。
- 迭代。 学到什么重要就加指标。
BoltTx 提供什么
BoltTx 在它侧暴露监控数据:
- 每笔签名级别投递遥测——每笔交易、每步何时发生
- 延迟仪表板——随时间 P50/P95/P99
- 错误拆解——什么失败、为什么
- 每客户隔离,让你指标不被别人流量污染
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
你组合 BoltTx 服务商侧数据和你应用侧遥测,得到完整可观测性。免费档注册——免费档可用遥测。
常见问题
最少监控配置什么? 每笔签名级别遥测 + 延迟仪表板 + 基础告警(P95 延迟、错误率)。再少就没法跑生产了。
该保留数据多久? 最少 30 天给趋势分析。要 debug 重复问题就更长。
该自己搭仪表板还是用 SaaS? 大多数团队 SaaS(Datadog、Honeycomb、Grafana Cloud)。重大规模才自己写。
Solana RPC 正常 P95 延迟什么? 看负载和 RPC。交易发送亚秒级可达。读延迟变化更多。
怎么知道我被夹了? 对比 swap 的 AMM 数学预期输出和实际输出。系统性差距 = 三明治被夹敞口。