RPC 节点监控：指标、告警与故障转移

RPC 节点监控的实际含义

RPC 节点监控是持续测量区块链 JSON-RPC 端点和底层节点的健康、性能和可用性的实践。它回答三个问题：端点是否可达？它是否响应正确？对于您的应用程序来说是否足够快？

监控不仅仅是关于正常运行时间。节点可能在线但落后于链尖，返回过时数据，或对您的请求进行限流。有效的监控既跟踪节点的内部状态（同步状态、对等节点数量），也跟踪外部服务质量（延迟、错误率）。

本指南侧重于实际方面：要收集哪些指标，如何使用 Prometheus 和 Grafana 收集它们，如何设置健康检查和告警，以及如何使用监控来驱动故障转移决策。它适用于任何 EVM 链（以太坊、Polygon、BSC）和 Solana，节点特定指标略有差异。

• 关键监控类别：可用性、性能、正确性和容量。
• 两层：节点级指标（通过导出器）和端点级指标（通过合成探针）。
• 监控支持主动事件响应，并为故障转移逻辑提供信息。

每个 RPC 节点应跟踪的关键指标

您收集的指标取决于您的链和您的角色（节点运营商 vs. 应用程序开发人员）。至少，您需要以下类别。

可用性：端点是否可达？这通常是简单的 TCP 或 HTTP 检查。对于 JSON-RPC，您可以发送一个轻量级方法，如 eth_blockNumber（EVM）或 getHealth（Solana），并期望在超时内得到有效响应。

延迟：测量完成请求的时间，通常以百分位数报告：p50、p95、p99。高 p99 延迟表示响应缓慢，可能导致应用程序超时。使用像 curl -w 这样的工具从您的位置测量，但对于持续监控，请使用合成探针或记录请求持续时间的 Prometheus 导出器。

错误率：返回错误的请求百分比。对于 JSON-RPC，错误包括 HTTP 5xx、JSON-RPC 错误代码（例如 -32000 服务器错误）和超时。错误突然激增通常表明节点问题或网络问题。

429 速率：HTTP 429 太多请求响应的速率。这是限流的迹象，无论是来自您的提供商还是来自您自己节点的连接限制。如果处理不当，高 429 速率可能导致应用程序故障。

同步状态：对于全节点，节点必须与链尖同步。对于 EVM，您可以将节点的最新区块号与已知参考（例如公共浏览器）进行比较。对于 Solana，使用 getHealth 和 getSlot 检查节点是否落后。

资源使用情况：CPU、内存、磁盘 I/O 和网络带宽。这些对于节点运营商规划容量和检测磁盘填充等问题至关重要。

• 对于 EVM：eth_blockNumber、eth_syncing、net_peerCount。
• 对于 Solana：getHealth、getSlot、getClusterNodes。
• 始终跟踪成功和失败响应，并记录延迟百分位数。

如何使用 Prometheus 收集指标

Prometheus 是抓取和存储时间序列数据的事实标准。要监控您的 RPC 节点，您需要一个以 Prometheus 格式公开指标的导出器。有几种方法：

使用节点导出器：许多区块链节点原生公开 Prometheus 指标。例如，Geth（以太坊）有一个 --metrics 标志，可以启用 HTTP 端点。Solana 验证器通过 solana-metrics（InfluxDB）公开指标，但您可以使用像 solana-exporter 这样的 Prometheus 导出器。

使用通用 JSON-RPC 导出器：像 json-rpc-exporter 或 prometheus-json-exporter 这样的工具可以抓取任何 JSON-RPC 端点并将响应转换为指标。这对于从外部监控端点而不接触节点很有用。

编写自定义导出器：为了完全控制，您可以编写一个小脚本，查询节点并公开指标。这对于跟踪应用程序特定指标（如交易成功率）很常见。

一旦有了导出器，配置 Prometheus 定期抓取它（例如每 15 秒）。以下是一个最小的 prometheus.yml 示例：

scrape_configs:
  - job_name: 'rpc-node'
    static_configs:
      - targets: ['localhost:9090']  # exporter address
    metrics_path: /metrics
    scrape_interval: 15s

设置 Grafana 仪表盘以监控 RPC 健康

Grafana 可视化 Prometheus 数据，并允许您构建仪表盘，一目了然地显示 RPC 端点的健康状况。您可以为每个指标创建面板：延迟百分位数、错误率、429 速率、同步状态和资源使用情况。

一个好的 RPC 仪表盘包括：

延迟图：p50、p95 和 p99 延迟的时间序列。使用热图查看随时间变化的分布。

错误率面板：显示返回错误的请求百分比的图表。颜色编码阈值（例如 >1% 红色）。

429 速率面板：每秒 429 响应的图表。这有助于您检测限流问题。

同步状态面板：对于 EVM，显示 eth_syncing 结果（如果同步则为 false）。对于 Solana，显示节点槽位与集群最大槽位之间的差异。

资源使用面板：来自节点导出器的 CPU、内存、磁盘和网络 I/O。

您还可以在 Grafana 中设置告警规则，当指标超过阈值时通过 Slack、电子邮件或 PagerDuty 通知您。例如，如果 p99 延迟超过 2 秒持续 5 分钟，或错误率超过 5% 持续 1 分钟，则发出告警。

• 使用 Grafana 的告警功能向您的团队发送通知。
• 为不同的链或环境创建单独的仪表盘。
• 使用 Grafana 的公共仪表盘功能与您的团队共享仪表盘。

健康检查和合成探针

健康检查是简单、频繁的请求，用于验证端点是否存活并正确响应。它们是正常运行时间监控和故障转移的基础。您可以通过两种方式实现健康检查：

主动健康检查：您的监控系统定期（例如每 30 秒）向端点发送请求，并期望得到有效响应。对于 EVM，使用 eth_blockNumber；对于 Solana，使用 getHealth。如果请求失败或超时，则将端点标记为不健康。

被动健康检查：您的应用程序在正常操作期间监控它收到的响应。如果它看到高错误率或重复超时，它可以标记端点不健康。这对于故障转移很有用，因为它反映了真实的用户体验。

合成探针更进一步，通过模拟真实的用户请求，例如发送交易或查询特定合约。这可以捕获简单健康检查遗漏的问题，例如节点在线但返回错误数据。

例如，您可以使用像 curl 这样的工具从 cron 作业执行健康检查：

curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
  -X POST https://your-rpc-endpoint \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

异常告警：需要注意什么

告警是监控和行动之间的桥梁。您需要定义指示问题的阈值，然后通知合适的人员。常见的告警规则包括：

端点宕机：健康检查失败超过 1 分钟。这触发立即调查。

高延迟：p99 延迟超过 2 秒持续 5 分钟。这可能表明节点过载或网络问题。

错误率激增：错误率超过 5% 持续 1 分钟。这可能是节点崩溃、网络分区或应用程序中的错误。

429 速率增加：429 响应超过阈值，表明您被限流。这可能要求您减少请求量或切换到不同的端点。

同步滞后：节点落后于链尖超过 10 个区块（EVM）或 100 个槽位（Solana）。这对于需要最新数据的应用程序至关重要。

资源耗尽：磁盘使用率 > 90%，内存 > 90%，或 CPU > 80% 持续 10 分钟。这有助于您在节点失败之前规划容量。

设置阈值时，请考虑应用程序的容忍度。DeFi 交易机器人可能需要 p99 < 500ms，而区块浏览器可以容忍 2 秒。使用历史数据设置现实的基线。

• 使用 Prometheus 告警规则或 Grafana 告警。
• 在告警通知中包含 runbook 链接。
• 通过故意制造故障（例如停止节点）来测试您的告警。

使用故障转移构建高可用性

监控只有在您采取行动时才有用。RPC 端点的高可用性（HA）意味着即使一个端点失败，您的应用程序也能继续运行。核心思想是拥有多个端点和一个故障转移机制，将流量路由到健康的端点。

多个端点：使用至少两个独立的 RPC 端点，最好来自不同的提供商或不同区域的自托管节点。这降低了单点故障的风险。

基于健康检查的路由：您的应用程序或负载均衡器应定期检查每个端点的健康状态，并仅将流量路由到健康的端点。这可以通过简单的脚本或像 HAProxy 或 Envoy 这样的服务来完成。

自动故障转移：当端点变得不健康时，系统应自动切换到下一个可用端点。这需要频繁运行的健康检查（例如每 10 秒）和快速反应的 routing 层。

负载均衡：将请求分发到多个端点，以避免过载任何一个。这还可以通过使用最近的端点来改善延迟。

重试逻辑：在您的应用程序中，当请求失败时实现指数退避的重试。这可以处理瞬时错误，而无需立即故障转移。

例如，您可以使用一个简单的 Python 脚本检查健康并更新 DNS 记录或负载均衡器配置。或者您可以使用像 OnFinality 的 RPC Assistant 这样的服务，它提供具有内置故障转移和监控的托管端点。有关详细信息，请参阅我们的 how to choose an RPC provider。

• 始终拥有至少两个来自不同提供商的端点。
• 使用健康检查驱动故障转移，而不仅仅是用于告警。
• 通过模拟端点故障定期测试故障转移。

常见陷阱及如何避免

即使有监控，也有常见的错误可能会破坏您的努力：

仅从一个位置监控：如果您从单个区域监控，您可能会错过影响其他区域用户的问题。使用多个监控位置或像 UptimeRobot 这样的服务。

忽略 429 响应：限流是 RPC 失败的常见原因。如果您看到 429，您需要减少请求速率或从提供商处获得更高的配额。

不监控同步状态：落后于链尖的节点将返回过时数据，这可能比停机更糟糕。始终监控同步状态。

告警疲劳：设置过低的阈值会导致过多告警，导致告警疲劳。使用严重性级别，并仅对可操作的问题发出告警。

不测试故障转移：如果您有故障转移但从未测试过，它可能无法在您需要时工作。定期模拟故障，以确保您的系统按预期运行。

忘记安全：监控端点可能暴露敏感信息。确保您的监控仪表盘受到保护，并且不要记录敏感请求数据。

• 使用多个监控位置以实现全球覆盖。
• 为不同的严重性级别设置单独的告警。
• 记录您的故障转移程序并进行演练。

后续步骤：从监控到托管解决方案

一旦您有了监控和故障转移设置，您可以考虑是构建和维护自己的基础设施，还是使用托管的 RPC 提供商。像 OnFinality 这样的托管提供商提供内置监控、高可用性和故障转移，节省您的运维开销。

如果您选择自托管，您将需要处理节点升级、安全补丁和扩展。这可能很耗时，但给您完全控制权。如果您更愿意专注于您的应用程序，托管提供商可能是更好的选择。

要了解有关选择自托管和托管 RPC 的更多信息，请参阅我们的指南 如何选择 RPC 提供商。有关特定链的详细信息，请查看我们的 Solana RPC 端点 和 以太坊网络页面。

如果您遇到延迟问题，我们的文章 减少 RPC 延迟 可以提供帮助。对于超时错误，请参阅 如何修复 RPC 超时错误。如果您正在比较公共和专用端点，请阅读 公共 RPC 端点与专用。

最后，考虑使用 OnFinality 的 API 服务 获得完全托管的解决方案，内置监控和故障转移。我们的 定价 透明，您可以从免费层开始。

• 评估自托管与托管服务的成本。
• 利用现有工具，如 Prometheus 和 Grafana，用于自托管设置。
• 探索 OnFinality 的托管 RPC 用于生产工作负载。