如何评估用于性能监控的以太坊 RPC 服务

在选择以太坊 RPC 提供商之前要衡量什么

如果你正在寻找用于性能监控的最佳以太坊 RPC 服务，你可能不仅仅是在寻找一个返回区块的端点。你可能运行着索引器、监控仪表板或数据管道，这些依赖于对以太坊状态的一致、低延迟访问。真正的问题是：哪家提供商能为你提供早期发现问题所需的可见性和可靠性？

以太坊 RPC 的性能监控不是单次速度测试。它是关于了解提供商在不同工作负载下的行为：高频轮询、长时间运行的 WebSocket 订阅以及昂贵的 trace 调用。本文为你提供了一个评估提供商的实用框架、要跟踪的具体指标，以及如何构建一个有效的监控设置。

快速建议：将提供商与你的监控工作负载匹配

在深入细节之前，这里有一个决策指南，可帮助你缩小选项范围：

• 如果你需要面向用户的 dApp 的低延迟 JSON-RPC，请寻找具有多个区域端点和经过健康检查的负载均衡器的提供商。OnFinality 提供托管以太坊 RPC，支持 HTTP 和 WebSocket，你可以在 https://eth.api.onfinality.io/public 查看公共端点。
• 如果你需要深层历史数据或 trace 级调试，你需要一个启用了 trace_ 和 debug_ 方法的归档节点。并非所有提供商都提供这些，因此在承诺之前请验证方法支持。
• 如果你正在构建依赖 WebSocket 订阅的监控系统，请测试提供商如何处理重连和丢失消息。在负载下丢弃订阅的提供商将破坏你的监控。
• 如果你需要保证生产环境的吞吐量，请考虑专用节点。共享公共端点适合开发，但它们可能受到速率限制或存在噪声。OnFinality 的 专用节点 服务为你提供隔离容量。

有关提供商选择的更广泛介绍，请参阅我们的 RPC 提供商选择指南。

以太坊 RPC 监控的重要指标

在比较以太坊 RPC 服务时，请在有意义的时间段（至少一周）内并在实际负载下跟踪以下性能指标：

用于性能监控和调试的关键方法

不同的监控任务需要不同的 RPC 方法。以下是你在任何提供商处都应测试的方法：

• eth_blockNumber：最简单的健康检查。如果此调用缓慢或失败，则说明有问题。
• eth_getLogs：用于获取合约或主题的事件日志。提供商可能限制单次调用可查询的区块范围。
• eth_subscribe：用于通过 WebSocket 进行实时事件流传输。测试提供商发送新事件的速度以及是否优雅地处理重连。
• trace_transaction（或 debug_traceTransaction）：重放交易以获取详细的执行跟踪。这对于调试失败交易或了解 gas 使用情况至关重要。
• eth_getBlockByNumber（包含完整交易）：对索引有用，但可能很重。检查提供商是否支持而不进行速率限制。

如何构建简单的 RPC 监控探针

你可以编写一个小型脚本，用于监控任何以太坊 RPC 端点的健康状态和延迟。以下是使用 Node.js 和 ethers 库的示例：

const { ethers } = require('ethers');

const url = 'https://eth.api.onfinality.io/public';
const provider = new ethers.JsonRpcProvider(url);

async function checkHealth() {
  const start = Date.now();
  try {
    const blockNumber = await provider.getBlockNumber();
    const latency = Date.now() - start;
    console.log(`Block: ${blockNumber}, Latency: ${latency}ms`);
  } catch (error) {
    console.error('RPC health check failed:', error.message);
  }
}

// Run every 10 seconds
setInterval(checkHealth, 10000);

此脚本为你提供基本的延迟趋势。对于生产环境，你需要跟踪 p95/p99、错误率和 WebSocket 连接。

WebSocket 监控：不要忽视实时数据

如果你的监控依赖于待处理交易或新区块，你需要稳定的 WebSocket 连接。以下是使用 ethers 测试提供商 WebSocket 支持的方法：

const { WebSocketProvider } = require('ethers');

const wsUrl = 'wss://eth.api.onfinality.io/public/ws'; // Replace with actual WebSocket endpoint
const provider = new WebSocketProvider(wsUrl);

provider.on('block', (blockNumber) => {
  console.log('New block:', blockNumber);
});

// Handle disconnects
provider.websocket.on('close', () => {
  console.log('WebSocket closed, reconnecting...');
  // Implement reconnect logic here
});

注意：上述 WebSocket URL 仅用于说明。请查看提供商的文档以获取确切的端点。OnFinality 在其以太坊网络上支持 WebSocket，你可以在 以太坊网络页面 找到正确的 URL。

比较以太坊 RPC 提供商：需要注意什么

当你比较提供商时，你不仅仅是在比较价格。你是在比较运营特性。以下是一个实用的比较框架：

• OnFinality：提供托管以太坊 RPC 服务，支持 HTTP 和 WebSocket 端点。你可以从公共端点开始测试，然后迁移到专用节点用于生产环境。RPC 定价 页面显示了层级，支持的网络 页面列出了所有可用链。
• 其他主要提供商（例如 Infura、Alchemy、QuickNode）也提供以太坊 RPC。它们在免费层级限制、归档数据可用性以及附加功能（如 Mempool 观察或增强 API）方面有所不同。

在评估任何提供商时，请问以下问题：

1. 他们是否提供归档节点？ 如果你需要历史状态，这是不可协商的。
2. 速率限制是多少？ 公共端点通常有严格限制。对于监控，你需要可预测的吞吐量。
3. 是否有 WebSocket 端点？ 它是否可靠地支持订阅？
4. 正常运行时间 SLA 是什么？ 虽然没有提供商能保证 100%，但明确的 SLA 表明信心。
5. 扩展容易吗？ 你能在不更改代码的情况下从共享端点升级到专用节点吗？

以太坊 RPC 监控中的常见陷阱

即使使用好的提供商，你也可能遇到问题。以下是常见陷阱以及如何避免它们：

• 使用单一端点：如果你的监控依赖于一个 RPC URL，你就有一个单点故障。使用多个提供商或至少使用故障转移机制。
• 忽略 WebSocket 重连：如果你的 WebSocket 断开，你可能会错过关键事件。实现带有退避的自动重连。
• 不测试大范围的 eth_getLogs：一些提供商限制区块范围以防止滥用。使用你实际需要的范围进行测试。
• 假设所有提供商都支持 trace 方法：Trace API 是资源密集型的。并非所有提供商都在共享计划上启用它们。在依赖它们之前进行验证。
• 忘记速率限制：即使是付费计划也有限制。监控你的使用情况并在达到上限之前设置警报。

如何设置生产级监控堆栈

对于严肃的监控设置，你需要的不仅仅是一个简单的脚本。以下是一个建议的架构：

1. 健康检查端点：每隔几秒使用轻量级调用（如 eth_blockNumber）来检测中断。
2. 延迟跟踪：记录每个请求的时间，并随时间计算百分位数。
3. WebSocket 订阅监控：订阅新区块，并测量区块时间戳与你收到它之间的延迟。
4. 错误警报：设置错误率超过阈值或任何 429/5xx 响应的警报。
5. 数据冗余：使用至少两个独立的 RPC 提供商来交叉检查数据并提供故障转移。

你可以使用 Prometheus 和 Grafana 等工具来收集和可视化这些指标。关键是有一个基线，以便检测异常。

关键要点

• 以太坊 RPC 的性能监控涉及延迟、吞吐量、WebSocket 稳定性和方法支持，而不仅仅是单次速度测试。
• 选择提供你所需方法的提供商，包括 trace 和归档数据（如果需要）。
• 构建一个同时测试 HTTP 和 WebSocket 端点的监控探针，并随时间跟踪百分位数。
• 使用多个提供商以实现冗余，并制定清晰的故障转移计划。
• OnFinality 提供支持 HTTP 和 WebSocket 的以太坊 RPC，你可以根据需求增长从公共端点扩展到专用节点。

常见问题解答

问：用于性能监控的最佳以太坊 RPC 服务是什么？

答：最佳服务取决于你的具体需求。寻找提供低延迟、高吞吐量、WebSocket 支持以及你所需方法（如 trace）的提供商。OnFinality 是一个值得考虑的选项，你可以根据本文中的标准与其他提供商进行比较。

问：如何测量 RPC 延迟？

答：使用脚本对 eth_blockNumber 等方法进行计时。随时间跟踪 p50、p95 和 p99 延迟，以了解分布情况。

问：监控是否需要专用节点？

答：如果你运行大规模监控系统且请求量高，专用节点可提供可预测的性能。对于小型项目，共享端点可能就足够了。

问：什么是 trace 方法，为什么它们很重要？

答：像 trace_transaction 这样的 trace 方法可以让你查看交易的内部执行情况。它们对于调试复杂的合约交互以及某些监控工具至关重要。

问：如何避免速率限制？

答：选择具有明确速率限制且符合你使用情况的提供商，如果你需要更高吞吐量，请考虑专用节点。监控你的使用情况以保持在限制范围内。