Hyperledger Besu network statistics with Ethstats: what it shows your consortium
A permissioned Besu network run by several organizations needs a shared, live view of node health, and Besu supports this directly. A Besu node connects to an Ethstats server with the --ethstats option, and --ethstats-contact can add a contact detail, but only when --ethstats is set. Ethstats has three parts: a server that consumes node data, a client that extracts data from the node and sends it to the server, and a dashboard that displays the statistics. Once the nodes report in, the dashboard shows last block details, connected peers, latency and uptime, along with charts for block time, gas and propagation. It also displays node logs and lets operators play back block history, which helps when a member asks what happened during an incident.
Treat this as a status dashboard, not an alerting or audit system. The dashboard shows what the nodes reported at the time they reported it, so a stalled client, a dropped connection or a node that stops sending data may look the same as a healthy quiet period unless someone watches the charts. Alerting on block production, peer loss or lagging nodes still belongs in your monitoring stack, and the metrics Besu exposes for Prometheus cover that need. Audit evidence of who changed a validator set or a permission is a different record, and the dashboard does not replace it. Before you rely on it, confirm with the Besu documentation how the node data is transmitted and stored, and decide which organization hosts the Ethstats server, since that party will see node identities, peer information and logs.
Agree the governance before the first node connects. Each member should decide which node names and contact details appear on the shared view, who may see node logs, and who is responsible for restarting a node when its tile turns red. Confirm the exact Ethstats server version and compatibility with your Besu release in the Besu Ethstats documentation before deployment, and test the connection on a non-production network first. Because Besu releases change frequently, add the Ethstats connection to your upgrade checks so a node update does not silently drop its reporting.
What you need before connecting nodes to Ethstats
Ethstats adds a reporting path from every Besu node to a shared server, so each item below has to be settled across the consortium before the first node reports. The checks are mostly about version support, reachability and naming, and each one fails quietly if it is skipped.
A Besu release that supports ethstats
Confirm that every node runs a Besu release that accepts the --ethstats option before you change any configuration. Check the release notes for the version in use on the Besu releases page, since option support is tied to specific versions. Mixed versions across members are common in consortiums, so inventory each operator's binary, not only the version your team runs. A node on an older release will not report, and the dashboard will not say why.
An Ethstats server every node can reach
Each node opens its own connection to the Ethstats server, so the server address and port must be reachable from every member's network, not only from the team hosting it. Test the path from each node's host, including through any proxy, firewall or NAT that member uses. Record which member runs the server and who can restart it. The reporting connection depends on this one service, so it is a single point of failure for the view, though not for block production.
A node naming convention
The --ethstats option takes a node identifier that appears on the dashboard, so names must be unique and recognizable across members. Agree a format before rollout, for example one that encodes the organization, node role and environment, and document it in the consortium's operating procedures. Without this, validators from different members can be indistinguishable on the dashboard, and a renamed node can look like a new one. Changing names later is possible but leaves gaps in the history.
Outbound network rules
Nodes need outbound access from their hosts to the Ethstats server on the agreed port. Ask each member's security team to approve this flow explicitly, and document the source, destination and protocol. Note that this is a connection from the node to the server, so inbound rules on the node are not part of this change. Confirm whether any member's egress controls, proxies or inspection devices affect the connection, since they can drop reports silently.
Who hosts and owns the server
The Ethstats server, its hosting, access control and retention of node data are a consortium decision, and DeployOpen does not supply a hosted Ethstats service. Decide who operates the server, who can view the dashboard, and whether node logs displayed there are acceptable to share with every member. Confirm these terms in writing before connecting regulated nodes, because the dashboard shows peer, block and log data across organizations.
Node authentication and exposure
Before adding a reporting path, confirm which node interfaces are exposed. Reporting to Ethstats does not replace JSON-RPC authentication or network controls on the node. Review the JSON-RPC authentication options in the Besu documentation and confirm that the reporting setup does not widen what is reachable from outside the node's network. Treat the Ethstats server as a system with its own access policy, not as a harmless monitoring endpoint.
How to configure Besu nodes to report to Ethstats
This sequence connects one pilot Besu node to an Ethstats server, confirms it appears correctly on the dashboard, and then extends reporting to the rest of the network. Each stage ends with a check, so problems surface on one node before they affect the whole consortium.
Deploy and confirm the Ethstats server
The platform team installs the Ethstats components in infrastructure the consortium agrees to use: a server that consumes node data, and a dashboard that displays it. Confirm the server and dashboard load in a browser from the network segment where operators work, and record the address and the shared secret the nodes will use to authenticate. Done when the dashboard opens and shows an empty network view without errors. Ask your Ethstats distribution or the Besu documentation which server component versions are compatible with your Besu release before you install.
Set the ethstats option on one pilot node
Choose a single non-validator or low-risk node as the pilot, then add the --ethstats option to its startup configuration, pointing to the server address and the secret agreed in the previous step. Give the node a clear, unique name that identifies the organization and role, such as the operator and node type, so it is easy to find on the dashboard. Keep the node name and secret in your normal configuration management, not in shared chat or tickets. Done when the configuration file or service definition contains the option and the change is peer reviewed.
Add the optional contact only after ethstats is set
If operators want a named contact visible on the dashboard, add --ethstats-contact to the same pilot node. The Besu documentation allows this option only when --ethstats is also set, so a contact on its own will not produce reporting. Use a team mailbox or role contact rather than a personal address, since the value is visible to anyone with dashboard access. Done when the startup configuration includes both options together and the contact value has been approved by the people who can see the dashboard.
Restart the pilot node and confirm it appears
Restart the pilot node so it loads the new options, then watch its startup logs for a successful connection to the Ethstats server. Open the dashboard and find the node by its name. Check that the connected peer count is plausible for the node's role, that the last block shown matches the chain head reported by a node you trust, and that the latency and uptime values update over a short period. Done when all three values look correct. If the node is missing, check the server address, the secret and network reachability between the node and the server first.
Compare the pilot node with a second node
Before rolling out further, add a second node of a different role and confirm it reports in the same way. For example, pair a validator with an RPC node. Compare the peer counts, last block height and block propagation charts for both nodes. Differences are expected between roles, but a node that lags the chain head or shows no peers needs investigation before rollout continues. Done when both nodes show consistent block data and the team agrees on what normal values look like for each role.
Roll out reporting to the remaining nodes
Apply the same --ethstats option and a unique node name to each remaining node, one group at a time, restarting each group and checking the dashboard after every change. Keep a record of which node names belong to which organization so the consortium can attribute statistics correctly. Done when every node in the network appears on the dashboard with a distinct name and its block height is at or near the chain head. Record the final inventory alongside your other network documentation.
How the Ethstats client, server and dashboard exchange node data
Ethstats reporting runs in three parts: a Besu node is the source of the data, a client extracts that data from the node and sends it, a server consumes it, and a dashboard displays it. The client sits next to the node and reads its state, then pushes that state out to the server. The node itself does not serve the dashboard, and the dashboard never queries the node directly. Before you enable the feature, confirm which component in your deployment runs the client role, since the Besu Ethstats documentation describes the node connecting directly to a server through the --ethstats option, and you should verify how that connection authenticates and what it sends in your Besu version using the Besu docs: Ethstats page.
What operators see on the dashboard is broader than a block height. The documented views include last block details, connected peers, latency, uptime, charts for block time, gas and propagation, node logs, and block history playback. Those views are useful for spotting a validator that falls behind, a node with few peers, or a block that propagates slowly across the consortium. The contents of node logs deserve particular care: a log stream can carry internal addresses, peer identifiers and error text, so decide who can open the dashboard and which nodes are allowed to report into it before you expose it to more than the network team.
The reporting crosses a trust boundary at the point where node data leaves the operator's network and reaches the Ethstats server. If that server is hosted by another consortium member, a third party or a SaaS provider, you are sharing operational telemetry outside your control. Treat the server as a system inside your infrastructure, place it behind your access controls, and confirm with your security team which fields leave your network before connecting any node in a regulated environment.
Which Besu values appear on the Ethstats dashboard
This table maps the node settings and runtime values Besu sends to Ethstats onto the dashboard views operators use day to day. Read it to decide which fields you can rely on for consortium monitoring and which ones need checking against your own node role and Besu version.
| Dashboard value | Where it comes from | How operators use it |
|---|---|---|
| Node name | Set through the --ethstats option, which carries the name shown on the dashboard | Identifies each organization's node in a shared view, so agree naming rules across the consortium before go-live |
| Contact details | Set with --ethstats-contact, which only takes effect when --ethstats is also set | Tells the network team who to call about a node; keep it current because it is not validated |
| Connected peers | Reported by the node from its peer list | A sudden drop on one node points to connectivity or permissioning problems, while a consistent count across nodes suggests a healthy mesh |
| Latest block and block history | Reported from the node's chain head | Confirms each node is following the chain and helps spot nodes stuck behind; playback is useful when reviewing an incident |
| Block time chart | Derived from block timestamps observed by the node | Validator-produced blocks should follow the configured block period; confirm expected values against your genesis and QBFT settings |
| Propagation and latency | Time between a block arriving at the server and reaching each node | Shows how quickly blocks reach each participant; slow propagation on one node often means network or resource issues on that host |
| Uptime and node logs | Reported by the client and streamed to the dashboard | Useful for quick triage; validator and RPC nodes differ in what the dashboard shows, so confirm field behavior for each role |
| Field names and availability | Set by the Ethstats client and the Besu version in use | Confirm each displayed field against the running Besu and Ethstats versions before using it for alerting or reporting |
Securing the Ethstats connection and what it exposes
Ethstats is a reporting path, so its security question is less about the dashboard and more about what leaves each node and who can see it. The cards below cover the server endpoint, the data reporting carries, whether the server sits inside or across organizations, and how the dashboard is reached.
Server endpoint and access control
The Ethstats server receives data from every node that reports to it, so treat it as an administrative system. Confirm how the server is reached, which network segments can post to it, and whether the dashboard requires its own sign-in. Decide who may view the dashboard and who may change server settings, and record that decision before go-live. Ask the Besu team and your Ethstats server maintainers to confirm the authentication options their release supports.
What node data reveals to members
Ethstats shows connected peers, latency, uptime, block history and node logs. Any member with dashboard access can therefore see when a peer goes offline, how far behind a node is, and what its logs say about errors. Decide whether every consortium member sees every node, or whether each organization sees only its own nodes. Review log content before it is forwarded, since logs can include addresses, endpoints or configuration details.
Internal or cross-organization server
A single server run by one member is simple to operate but gives that member a live view of the whole network, and it becomes a dependency for everyone's reporting. A server run inside each organization's own infrastructure keeps data local but yields partial views. Choose the model during network governance, because changing it later means reconfiguring every node. Write down who hosts the server, who holds its credentials, and who may read its data.
Keep Ethstats off the RPC path
Ethstats reporting is outbound from the node to the server, and it should not require any new RPC exposure. Do not open JSON-RPC ports, change RPC bind addresses or publish RPC endpoints to make the dashboard work. Check firewall rules so that only the reporting path to the Ethstats server is allowed, and keep RPC access governed by the access model that already applies to the network.
Reverse proxy for dashboard access
Besu does not terminate HTTPS natively, so any browser or remote access to the dashboard needs a reverse proxy that the team selects and operates. Pick a proxy the security team already supports, configure TLS with certificates from your own authority, and restrict access by network or identity at that layer. Confirm how the chosen Ethstats server expects to be fronted, including WebSocket handling, before you publish the path.
Node identity strings
A node's display name appears on the dashboard and to every member who views it. Use names that identify the role and organization in neutral terms, such as a role and region label, and avoid hostnames, internal IP addresses, cloud account identifiers or contact details that help an attacker map your infrastructure. Use the contact option only when it is needed, because it is shown alongside the node and is only applied when the Ethstats option is set.
What the Ethstats dashboard does not replace
Ethstats is a live view of the network, not the system of record for operations, alerting or audit, so the team should plan separate controls for each gap before go-live. The dashboard shows last block details, connected peers, latency, uptime, block time, gas and propagation charts, node logs and block history playback. Those views help an operator see that a node has fallen behind or dropped off. They do not evaluate thresholds, page an on-call engineer, or keep a retention-controlled record that an auditor can rely on. Ethstats also does not manage permissioning, which Besu handles through its local node and account permissions files, and it does not handle key management, which remains a question for the node key file and any security module plugin such as the Besu HSM plugin.
For alerting and history, the monitoring path is Besu's own metrics endpoint. Start the node with --metrics-enabled and the default endpoint port of 9545, then scrape it with Prometheus and define alert rules for peer count, block production and sync state. Besu also documents a sample Grafana dashboard, which gives the team a starting point for long-term trend views that Ethstats does not keep in the same form. Decide who owns the alert routing, how long metric history is kept, and where the Prometheus and Grafana components run, since those choices sit inside your infrastructure and not inside the Ethstats server.
Audit evidence comes from logs and traces, which need their own pipeline and retention settings. Ethstats node logs are a convenience for live troubleshooting and should not be treated as the retained audit trail. Plan separate log and tracing integrations, with agreed retention periods, access controls and tamper resistance, and confirm with your auditors and compliance lead which records they expect and for how long. The monitoring obligations that apply to your regulated entity, including any operational resilience or incident reporting duties, are determined by your regulator and your own risk assessment. Confirm those obligations internally and with your advisers before deciding that the Ethstats view is sufficient for any of them.
Why a Besu node does not appear on Ethstats
This table pairs each common reason a Besu node fails to show on an Ethstats dashboard with its likely cause and the check to run first. Work through the rows in order, because the first two checks rule out most connection problems. Confirm each setting against your own node configuration and the Besu Ethstats documentation rather than relying on memory.
| Symptom | Likely cause | Check to run |
|---|---|---|
| Node missing from the dashboard | The --ethstats option is absent, or it points to the wrong server address or port | Confirm the startup flags on the running process and check the node logs for Ethstats connection messages |
| --ethstats-contact value ignored | The contact option was set without --ethstats, so Besu has no connection to attach it to | Confirm --ethstats is set in the same configuration, since --ethstats-contact is only used when --ethstats is set |
| Stale block data on the dashboard | The node has stopped syncing or the connection dropped and was not re-established | Compare the node's chain head with a healthy peer, then check whether the Ethstats client reconnected after the last restart |
| Wrong node name shown | The name was taken from a default or an older configuration than the one now running | Check the node name in the running configuration and confirm the deployment did not reuse an old config file or container image |
| Server unreachable from the node network | Firewall rules, routing, or a proxy block outbound traffic from the node subnet to the Ethstats server | Test connectivity from the node host itself, not from your workstation, and review egress rules for the Ethstats port |
| Dashboard and node disagree after a restart | The dashboard shows a cached or previous session, or the node came back on a different host, address or identity | Compare the node's current identity and chain head with the dashboard entry, then remove or refresh the stale entry |
| Node shows but peers look wrong | The dashboard reports only what the client sends, so peer counts reflect the node's view at the last update | Compare peer counts on the node's own RPC or logs with the dashboard before changing configuration |
Questions teams ask before connecting Besu to Ethstats
What does connecting Besu to Ethstats cost and what drives the effort?
The cost is mostly labor and hosting, not licensing, because the Ethstats components are open source and the Besu option is a single node setting. The main effort drivers are the number of nodes to connect, whether the Ethstats server is hosted in your infrastructure or elsewhere, and how many organizations must agree on node names, contact details and reporting access. Each node needs its client configured and checked, so effort grows with the node count. Ask any partner for a quote that separates one-time setup (server build, client configuration, dashboard access) from recurring work (server patching, client upgrades when Besu releases change, and access reviews). Ethstats itself does not publish prices, so the cost is set by the written scope.
How long does an Ethstats rollout take?
Duration depends on scope rather than on the Ethstats software itself. A single-team pilot on a small set of nodes you already operate is the shortest path, because it needs one server, a client connection per node and a check that the dashboard shows the expected peers and block data. A multi-member rollout takes longer because each organization must confirm its node names, its network reporting rules and who can see the data before anything is connected. Schedule time for a test network first, then for changing node configuration on live nodes in a planned window. Ask for a timeline in the written scope that lists these stages separately.
What does the consortium need to provide before the work starts?
Three things must be agreed before any node is configured. First, access to a server where the Ethstats server will run, with network paths from every Besu node that will report to it. Second, a naming scheme for nodes so that operators can tell which organization runs each one on the dashboard. Third, network rules that say what data may be shown, who may view it and whose nodes may appear. Without these decisions, the dashboard either shows incomplete data or exposes information members did not agree to share. Confirm the exact client options and server requirements against the current Besu Ethstats documentation for your release.
Can our own team connect Besu to Ethstats without a partner?
Yes, for a pilot on nodes your team already runs. The Besu option takes the server address, a node name and an optional contact value, and a team familiar with Besu node configuration can complete it. A multi-member rollout is harder because the work includes coordinating node names, reporting rules and access across organizations, and someone must own those decisions after go-live. Teams often keep the technical configuration in-house and bring in a partner for the consortium agreements, the server hosting design and the review of who can see which data. Decide early who will run and patch the server, since it becomes a service your operators depend on.
Does Ethstats satisfy our monitoring requirements for a regulated network?
No. Ethstats gives a live operational view of peers, block times, propagation, latency, uptime, node logs and block history playback. It is useful for the operations team, but it is not a complete monitoring, alerting or audit system. Regulated operators typically need metrics retention, alert routing, log retention and evidence that controls work, which are covered by other tools such as Prometheus-based metrics, centralized log pipelines and your incident process. Treat Ethstats as one visibility layer that sits beside those controls. Your compliance team should map each monitoring requirement to the system that meets it, and confirm the mapping with the people who will be audited.
Does Ethstats expose sensitive data or create security risk?
It can, depending on what is reported and who can reach the dashboard. Node logs and node identity information are visible to anyone with dashboard access, so the server should sit behind controlled access and should not be reachable from the open internet without an authentication layer you own. Review what each node sends before enabling it, and limit the contact field to a monitored role rather than a personal address. Keep the Ethstats server and client on supported versions, and include the server in your normal patching and access review cycle. Confirm the authentication options of your chosen Ethstats server build during the design phase.
What should we check after connecting nodes to Ethstats?
Check four things on each node and on the dashboard. The node should appear with the expected name and contact value, the peer count should match what your network design expects, block data should update at the expected block time, and node logs should show the connection without repeated errors. Then check that nodes from each organization appear as agreed, and that no node reports data it should not. Repeat these checks after every Besu upgrade and after any change to node network settings, because a client change can alter what the dashboard receives.
Does the dashboard replace our block explorer or alerting?
No. Ethstats shows network health and node status, but it does not replace a block explorer for looking up transactions, contracts or account history, and it does not send alerts to on-call staff by itself. Teams that need transaction search usually add a separate explorer with its own access controls, and teams that need alerts usually route metrics into an alerting system. Ethstats is most useful as a shared operational view during onboarding, incident triage and routine checks, where all members can see the same picture of the network.
How DeployOpen scopes and delivers Ethstats for permissioned Besu networks
DeployOpen plans, implements and documents Ethstats monitoring for Besu nodes inside the infrastructure you control, so operators get one live view of peers, block times and uptime. We start from the written scope, wire the client and server into your existing network, and leave your team with runbooks and a clear boundary between the dashboard and your formal monitoring.
How we scope
- Inventory every Besu node that will report, including validators, RPC nodes and any bootnodes.
- Agree which Ethstats server hosting model fits your environment and where it runs.
- Define who may view the dashboard and which node contact details may appear on it.
- Record in the written scope what the dashboard replaces and what stays in your alerting stack.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Configure the --ethstats option on each node and set --ethstats-contact only where it is needed.
- Deploy the Ethstats server, client and dashboard components in your chosen environment.
- Test that each node appears with correct peer counts, latency and last block details.
- Confirm that block time and propagation charts reflect real network activity during a test window.
- Keep the Ethstats secret and server address in your secrets store rather than in plain configuration files.
How we hand over
- Provide a runbook covering node onboarding, server updates and what to do when a node disappears.
- Document the data Ethstats exposes, including node logs and block history, and who can access them.
- Record the dashboard's limits, such as it not replacing alert rules, audit logging or capacity planning.
- Walk your operations team through the dashboard views and the checks they should run daily.
- Deliver configuration and test evidence in a form your auditors and change board can review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers.
- Review Ethstats client compatibility each time you upgrade Besu, since releases ship roughly monthly.
- Plan changes to the dashboard as your consortium adds or removes member nodes.
- Confirm with your team which metrics stay in Prometheus and Grafana for alerting and long-term retention.
- Coordinate dashboard changes with validator and RPC maintenance windows agreed with your consortium.
