Build your own dashboards

This page explains how to create your own dashboards using StereumLabs data and conventions. It covers data access, custom labels, and ready-to-use PromQL examples.

If you need the standard dashboards instead, see the Dashboards Catalog.

Private Grafana org

Pro and Enterprise customers get a private Grafana organization. The datasources and dashboards described below are provisioned into your org. Dashboard and datasource UIDs are unique per org, so this page references everything by name. Use the Grafana UI to find specific UIDs when you need them.

Goals

Enable operators, client teams, and researchers to tailor views to their needs.

What you can build

• Operator views: resource saturation, headroom, alert-focused panels.
• Client team views: pipeline timings (import/execute/write), DB/FS behavior.
• Research views: propagation, mempool dynamics, reorg signals (non-staking).
• Environment studies: cloud vs. bare-metal profiles, kernel/filesystem tuning impact.

Staking-focused panels (participation, inclusion delay, missed duties) will be documented separately when available. See Roadmap.

Data access

StereumLabs provisions a consistent set of datasources into each customer's Grafana org. Which ones you can query depends on your plan. See Plans.

Datasource name	Type	Plan	What it holds
Public Prometheus	Prometheus	All tiers	A small set of recording rules (delayed by 7 days), 90-day retention.
Full Prometheus	Prometheus	Pro, Enterprise	The full metric set, no retention or delay restriction. Default datasource on Pro/Enterprise orgs.
Elasticsearch	Elasticsearch	Pro, Enterprise	Container logs from every EC and CC instance, shipped via Filebeat. INFO level retained for ~30 days; DEBUG level retained for a shorter window.
Run-manifest metadata	(varies)	Enterprise	Per-run metadata, scenario specs, VM lineage.

Scrape interval: 15 seconds across all jobs. End-to-end latency from exporter to query is typically 25 to 30 seconds on the full Prometheus tier.

Active scrape jobs cover every supported client (besu, erigon, ethrex, geth, nethermind, reth, grandine, lighthouse, lodestar, nimbus, prysm, teku, caplin) plus node_exporter on every host.

StereumLabs custom labels

To keep dashboards portable across clients, we apply a consistent set of labels on Prometheus metrics:

Label	Values	Meaning
ec_client	besu, erigon, ethrex, geth, nethermind, reth	Execution client name.
ec_version	e.g., v3.4.1, 26.4.0	Execution client version.
cc_client	grandine, lighthouse, lodestar, nimbus, prysm, teku (or <name>-super for supernodes)	Consensus client name.
cc_version	e.g., v7.1.3, v8.1.3	Consensus client version.
role	ec, cc, standalone	Which layer this host runs. standalone is for Caplin (EL + CL in one binary).
deployment	NDC2, GCP	Hosting environment.
location	Vienna/Austria, europe-west3-a	Geographic placement / cloud region.

Scenario / config label

A tba_config_name (or equivalent) label to identify specific scenarios (custom VM specs, custom client flags) is planned but not yet live. Until it lands, use (deployment, cc_client, ec_client, *_version) tuples to identify a unique configuration. Track progress on the Roadmap.

Label deployment

StereumLabs runs nodes on multiple (cloud) providers:

• NDC2: Data center in Vienna, Austria. Servers and networking fully managed by RockLogic. Bare-metal baseline (Epyc 9654P, ECC DDR5, ZFS raidz1, dedicated NICs).
• GCP: Google Cloud Platform, currently europe-west3-a (Frankfurt). Hosts the supernode (cc_client ending in -super) cluster.

Label role

• ec: execution-client host.
• cc: consensus-client host.
• standalone: Caplin (Erigon binary running both EL and CL).

PromQL examples

Examples that should work as-is against the full Prometheus datasource. Replace the client/version filters with what you care about.

Resource utilization

CPU utilization (cores) of an Erigon EC paired with Prysm:

sum by (instance) (rate(node_cpu_seconds_total{
  mode!="idle",
  cc_client="prysm",
  ec_client="erigon",
  role="ec"
}[5m]))

Memory in use (bytes) for every consensus client across the NDC2 fleet:

node_memory_MemTotal_bytes{deployment="NDC2", role="cc"}
  - node_memory_MemAvailable_bytes{deployment="NDC2", role="cc"}

Disk write rate (MB/s) per EC, averaged over the last 7 days:

avg_over_time(
  (
    rate(node_disk_written_bytes_total{device!~"loop.*|dm-.*", role="ec"}[5m])
    / 1e6
  )[7d:1h]
)

Client peers

EC peer counts (Besu exposes per-client breakdowns):

besu_peers_peer_count_by_client{ec_client="besu"}

CL libp2p peer count (Prysm metric name; other CCs use different names, see Client metrics):

p2p_peer_count{cc_client="prysm", role="cc"}

Sync & headroom

Slots behind for every CC (different CCs expose different metric names; here Prysm):

clock_slot - beacon_head_slot

Filtering by a specific pairing:

(clock_slot - beacon_head_slot){cc_client="prysm", ec_client="nethermind"}

Block processing (Erigon log-derived)

The block-import phase timings live in container logs (Elasticsearch), not Prometheus. See the Caplin standalone post methodology for the regex used to extract execution=, commit=, age=, and mgas/s= fields from the head updated log line.

Cross-fleet comparators

Average CPU per EC pairing over the last 24 hours:

avg by (cc_client, ec_client) (
  avg_over_time(
    (
      sum by (instance) (rate(node_cpu_seconds_total{mode!="idle", role="ec"}[5m]))
    )[24h:1h]
  )
)

This is the shape of query that powers most of the per-client comparators on our dashboards.

Tips

• Always filter by role. A naked metric query will mix EC and CC hosts. You almost never want that.
• Use subqueries ([7d:1h]) for long-horizon averages. Cheaper than range queries when you only need the boundary value.
• Exclude virtual interfaces in network metrics: device!~"lo|veth.*|docker.*|br.*".
• Exclude virtual disks in disk metrics: device!~"loop.*|dm-.*".
• The full Prometheus datasource is the default in Pro and Enterprise orgs. Queries pointed at no specific datasource go there.
• Histograms are exposed as _bucket, _count, _sum. Use histogram_quantile(0.99, sum by (le) (rate(<name>_bucket[5m]))) for percentiles.

Want us to build a dashboard for you?

Pro customers can request custom dashboards on a fair-use basis. Tell us the audience, the metrics you want, and the question the dashboard should answer. We assess scope and effort and aim to deliver as part of the regular release cadence. Enterprise customers get priority queueing and larger scope.

Send proposals to contact@stereumlabs.com.

Submitting community dashboards

• Send a short proposal (audience, metrics, a link) to contact@stereumlabs.com.
• We can list or link high-quality community dashboards once labels/units/definitions match this page.

---

Change control for this page: material edits will be logged in the global Changelog with a short rationale and effective date.