Node Metrics and Monitoring

The DEVIIUM Chain devium--batcher exposes a variety of metrics to help observe the health of the system and debug issues. Metrics are formatted for use with Prometheus and exposed via a metrics endpoint. The default metrics endpoint is http://localhost:7300/metrics.

To enable metrics, pass the --metrics.enabled flag to the devium--batcher. You can customize the metrics port and address via the --metrics.port and --metrics.addr flags, respectively.

Important Metrics

To monitor the health of your node, you should monitor the following metrics:

• op_node_default_refs_number: This metric represents the devium--batcher's current L1/L2 reference block number for different sync types. If it stops increasing, it means that the node is not syncing. If it goes backwards, it means your node is reorging.
• op_node_default_peer_count: This metric represents how many peers the devium--batcher is connected to. Without peers, the devium--batcher cannot sync unsafe blocks and your node will lag behind the sequencer as it will fall back to syncing purely from L1.
• op_node_default_rpc_client_request_duration_seconds: This metric measures the latency of RPC requests initiated by the devium--batcher. This metric is important when debugging sync performance, as it will reveal which specific RPC calls are slowing down sync. This metric exposes one timeseries per RPC method. The most important RPC methods to monitor are:
  • engine_forkChoiceUpdatedV1, engine_getPayloadV1, and engine_newPayloadV1: These methods are used to execute blocks on devium-geth. If these methods are slow, it means that sync time is bottlenecked by either devium-geth itself or your connection to it.
  • eth_getBlockByHash, eth_getTransactionReceipt, and eth_getBlockByNumber: These methods are used by the devium--batcher to fetch transaction data from L1. If these methods are slow, it means that sync time is bottlenecked by your L1 RPC.

Available Metrics

A complete list of available metrics is below: