Hyperledger Besu monitoring starts with knowing which node signals matter
A team standing up a permissioned Besu network needs visibility before the first block is produced, not after the first incident. Besu exposes Prometheus metrics that a monitoring stack can scrape or receive by push, and a useful setup depends on choosing the right alerts for a private network. The metrics endpoint is switched on with the --metrics-enabled option, and the default endpoint listens on port 9545. Enabling that endpoint is the easy part. Deciding which signals should wake someone up is the work that determines whether monitoring helps.
Several things make this harder than it looks. Default metrics are not alerts: a node can export thousands of series and still give no warning that a validator has stopped proposing blocks. The sample Grafana dashboard that Besu documents is a starting point to adapt, not a finished operations view. A permissioned network also differs from a public one. It has a small, known set of validators, so the health of each named validator, its peers and its block production tells you far more than generic public-network heuristics such as overall peer counts across thousands of nodes. Your alert rules should be written against that known roster.
Metric names, labels and behavior must be confirmed against the Besu version you run. Besu uses calendar version numbers and ships roughly monthly, and releases have removed or changed features that affect what is exported. Before you write a single alert, pull the metrics list from your running build, record which series your rules depend on, and repeat that check at every upgrade. Treat a renamed metric as a monitoring outage that looks like a healthy network, because a silent alert rule fails without any visible error.
Besu is open source under the Apache 2.0 license, so there is no license fee for the client itself. The monitoring stack is different: Prometheus, Grafana, any alert manager and any push gateway are third-party software that your team or your partner operates inside your infrastructure. Ask who owns the scrape configuration, the dashboards, the alert routing and the retention settings, and who patches those components. Those answers decide whether the monitoring keeps working during the first validator incident.
Which components make up a Besu monitoring stack
A Besu monitoring stack is a chain of components: each node exposes metrics, Prometheus collects them, dashboards and alerts read from Prometheus, and host metrics show the machine underneath. Each part usually has a different owner, so agree on responsibilities before you build. The push gateway is optional and applies only to nodes that cannot be scraped.
Besu metrics endpoint
Besu exposes its metrics over HTTP when the metrics-enabled option is set. The default port is 9545, so confirm the port and bind address your nodes use before you open any firewall rule. In a typical deployment, the node operations team sets this in the node configuration for each validator and RPC node. Confirm in the Besu metrics documentation for your release which metric families are emitted and whether the endpoint should be limited to the monitoring network.
Prometheus server
Prometheus pulls samples from each Besu endpoint on a fixed schedule, which is the usual collection path for a private network. It stores the time series that dashboards and alert rules query, so retention and disk sizing decide how far back you can investigate an incident. The monitoring or SRE team typically owns the server, its scrape targets and its storage. Confirm the scrape interval and retention you plan to use, and check that the metric names your alert rules depend on match your Besu version.
Prometheus push gateway
The push gateway is optional and is only needed where Prometheus cannot reach a node directly, such as a node behind a restrictive network boundary. Besu can push metrics to a gateway, but pushed series persist until someone removes them, so the gateway needs its own cleanup and access controls. The platform team usually owns the gateway. Confirm in the Besu metrics documentation how push is configured for your version and how stale series are handled.
Sample Grafana dashboard
Besu documents a sample Grafana dashboard built on its Prometheus metrics. It gives teams a starting point for panels on peer count, block import and sync state. Panels usually need editing to match your validator set, node names and data source labels. Dashboard ownership often sits with the monitoring team, with node operators reviewing the panels for their own validators. Confirm that the dashboard version matches your Besu release and the variables it expects from your data source.
Alertmanager or equivalent alert routing
Alertmanager receives the alerts that Prometheus rules fire and routes them to email, chat, paging or ticketing tools. For a permissioned network, the rules that matter most cover low peer count, stalled block production and a node falling behind the chain head. Routing needs a named on-call owner, so a typical deployment assigns it to the operations rota. Confirm escalation paths and silencing rules with the people who will be paged, and test each route before go-live.
Host-level metrics
Besu metrics describe the client, but the host beneath it can fail first. Host exporters report CPU, memory, disk and network usage on every node. Disk matters most for nodes that store chain state, because the database grows over time and an unnoticed full disk can stop a node. The infrastructure team usually owns the exporters and their deployment on each host. Confirm which exporter and collectors your operating system and hardening baseline allow, and check that disk alerts account for expected database growth.
Which monitoring design fits your network
This table compares the main monitoring design choices for a Besu network, from how metrics reach Prometheus to how long history is kept. Read each row against your own topology: the number of sites, the operators who run nodes, and who must be paged when a validator falls behind. The main takeaway is that every convenience, from push gateways to shipped dashboards, moves some operational work or blind spot onto your team.
| Decision | When it fits | What it costs you operationally |
|---|---|---|
| Pull-based scraping from Prometheus | Nodes are reachable from the Prometheus server on the metrics port (default 9545), and you want Prometheus to notice a silent node by itself | You must open and control network paths to each node's metrics endpoint, and each node needs a stable scrape target definition |
| Push through a Prometheus push gateway | Nodes sit behind firewalls or in another operator's network where inbound scraping is not allowed | You run one more component, and a push gateway keeps the last value it received, so a stopped node can look healthy; add staleness alerts on the time each series was last pushed |
| Dashboard used as shipped | You need visibility quickly and your validator set and naming match the sample dashboard assumptions | Panels may not reflect your validator count, labels or alert thresholds, and you must confirm each panel against your own environment before relying on it |
| Dashboard rebuilt for your validator set | You run several validators, multiple sites or operator-specific labels that the default panels do not show | Someone must own the dashboard as Besu releases change metric names, which adds ongoing review work after each upgrade |
| One central Prometheus | One operator or one site runs all nodes and the network is small enough for a single scrape configuration | A single outage in the central server blinds every node at once, so confirm its own availability and alerting path |
| One Prometheus per site or operator | Each operator must keep its own monitoring data private or run its own alerting under its own control | You must agree on shared metric names, retention and who correlates network-wide views, and each instance needs its own maintenance |
| Alert routing to a shared on-call channel | Consortium members agree on common escalation for peer count, block production and sync status | Ownership of each alert must be written down, or a stalled network produces alerts that nobody acts on |
| Alert routing to each operator | Each operator is responsible for its own validator and needs its own pages | Cross-operator incidents need a second channel, and alert text must avoid exposing another member's internal details |
| Metric history retention | Short retention suits day-to-day troubleshooting, while longer retention supports incident reviews and upgrade comparisons | Longer retention increases storage on the Prometheus host; confirm retention periods and storage needs with your own sizing before you commit |
How to enable Besu metrics and connect them to Prometheus
This sequence takes each Besu node from no monitoring to a tested setup, in which Prometheus scrapes or receives metrics, Grafana displays them, and alert rules reach the on-call channel. Each step closes with a check you can run, so you know the previous step worked before you build on it. The final step stores the configuration in version control so it can be reviewed and rebuilt.
Enable the metrics endpoint on nodes
The platform engineer adds the metrics option to each node's startup configuration, using the --metrics-enabled option and the default endpoint port 9545 unless your environment sets another port. Confirm both the option name and the port in the Besu metrics documentation for the release you run, because options can change between monthly releases. The step closes when a request to the metrics port from the node host returns Prometheus-format text, and each node serves its own endpoint.
Restrict the metrics bind address
Set the host address the metrics endpoint listens on so that only the monitoring network can reach it. Confirm the host option and its default value in the Besu metrics documentation for your release, then apply firewall or security group rules that allow the Prometheus server and no other source. The step closes when a connection from a host outside the monitoring network fails and a connection from the Prometheus server succeeds.
Add a scrape job per node
The platform engineer adds one scrape target per node to the Prometheus configuration, with labels that identify the node and its role, such as validator or RPC. Reload the Prometheus configuration and open the targets page in the Prometheus interface. The step closes when every target shows as up, and any target that is down is traced to its port, address rule or path before you move on.
Configure push gateway delivery if used
Skip this step if Prometheus scrapes every node directly. If your design pushes metrics through a Prometheus push gateway, configure each node's push settings to point at the gateway, and set job and instance labels that identify each node. Confirm the push settings in the Besu metrics documentation for your release. The step closes when a query for a known series returns samples carrying the expected node label, and those samples keep updating over several scrape intervals.
Import and adjust the Grafana dashboard
Import the sample Grafana dashboard that Besu documents, then point its data source at your Prometheus server. Update the dashboard variables and queries so the label values match the node names and labels set in the scrape configuration. The step closes when every panel shows data for each node. A panel that stays empty is checked against its query and labels before the dashboard is accepted.
Define and trigger alert rules
Write alert rules for peer count, block production and sync status, the signals covered in the next section, and route them to the on-call channel. In a test network, create each condition on purpose, such as dropping a node's peers, stopping block production on a validator, or holding a node behind the chain, to trigger each rule. The step closes when every rule fires, the alert reaches the on-call channel, and the alert resolves after the condition clears.
Save configuration in version control
Commit the Prometheus scrape configuration, the Grafana dashboard JSON, the alert rules and the Besu node configuration files to version control, and require a review before merge. Record the Besu release each file was tested against so that future upgrades can be reviewed alongside that release's notes. The step closes when a clean checkout recreates the scrape jobs, dashboard and alerts in the test network without manual edits.
Which alerts matter for peer count, block production and sync status
The three alert families that matter most for a permissioned Besu network are peer count, block production and sync status. Each one points to a different failure: a node cut off from the validator set, a chain that has stopped advancing, or a node that cannot serve current data. Set these alerts first, before you add the broader resource alerts for CPU, memory and disk, because they tell you whether the network is still doing its job.
Peer count alerts behave differently on a private network than on a public one. On a public network, a node may run with a wide and changing set of peers, so a low count is only a loose signal. In a private network, the peer set is known in advance because the permissions configuration restricts connections to participants you have named. That means the expected count for each validator and RPC node is something you can state. Alert when a node falls below that expected count, and confirm with the operators of the other nodes whether a drop is expected during maintenance. Confirm the exact peer metric name in the metrics documentation for the Besu release you run.
Block production alerts check that the chain head keeps advancing and that blocks are sealed at the cadence your configured block time implies. On a permissioned QBFT network, a stalled head is usually the first visible sign of a consensus problem, and it can appear before any node reports an error. Alert on the absence of new blocks over a window longer than your block time allows for normal variation, and also on a block interval that drifts well away from the configured value. The right window is a decision you make from test results on your own network, not a number copied from a public chain, where block times and validator behavior differ. Confirm the head-height and block-timing metric names for your release before you write the rules.
Sync status alerts identify a node that is syncing or behind the chain head. A node in that state cannot serve reliable reads to the applications that depend on it, and a validator that is behind may not vote correctly. Compare each node's local head with the head reported by the rest of the network, and alert when the gap persists beyond a short period. Public networks often treat syncing as routine after a restart, but on a private network a long catch-up can mean a node was offline long enough to matter for finality, so you should treat it as an incident until you know the cause. Plan the alert so that a planned restart does not page the on-call engineer.
Validator voting and general QBFT health are covered in a separate topic, so this section does not set thresholds for them. Before you finalize any of these alerts, run the network through normal operation, planned restarts and a controlled peer loss in a test environment, record the observed values, and set thresholds from that baseline. Document each alert with its owner, its expected response and the test result that justified its threshold, so that auditors and your own operators can see why each number was chosen.
What drives monitoring effort and cost
This table lists the factors that change how much design, build and upkeep a Besu monitoring stack needs, and how to keep each one contained. Read each row as a lever: the left column names the driver, the middle column shows what makes it larger, and the right column shows how to hold it down. Most of the cost is internal engineering time plus storage and compute for Prometheus and Grafana, so the sample dashboard and documented metrics are the main ways to reduce design work.
| Driver | What makes it larger | How to keep it down |
|---|---|---|
| Number of nodes and sites | Many validators, RPC and boot nodes spread across sites, each with its own scrape target and host-level metrics | Standardize node roles and labels so one scrape configuration and one dashboard template cover every node |
| Number of environments | Separate dev, test and production stacks, each with its own alert rules, thresholds and access settings | Keep one codebase for dashboards and rules, and vary only labels and thresholds per environment |
| Dashboards and alert rules built versus adapted | Designing panels and alerts from scratch for each consortium member or chain | Start from the sample Grafana dashboard and the documented metrics, then change only what your operating model needs |
| Integration with an existing monitoring or on-call platform | Routing alerts into a ticketing, paging or SIEM tool that has its own schemas, escalation rules and testing needs | Confirm the notification path early, use a single alert manager as the handoff point, and test paging end to end once |
| Retention and storage sizing for Prometheus | Long retention periods, high scrape frequency and many label combinations increase disk use and query load | Set retention to match your audit and incident review needs, limit scrape intervals to what alerts require, and confirm storage growth with a test run |
| Access control and audit requirements | Regulated deployments may need authenticated Grafana users, role-based views, TLS for scrape and push paths, and logs of who changed dashboards or rules | Use your existing identity provider where supported, restrict write access to dashboards and rules, and keep configuration in version control |
| Besu release upgrades the dashboards must survive | Metric names, labels or defaults can change across the monthly release calendar, so each upgrade may require dashboard and rule checks | Pin the Besu version per environment, track release notes for metric changes, and rerun dashboard and alert tests after each upgrade |
How monitoring changes across single node, multi-site and air-gapped setups
A single development node is the simplest case. One Besu process exposes metrics on its own endpoint, and one Prometheus instance scrapes it. The sample Grafana dashboard covers what a developer needs while testing contracts or client settings, and nobody is paged for what it shows.
What changes: very little from a standard setup. The scrape target points at one host, and alerting is usually disabled or sent to the developer who owns the node.
What stays the same: the metrics option, the default metrics port of 9545, and the metric names the sample dashboard expects.
- Scrape target: one static target for the Besu metrics endpoint.
- Dashboard: the sample dashboard, imported as provided, is usually enough.
- Alerts: optional, with no routing to an on-call team.
- Retention: short, because the data supports debugging rather than evidence for audits.
Confirm with the developers who own the node whether the metrics port is reachable only from the local host, and whether anyone expects the history to survive a rebuild of the environment.
A validator set running in one site, or one data center, usually has one Prometheus instance that scrapes every node. Validators and any RPC nodes each expose their own metrics endpoint, and the scrape configuration lists all of them. Alert rules apply per node, and notifications go to one team that owns the whole network.
What changes: the scrape configuration lists every node, and each target needs consistent labels so that a panel can filter by validator. Alert rules for peer count, block production and sync status are evaluated for each node, so one stalled node produces a clearly identified alert.
What stays the same: the metric names, the dashboard structure and the single notification path to one on-call rotation.
- Scrape targets: one entry per validator and RPC node, with a stable naming scheme.
- Labels: node name, role and environment, so the same panel works across the set.
- Alerts: peer count, block production and sync status, with thresholds set against the network's own normal behavior.
- Notifications: one routing tree sending to one team.
Confirm with the team that operates the network which hosts run validators, that Prometheus can reach each metrics port over the internal network, and who receives pages outside business hours.
In a consortium, each operator may run its own Besu nodes, its own Prometheus and its own Grafana. No single scrape point sees the whole network, so the consortium needs agreement on shared definitions. The shared agreement covers dashboards, metric names, alert thresholds and what counts as a stalled network.
What changes: there is no single place where every node is scraped. Cross-operator views need either a shared dashboard that reads from each operator's data source or an agreed export of selected metrics. Alert ownership also needs to be explicit, because a stall may be visible to every operator while only one operator's node is failing.
What stays the same: the Besu metrics option, the metric names and the sample dashboard as the starting point.
- Shared dashboard: agreed panels and variable names, maintained by one named owner.
- Alert semantics: the same definitions of peer count, block production and sync status across operators.
- Severity model: which conditions page an operator and which go to the consortium channel.
- Exposure: how each operator makes its metrics available to others, and under what access controls.
Confirm with the consortium governance group who owns the shared dashboard, whether each operator will expose metrics across organizational boundaries, and how an incident is escalated when no single operator can see the full picture.
In an air-gapped network, the monitoring stack has no route to public package repositories, public dashboards or external notification services at runtime. Prometheus, Grafana, the dashboard files and any Besu release all come from internal artifact repositories. Alert notifications must reach people through services that sit inside the enclosed network.
What changes: installation and updates come from internal mirrors, and every dashboard or alert rule change goes through an approved import process. Notifications route to internal mail relays, chat tools or on-call systems that are reachable inside the enclosure.
What stays the same: the metrics option, the metric names, the dashboard layout and the alert logic.
- Artifacts: mirrored copies of Prometheus, Grafana, the dashboard files and the Besu release, with checksums recorded. Besu 26.6.0 requires JDK 25, so the JDK must also be mirrored.
- Plugins and data sources: any Grafana plugin the dashboard needs must be supplied from the internal repository.
- Notifications: internal endpoints only, tested before go-live.
- Change control: a documented approval step for new dashboard or alert versions.
Confirm with the team that runs the enclosed environment which artifact repositories are available, how time is synchronized across the nodes, and who approves changes to dashboards and alert rules.
How to protect the metrics endpoint and monitoring stack
Metrics show how a Besu node is performing, and the monitoring stack around them can expose scrape paths, dashboards and alert settings to people and systems that should not reach them. The cards below cover where the endpoints sit, how they are authenticated, where secrets can leak and who may change alerts. Each card names a decision to make and a check to run before the stack goes live.
Restrict the metrics endpoint
Besu exposes metrics when the --metrics-enabled option is set, and the default endpoint port is 9545. Confirm the bind address in the Besu metrics documentation, then limit access with host and network firewall rules so only the Prometheus servers that scrape the node can connect. Keep monitoring hosts outside the trust zone that holds validator signing material, because the local node private key file is not encrypted. From a host outside the monitoring network, confirm that the port does not answer, and repeat the check after each Besu upgrade or host rebuild.
Separate metrics from JSON-RPC
The metrics endpoint is a separate listener from the JSON-RPC interface, so Prometheus does not need access to RPC ports to scrape a node. Keep RPC and WebSocket ports closed to monitoring hosts unless a specific health check requires them, and document that exception if it exists. Review the RPC settings on each node to confirm which clients can reach them. Keeping these paths apart means a compromised monitoring server does not also become a route into the node's JSON-RPC API.
Authenticate and encrypt dashboard access
Grafana and Prometheus each have their own login and transport settings, and you configure them in those tools. Besu does not terminate HTTPS natively, so any TLS in front of an exposed endpoint is a separate component, such as a reverse proxy, that your team selects, certifies and operates. Require authenticated access to Grafana, enable TLS on every path that crosses a network boundary, and confirm the certificate chain and renewal process before users depend on it.
Protect push gateway credentials
If Besu pushes metrics to a Prometheus push gateway, the gateway accepts writes and needs its own access control. Store its credentials in a secrets store with restricted read access, and keep them out of shell history and version-controlled configuration. Allow traffic to the gateway only from the Besu hosts that push to it, and confirm that the gateway rejects unauthenticated writes. Set a credential rotation schedule with your security team and record who owns each credential.
Keep secrets out of dashboards
Dashboard variables, panel queries, annotations and log output are common places for a token, password or key file path to appear on a screen many staff can view. Metrics describe node behavior, but free-text fields are where secrets usually end up. Review dashboard JSON and provisioning files for credentials, and limit annotations to event descriptions. Configure log levels and log shipping so authentication headers and file contents are not written to shared logs, and include this review in the change process for every dashboard edit.
Limit who can change alerts
Silencing an alert or editing a scrape target can hide a stalled validator or send metrics to an unintended host. Define roles in Grafana and Prometheus so that only designated operators can silence alerts, edit alert rules or change scrape targets, and other staff have view access. Record who holds each role, review membership on a fixed cadence, and remove access when duties change. Test that a read-only account cannot modify silences or scrape targets.
How to verify monitoring works and fails loudly
A Besu monitoring setup is proven only when tests force each alert to fire, confirm it clears, and show that a failure in the monitoring stack itself is also noticed. Start with the scrape layer. Confirm that Prometheus lists every Besu node as up on its metrics endpoint, which must be enabled with the --metrics-enabled option (default port 9545 according to the Besu documentation). Then query the series for each node and check that the labels you defined, such as node name, role (validator or RPC) and network, are present and spelled consistently. A node that is up but labeled wrongly will route its alerts to the wrong owner, so check labels as carefully as you check target health. Finally, confirm that every Grafana panel in the sample dashboard reads the same series you just verified.
Next, test the peer and staleness alerts by stopping one node on a test network. Record the time of the stop, then confirm that the peer count alert and the staleness alert fire within the window defined in your rule files. Confirm that the window in the rules matches what your on-call runbook promises, because a rule that fires after the runbook's expected time is a finding, not a tuning detail. Restart the node and confirm that both alerts clear and that the resolution notification arrives. Repeat the test with a validator and with an RPC node, since the expected behavior and the people who must respond may differ between them.
Block production and sync are the alerts most likely to be missed in a permissioned network, so test them deliberately. On a test network, pause block production by stopping enough QBFT validators to break quorum, where your validator topology allows it, and confirm that the block production alert fires. Do not run this test against a network with real participants. Then lag a node on purpose, for example by isolating it from its peers for a set period, and confirm that the sync alert fires. Your validator count determines which of these tests are possible, so confirm the topology with your team before scheduling them. Note any test you cannot run and record the reason for the review.
The most common gap is a silent monitoring failure. Alertmanager cannot report that Prometheus or Grafana has stopped, so break each service on purpose and check that someone else notices. Two common designs cover this. A watchdog alert that always fires can be routed to an external service that raises an alarm when the heartbeat stops. Alternatively, an external probe outside the cluster can check that the Grafana and Prometheus endpoints respond. Stop Prometheus, confirm the external signal arrives within your expected window, then restore it and confirm the signal clears. Repeat for Grafana, since its failure may not affect alert delivery at all.
Record every test as evidence for the go-live review. For each run, capture the date, the Besu version, the commit of the configuration and scripts, the fault injected, the expected and observed alert times, and the name of the person who ran it. Keep the test scripts in the same version control as the Prometheus rules, Grafana dashboards and Besu configuration, so the suite can be repeated after each upgrade. Besu ships releases roughly monthly, and metric names or defaults can change, so confirm against the release notes and rerun the suite after each change to the node version. Agree in advance with reviewers what counts as a pass.
What to keep running after monitoring goes live
Going live is the start of monitoring, not the end of it. The cards below cover what someone should look at every day, what must be backed up so the setup can be rebuilt or audited, how to re-check dashboards and alerts before each Besu upgrade, and what the team must write down so the next person on call can act without guesswork.
Daily checks on the network
Review peer count, head block progress, sync state, host resources and Prometheus storage each day. A validator with a falling peer count or a head that has stopped advancing is often the first sign of a partition or a stalled network, so these panels should be read against the expected baseline for each node. Confirm the baseline values with your own network design, because they depend on validator count and topology. Watch disk growth on the Prometheus host as well, since a full volume silently stops metric collection.
Dashboard and alert rule backups
Export the Grafana dashboard JSON, the Prometheus alert rules and the scrape configuration into version control, and record which Besu version each set was tested against. Without these files, a rebuilt Grafana or Prometheus host will show empty panels and silent alerts, and nobody may notice until an incident. Store the exports alongside the node configuration so that a restore is a single, reviewed change rather than a manual rebuild from memory.
Prometheus data retention for audits
Decide whether historical metrics are needed for audits, incident reviews or capacity planning, and set retention to match. If history matters, back up the Prometheus data directory on a schedule and test that a restored copy can be queried. If it does not, state the retention period in writing so that auditors and operators understand why older data is gone. Confirm the retention requirement with your compliance lead before the first production cutover, not after the first audit request.
Re-checking metrics before each Besu upgrade
Besu ships roughly monthly, and metric names and default settings can change between releases. Before each cutover, read the metrics documentation for the target version and compare it with the panels and alert expressions in use, so that a renamed metric does not produce a flat line that looks healthy. Note that some database upgrades are irreversible: the Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and older versions cannot open it, so take a backup before upgrading and test the monitoring on a non-production node first.
Ownership and escalation documentation
Record who owns each dashboard, alert and node, who is paged first, and how the escalation path moves when that person does not respond. Keep a short runbook for each alert that states what the alert means, the first diagnostic steps and when to escalate to validator operators or the security team. Document the threshold rationale, meaning why each limit was chosen, so that a future engineer can change it deliberately. Attach the test evidence from go-live, such as the alert firing and resolving during a controlled peer disconnect, so the team can show the monitoring worked when it was introduced.
Ongoing monitoring care as a support arrangement
Upkeep of dashboards, alert tuning, upgrade re-checks and backup verification can be scoped as part of a support arrangement rather than left to whoever is free. Ask any partner to state in writing which tasks are included, how often reviews happen, who responds to alerts outside business hours and how upgrade re-checks are timed against Besu releases. Your internal team should still retain ownership of thresholds and escalation decisions, with the partner supplying the monitoring work and evidence.
Questions teams ask before setting up Besu monitoring
How much effort does a basic Prometheus and Grafana setup for Besu take compared with production alerting?
A basic setup is mostly configuration: enabling metrics on each node with the --metrics-enabled option, pointing Prometheus at the metrics endpoints (Besu's default metrics port is 9545), and importing the sample Grafana dashboard that Besu documents. Production alerting takes more work because it needs decisions the sample does not make for you: which conditions page someone at night, how long a condition must persist before it fires, how alerts route to validator operators, and how the design behaves when a node is restarted, upgraded or isolated. The main cost drivers are the number of validators and RPC nodes, how many environments you run, how many organizations operate nodes, and how much of the alert routing must integrate with existing on-call tooling. Ask any partner to list each alert, its threshold, its owner and its test method in the written scope.
Is the sample Besu Grafana dashboard enough for a permissioned network?
The sample dashboard is a starting point, not a complete operations view. It shows general node health and performance, but a permissioned network also needs views for validator participation, peer connectivity against your known participant list, block production across every validator, and sync status for each node. Those views depend on your topology, so they usually need to be built or adjusted once the network layout is fixed. Confirm with your team which panels you need for each role (validator, RPC, boot node) and who reviews them during an incident.
Can our team set this up without outside help if we already run Prometheus?
Often yes, if the team already operates Prometheus and has someone who knows Besu's configuration. Enabling metrics, adding scrape targets and importing the dashboard are straightforward for experienced operators. The harder parts are the alert design, the validator-specific checks and the test plan that proves an alert fires when it should and stays quiet otherwise. Teams without a Besu owner usually find that the time goes into learning the QBFT behavior they need to alert on. A written scope should state which of these items your staff will own and which a partner will deliver.
How long does Besu monitoring work take, and what depends on our internal calendar?
Duration depends on scope and on how quickly your side can respond, not only on the technical work. The main internal dependencies are access approvals for nodes and hosts, change windows for restarting nodes to enable metrics, the availability of people who can confirm validator roles, and the time your security or operations teams need to review alert routing. Ask for a timeline in the written scope that lists each dependency with an owner and a date, and make sure it includes a test window on a non-production network before anything reaches production.
What does the monitoring work need from our organization?
Expect to provide access to the nodes you want monitored, a monitoring host or namespace where Prometheus and Grafana run, a named contact list for alert routing, and access to test networks where alerts can be triggered safely. You also need someone who understands the validator topology: which nodes are validators, which are RPC or boot nodes, where each operator's infrastructure sits and which peers are expected to connect. Without that person, alert thresholds are guesses. Confirm these items, and who supplies each one, before the scope is signed.
Does Besu licensing add cost to monitoring?
Besu itself does not add a license fee. It is open source under the Apache 2.0 license, so there is no paid edition to buy for metrics. The costs sit elsewhere: the compute and storage for Prometheus and Grafana, any hosted or commercial monitoring service you choose, the alert routing tools, and the staff time to design, maintain and respond to alerts. Ask a partner to separate one-time work (initial build, alert design, testing) from recurring work (dashboard updates, rule tuning, review after each release), and to state which third-party licenses, if any, are included.
How does monitoring change after a Besu upgrade?
Each upgrade can change metric names, default behavior or the features your dashboards depend on, so monitoring should be checked as part of every upgrade plan. Besu ships releases roughly monthly, so the check must be routine rather than occasional. Before upgrading, review the release notes for metric and API changes, and confirm that panels and alerts still reference valid series on a test network. Remember that some upgrades change the database irreversibly, so take a backup first. Ask any partner how upgrade checks are included in the support agreement.
How DeployOpen scopes, builds and hands over Besu monitoring
DeployOpen plans and implements Hyperledger Besu monitoring with Prometheus and Grafana inside your own infrastructure, from enabling Besu's metrics endpoint through to dashboards and alerts your operators can run. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Inventory every Besu node and validator, including which nodes expose metrics and which network segments Prometheus can reach.
- Confirm whether your nodes will be scraped by Prometheus or push metrics through a push gateway, and document the choice.
- Agree the written scope covering which alerts, dashboards and environments are in and which are excluded before work begins.
How we build
- Enable the Besu metrics option on each node, with the metrics endpoint bound and reachable only from approved monitoring hosts.
- Configure Prometheus scrape jobs and build Grafana dashboards starting from Besu's documented sample dashboard, adjusted to your node roles.
- Define alerts for peer count, block production and sync status, then test each one against a controlled node outage before sign-off.
How we hand over
- Deliver configuration files, scrape definitions, dashboard exports and alert rules as versioned artifacts stored in your repository.
- Document each alert with its trigger, expected response, owner and the Besu metric it reads, so on-call staff can act without us.
- Walk your operations team through the dashboards and a live alert test, and record the handover against the agreed scope.
How we support
- Review alert thresholds and dashboards when Besu releases change metric names or default behavior, since releases ship roughly monthly.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Confirm with us in the quote which post-go-live tasks are included, such as metric checks after each Besu upgrade.
