Exporter
A metric-to-RPC map for Solana validator monitoring and alert design.
A Solana exporter is a service that collects validator or RPC state and exposes it as Prometheus metrics for dashboards and alerts. A useful exporter maps each metric to the RPC call that produced it, so operators can validate a dashboard independently and understand what an alert actually means.
The Asymmetric Research Solana exporter provides the exporter implementation. When Kubernetes is the right delivery model, limit the RPC endpoint, validator identities, and optional collectors to the metrics needed by the environment.
| Metric family | RPC source | What it answers |
|---|---|---|
| Node health | getHealth | Is the RPC reporting healthy? |
| Validator and vote accounts | getVoteAccounts | Is the validator present, voting, delinquent, and carrying the expected stake? |
| Epoch progress | getEpochInfo | Which epoch is active, how far through it is, and how much time/slot budget remains? |
| Block production | getBlockProduction | Is the validator producing expected blocks and missing assigned slots? |
| Slot rate and local progress | getSlot, sampled over time | Is the node advancing at the expected observed pace? |
| Identity and version | getIdentity, getVersion | Is the exporter querying the intended node and client build? |
| Retention boundary | minimumLedgerSlot, getFirstAvailableBlock | How far back can this node serve local ledger data? |
| Balances, rewards, leader work | getBalance, getInflationReward, getLeaderSchedule, and getBlock when block-size monitoring is enabled | Are funded accounts, rewards, leader slots, and optional block-size data behaving as expected? |
This metric design does not require getRecentPerformanceSamples. If that RPC is useful for a particular dashboard, add a separate, versioned collector and document its collection interval, cost, and failure behavior rather than assuming a standard exporter already emits it.
Collection design
Use a dedicated, authenticated RPC endpoint for monitoring when possible. Poll low-frequency state such as epoch information and version compliance less often than health and slot lag. Cache responses only when the metric definition records the cache age; a dashboard should never present stale data as current health.
Each metric should include labels only for stable, low-cardinality dimensions such as cluster, validator identity, RPC endpoint class, and environment. Do not label metrics with transaction signatures, account addresses, or arbitrary error text; that can overload Prometheus and make the exporter itself a reliability problem.
Derived metrics
The raw RPC response is not always the operational signal. Useful derived metrics include:
| Derived metric | Calculation | Why it helps |
|---|---|---|
| Slot lag | reference finalized slot minus local finalized slot | Detects a node that is reachable but falling behind. |
| Epoch completion | elapsed slots divided by slots in epoch | Adds context to leader schedule and maintenance timing. |
| Block-production ratio | produced blocks divided by leader slots | Highlights degraded validator performance. |
| Vote-account delinquency | vote account absent from current validator set or marked delinquent | Turns a complex RPC response into a clear operator signal. |
| Observed slot rate | successive getSlot samples divided by their elapsed time | Detects network or node behavior changes without relying on one point-in-time value. |
Choose the reference endpoint carefully. Comparing a private development cluster to a public mainnet endpoint is meaningless; use an agreed healthy peer in the same cluster.
Alert rules should cover
- RPC health failing beyond a short transient period.
- Processed/finalized slot lag exceeding the environment’s threshold.
- Validator becoming delinquent or missing a sustained number of leader slots.
- Upcoming version or feature compliance risk.
- Ledger/accounts disk pressure and snapshot failures.
- Notification delivery failure.
Alert design
An alert should name the affected validator or RPC endpoint, show the observed and reference slots, identify the environment, and include the next diagnostic command. Avoid triggering on a single failed sample. A useful starting pattern is a warning for sustained lag and a critical alert only when the lag continues to grow or the service becomes unavailable.
Pair every rule with an owner and a suppression policy for planned maintenance. Otherwise routine upgrades become noisy and real incidents become easier to ignore.
Dashboards and rules
This documentation includes a reusable Grafana dashboard JSON and Prometheus alert rules. They use variables and generic labels; adapt the job, identity, slot-lag threshold, storage mount regex, and notification routing to the target environment before deployment.
A screenshot is not an operational artifact. Keep the dashboard and alert rules versioned with your documentation and review them as the exporter evolves.
Validate the exporter independently
When a metric looks wrong, query the same RPC method manually before changing the dashboard or alert threshold. An exporter may support node and vote keys, balance addresses, active-identity detection, light mode, comprehensive slot tracking, and optional block-size monitoring. The last two can substantially increase Prometheus cardinality or RPC work, so enable them deliberately. Exporters should expose their scrape errors and last-success timestamp so an absent metric can be distinguished from a healthy zero value.