Skip to main content

Basic Monitoring Indicators in the ISBE Network

This document summarizes the main indicators that use cases may need to verify the operation of the ISBE network and their regular nodes. This is a minimalist guide to recognize the general state without entering into internal infrastructure details.

1. Block Time​

The block time indicates the average interval between generated blocks.

  • Expected value: ~2 seconds
  • What it means:
    • If it increases significantly → congestion or problems in validators.
    • If it decreases slightly → normal variations in IBFT.
  • How to check it:
    • Through Blockscout.
    • With RPC:
curl -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest", false],"id":1}'   http://localhost:8545

2. Peer Count​

The number of peers indicates how many P2P nodes are connected to your regular node.

  • Expected value: > 0
    (Normally between 3 and 7 peers, depending on the environment)
  • What it means:
    • 0 peers → the node is not permissioned, the firewall blocks the port, or the network is not accessible.
  • Check:
curl -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'   http://localhost:8545

3. Block Height​

Indicates the number of the last block generated on the network.

  • Expected value: continuous growth every ~2s.
  • What it means:
    • If the value does not change → the node is not syncing.
    • If it changes but is far behind the explorer → the node is lagging.
  • Check:
curl -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'   http://localhost:8545

4. RPC Latency​

Latency indicates the node's responsiveness when receiving queries.

  • Guideline values:
    • 20–150 ms: normal.

    • 500 ms: network problem or node overload.

  • How to measure:
    • Using repeated eth_blockNumber scripts.
    • Reviewing response times in application logs.
    • External tools like curl -w "%{time_total}".

5. Regular Node Usage (optional)​

If the use case operates its own node, periodic reviews are recommended:

CPU​

  • Should stay below 70% in sustained use.

RAM​

  • Besu typically consumes between 1–3 GB; if it exceeds 4 GB, there may be a memory leak or excessive load.

Disk​

  • The data folder grows over time.
  • Keep > 20% free to avoid data corruption.

Logs​

  • Recurring errors such as DroppedPeer, SyncError, or Permissioning rejected should be investigated.

6. General Interpretation for Use Cases​

IndicatorGood StateDoubtful StateBad State
Block time~2 s>3 s>5 s
Peer count>00 intermittent0 constant
Block heightAdvancingSlight delayNot advancing
RPC latency<150ms150–500ms>500ms

Teams should only escalate to ISBE in "Bad" states. "Doubtful" states are usually due to temporary conditions or local overload of the regular node.

  • Peer count = 0:

    • Verify firewall and opening of port 30303/tcp.
    • Confirm that <NODE_IP> matches the one sent for permissioning.

  • High block time:

    • Check Blockscout to see if it is general or local.
    • Contact ISBE if it lasts more than 5 minutes.

  • Block height not advancing:

    • Restart the node.
    • Check Besu logs.
    • Contact if it persists.

  • High latency:

    • Check bandwidth and server load.
    • Avoid simultaneous massive deployments.

8. Summary​

This document summarizes the essential indicators to validate:

  • Node connectivity (peer count)
  • Network health (block time)
  • Synchronization (height)
  • Responsiveness (latency)

With this data, any use case can detect basic problems without requiring access to ISBE's internal tools.