Our Grafana dashboard provides a comprehensive overview of key metrics to help developers and operators ensure optimal performance and reliability of their Ethrex nodes. The only configured datasource today is prometheus, and the job variable defaults to ethrex L1, which is the job configured by default in our provisioning.
Use the network variable (discovered via the consensus config metric) to scope the view by network, then pick one or more instance entries. Every panel honors these selectors. Tip: several panels rely on Grafana transforms such as Organize fields, Join by field, Filter by value, and Group by—keep those in mind if you customize the layout.
Confirms the execution client name and build that each monitored instance is running so you can spot mismatched deployments quickly.
Shows the consensus configuration reported by ethereum-metrics-exporter, helping you verify which network the node is running.
Highlights the active fork reported by ethereum-metrics-exporter, which is a useful signal during planned upgrades.
Row panels showing key block processing metrics across all selected instances.
Tracks how much of the block gas limit is consumed across instances, surfacing heavy traffic or underfilled blocks at a glance.
Charts gigagas per second to compare execution throughput between nodes and reveal sustained load versus isolated spikes.
Plots the head block seen by each instance so you can immediately detect stalled sync or lagging nodes.
Scatter view that ties throughput to the specific block number once all selected instances agree on the same head, making block-level investigations straightforward.
Limitations: This panel only shows data when all selected instances agree on the same head block, and it doesn't handle reorgs gracefully. Here are a couple of things to have in mind when looking at it:
- During reorgs, we might see weird shapes in the data, with lines at a certain block connected to past ones when more than one slot reorgs happen.
- We could see double measurements for the same block number if reorgs on the same block occur.
- Mean could vary when adding or removing instances, as only blocks agreed upon by all selected instances are shown.
Estimates per-block execution time and lines it up with block numbers, helping you correlate latency spikes with particular blocks.
Limitations: This panel has the same limitations as the "Ggas/s by Block" panel above, as it relies on the same logic to align blocks across instances.
Collapsed row that surfaces instrumentation from the add_block_pipeline and execute_block_pipeline timer series so you can understand how each instance spends time when processing blocks. Every panel repeats per instance vertically to facilitate comparisons.
Pie chart showing how execution time splits between storage reads, account reads, and non-database work so you can confirm what are the bottlenecks outside of execution itself.
Tracks how much longer we spend merkleizing versus running the execution phase inside execute_block_pipeline. Values above zero mean merkleization dominates; negative readings flag when pure execution becomes the bottleneck (which should be extremely rare). Both run concurrently and merkleization depends on execution, 99% of the actual execute_block_pipeline time is just the max of both.
Plots execution-stage timers (storage/account reads, execution without reads, merkleization) against the block number once all selected instances report the same head.
Limitations: This panel has the same limitations as the other by block panels, as it relies on the same logic to align blocks across instances. Can look odd during multi-slot reorgs
Collapsed row that surfaces the namespace="engine" Prometheus timers so you can keep an eye on EL <> CL Engine API health. Each panel repeats per instance to be able to compare behaviour across nodes.
Shows how many Engine API calls per second we process, split by JSON-RPC method and averaged across the currently selected dashboard range.
Bar gauge of the historical average latency per Engine method over the selected time range.
Live timeseries that tries to corralate to the per-block execution time by showing real-time latency per Engine method with an 18 s lookback window.
Limitations: The aggregated panels pull averages across the current dashboard range, so very short ranges can look noisy while long ranges may smooth out brief incidents. The live latency chart still relies on an 18 s window for calculate the average, which should be near-exact per-block executions but we can lost some intermediary measure.
Another collapsed row focused on the public JSON-RPC surface (namespace="rpc"). Expand it when you need to diagnose endpoint hotspots or validate rate limiting. Each panel repeats per instance to be able to compare behaviour across nodes.
Pie chart that shows where RPC time is spent across methods over the selected range. Quickly surfaces which endpoints dominate total processing time.
Table listing the highest average-latency methods over the active dashboard range. Use it to prioritise optimisation or caching efforts.
Timeseries showing request throughput broken down by method, averaged across the selected range. Great for checking load distribution after clients roll out new features.
Live timeseries that tries to corralate to the per-block execution time by showing real-time latency per Engine method with an 18 s lookback window.
Limitations: The RPC latency views inherit the same windowing caveats as the Engine charts: averages use the dashboard time range while the live chart relies on an 18 s window.
Row panels showing process-level and host-level metrics to help you monitor resource usage and spot potential issues.
Displays time since the Ethrex process started. [need proper instance labels]
Shows the number of tokio process threads in use. [need proper instance labels]
Reports current file descriptor usage so you can compare against limits. [need proper instance labels]
Time-series view of descriptor usage to spot gradual leaks or sudden bursts tied to workload changes.
Tracks database footprint growth, helping you plan disk needs and confirming pruning/compaction behavior.
Shows effective CPU cores consumed by each instance, separating sustained computation from short-lived bursts.
Follows the resident memory footprint of the Ethrex process so you can investigate leaks or pressure.
Uses node exporter metrics to track whole-host CPU load and distinguish client strain from other processes on the server.
Compares used versus total RAM to highlight when machines approach memory limits and need attention.
This collapsed row offers a combined view of the block building base fee, gigagas per second during payload construction, and the time the builder spends assembling blocks. These panels are works in progress, collapsed by default, and may be refined over time.
