Node Metrics

Metrics that measure the speed and responsiveness of a node's operations. Key indicators include block propagation time (how fast a new block is received), transaction processing speed, and peer-to-peer (P2P) network latency. High latency can lead to forks and stale blocks, degrading overall network performance.

Tracks the consumption of a node's underlying hardware resources. Critical metrics are:

• CPU Usage: Processing load from consensus and validation.
• Memory (RAM) Consumption: For state and mempool management.
• Disk I/O & Storage: Read/write speed and total blockchain data size.
• Network Bandwidth: Data uploaded/downloaded to peers. Monitoring these prevents node crashes and ensures stable operation.

Metrics specific to a node's role in the network's consensus mechanism. For Proof-of-Stake, this includes validator uptime, attestation effectiveness, and slashing events. For any node, tracking block validation success rate and fork choice rule adherence is crucial for maintaining chain integrity and earning rewards.

Measures a node's integration within the peer-to-peer network. This includes the number of active peer connections, peer churn rate (how often connections drop), and geographic distribution of peers. A well-connected node with stable, diverse peers receives blocks and transactions faster, improving its reliability.

Metrics related to the node's local copy of the blockchain state. The sync status (e.g., "in-sync", "catching up") and sync speed (blocks per second) are primary indicators. For full nodes and archive nodes, monitoring the size of the state trie and pruning efficiency is vital for managing storage growth.

Metrics that help identify malicious activity or operational failures. This involves monitoring for unusual spikes in invalid transactions, repeated connection attempts from suspicious IPs, deviations from expected block gas limits, or unexpected changes in consensus vote patterns. These are early warning signs of attacks or bugs.

The percentage of time a node is online and reachable on the network. High uptime is critical for validators, RPC providers, and indexers. It is often measured as a Service Level Agreement (SLA) percentage (e.g., 99.9%).

• Key Metric: (Total Time - Downtime) / Total Time
• Impact: Downtime for a validator can lead to missed blocks and slashing penalties.

The latency for a newly produced block to be received and processed by a node after it is first broadcast. This measures network efficiency and directly impacts consensus finality.

• Measured in milliseconds (ms).
• A critical metric for validator performance; slow propagation increases the risk of forks.
• Network-wide averages are used to gauge overall health.

The number of active network connections (peers) a node maintains. This reflects the node's integration into the peer-to-peer (P2P) network.

• Inbound Peers: Connections initiated by others to your node.
• Outbound Peers: Connections your node initiates.
• A healthy, stable peer count ensures robust data availability and resistance to network partitions.

The consumption of hardware resources by a node process, primarily CPU, Memory (RAM), Disk I/O, and Network Bandwidth.

• Monitoring Purpose: To prevent node crashes, sync issues, and performance degradation.
• Spikes in CPU/Memory can indicate heavy block processing or mempool activity.
• Disk I/O is crucial for nodes with large state, like archive nodes.

Indicates whether a node's local blockchain copy is up-to-date with the network's canonical chain. The two primary states are:

• In-Sync: The node's latest block matches the network's head block.
• Syncing: The node is catching up by downloading and validating historical blocks.
• Metric: Often expressed as block height difference (e.g., -5 blocks behind).

Measures the responsiveness and reliability of a node's external interfaces, such as its JSON-RPC or REST API endpoints. Key for developers and dApps.

• Latency: Time to fulfill a request (e.g., eth_getBalance).
• Throughput: Requests per second (RPS) the node can handle.
• Error Rate: Percentage of failed requests (e.g., timeouts, rate limits).

The number of active connections a node maintains with other peers in the network. A healthy peer count ensures data redundancy, fast block propagation, and resilience against network partitions.

• Low peer count can lead to network isolation, slower syncing, and increased risk of being on a minority chain.
• Target ranges vary by client and network; for example, Ethereum execution clients often aim for 50-100 peers.

Indicates whether a node's local blockchain is fully synchronized with the canonical chain's latest block. Sync status is critical for validating transactions and participating in consensus.

• Key metrics: head block number, highest block, and sync distance.
• Being out of sync means the node cannot verify the latest state, making it vulnerable to serving stale or incorrect data.

Measures the computational and RAM resources consumed by the node software. Sustained high utilization can degrade performance and cause instability.

• Spikes in CPU usage often occur during block processing or state trie operations.
• Memory leaks can lead to gradual performance degradation and eventual crashes, requiring monitoring and client updates.

Monitors read/write operations and the rate of growth of the blockchain database (e.g., chaindata). High I/O latency or insufficient disk space can halt a node.

• SSDs are typically required for acceptable performance due to random access patterns.
• Pruning and state expiry are mechanisms to manage relentless storage growth, which is a key operational challenge.

The volume of data transmitted/received and the delay in communication with peers. Bandwidth affects how quickly blocks and transactions are propagated.

• High latency can cause a node to receive blocks late, impacting validator performance in Proof-of-Stake systems.
• Monitoring traffic helps identify DDoS attacks or misconfigured peers flooding the connection.

For consensus nodes, metrics like attestation effectiveness, proposal success rate, and slashing conditions are paramount.

• Missed attestations or proposals directly impact rewards and can signal infrastructure issues.
• Monitoring for slashing events (double signing, surround voting) is a critical security requirement to prevent stake loss.