Node metrics and monitoring

The Optimism op-node 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 op-node. 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 op-node'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 op-node is connected to. Without peers, the op-node 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 op-node. 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 op-geth. If these methods are slow, it means that sync time is bottlenecked by either op-geth itself or your connection to it.
  • eth_getBlockByHash, eth_getTransactionReceipt, and eth_getBlockByNumber: These methods are used by the op-node 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: