Our [dashboards page](/docs/monitoring/dashboards) explains how to set up a Grafana dashboard for monitoring your Geth node. This page explores the dashboard itself, explaining what the various metrics are and what they mean for the health of a node. Note that the raw data informing the dashboard can be viewed in JSON format in the browser by navigating to the ip address and port passed to `--metrics.addr` and `--metrics.port` (`127.0.0.1:6060` by default).
Each panel in the dashboard tracks a different metric that can be used to understand some aspect of how a Geth node is behaving. There are three main categories of panel in the default dashboard: System, Network and Blockchain. The individual panels are explained in the following sections.
## What do the panels show?
### System
Panels in the System category track the impact of Geth on the local machine, including memory and CPU usage.
#### CPU
The CPU panel shows how much CPU is being used as a percentage of one processing core (i.e. 100% means complete usage of one processing core, 200% means complete usage of two processing cores). There are three processes plotted on the figure. The total CPU usage by the entire system is plotted as `system`; the percentage of time that the CPUs are idle waiting for disk i/o operations is plotted as `iowait`; the CPU usage by the Geth process is plotted as `geth`.
Memory tracks the amount of RAM being used by Geth. Three metrics are plotted: the cache size, i.e. the total RAM reserved for Geth (default 1024 MB) is plotted as `held`; the amount of the cache actually being used by Geth is plotted as `used`; the number of bytes being allocated by the system per second is plotted as `alloc`.
The Peers panel shows the number of individual peers the local node is connected to. The number of dials issued by Geth per second and the number of external connections received per second are also tracked in this panel.
Ingress is the process of data arriving at the local node from its peers. This panel shows the rate that data specifically using the eth subprotocol is arriving at the local node in units of kB/s (kilobytes per second). The data is subdivided into specific versions of the ETH subprotocol. Make sure your dashboard includes the latest version of the eth subprotocol!
#### ETH egress data rate
Egress is the process of data leaving the local node and being transferred to its peers. This panel shows the rate that data specifically using the eth subprotocol is leaving the local node in units of kB/s (kilobytes per second). Make sure your dashboard includes the latest version of the eth subprotocol!
#### ETH ingress traffic
Ingress is the process of data arriving at the local node from its peers. This panel shows a moment-by-moment snapshot of the amount of data that is arriving at the local node, specifically using the eth subprotocol, in units of GB (gigabytes). Make sure your dashboard includes the latest version of the eth subprotocol!
#### ETH egress traffic
Egress is the process of data leaving the local node and being transferred to its peers. This panel shows a moment-by-moment snapshot of the amount of data that has left the local node, specifically using the eth subprotocol, in units of GB (gigabytes). Make sure your dashboard includes the latest version of the eth subprotocol!
### Blockchain
Panels in the Blockchain category track the local node's view of the blockchain.
#### Chain head
The chain head simply tracks the latest block number that the local node is aware of.
#### Transaction pool
Geth has a capacity for pending transactions defined by `--txpool.globalslots` (default is 5160). The number of slots filled with transactions is tracked as `slots`. The transactions in the pool are divided into pending transactions and queued transactions. Pending transactions are ready to be processed and included in a block, whereas queued transactions are those whose transaction nonces are out of sequence. Queued transactions can become pending transactions if transactions with the missing nonces become available. In the dashboard pending transactions are labelled as `executable` and queued transactions are labelled `gapped`. The subset of those global transactions that originated from the local node are tracked as `local`.
#### Block processing
The block processing panel tracks the time taken to complete the various tasks involved in processing each block, measured in microseconds or nanoseconds. Specifically, this includes:
- **execution**: time taken to execute the transactions in the block
The transaction processing panel tracks the time taken to complete the various tasks involved in validating the transactions received from the network, measured as a mean rate of events per second:
- **known**: rate of new transactions arriving at the node that are ignored because the local node already knows about them.
- **valid**: rate that node marks received transactions as valid
- **invalid**: rate that node marks received transactions as invalid
- **underpriced**: rate that node marks transactions paying too low gas price as rejected
- **executable discard**: rate that valid transactions are dropped from the transaction pool, e.g. because it is already known.
- **executable replace**: rate that valid transactions are replaced with a new one from same sender with same nonce but higher gas
- **executable ratelimit**: rate that valid transactions are dropped due to rate-limiting
Block propagation was disabled in Geth at The Merge. Block propagation is now the responsibility of the consensus client. Included here for archival interest.
- **ingress announcements**: the number of inbound announcements per second. Announcements are messages from peers that signal that they have a block to share
- **malicious announcements**: the number of announcements per second that are determined to be malicious, e.g. because they are trying to mount a denial-of-service attack on the local node
- **ingress broadcasts**: the number of blocks directly propagated to local node per second
- **known broadcasts**: counts all blocks that have been broadcast by peers including those that are too far behind the head to be downloaded
The transaction fetcher peers panel shows how many peers the local node is connected to that can serve requests for transactions. The adjacent transaction fetcher hashes panel shows how many transaction hashes are available for fetching. Three statuses are reported in each panel: Waiting, queuing and fetching.
#### Reorg
The `reorg meter` panel simply counts the blocks added and the blocks removed during chain reorgs. The adjacent `Reorg total` panel shows the total number of reorg executions including both additions and removals.
#### Eth fetcher filter bodies/headers
Tracks the rate that headers/block bodies arrive from remote peers.
- **compaction read**: Rate that data is read from the LevelDB database while it is being compacted (i.e. free space is reclaimed by deleting unnecessary data)
- **compaction write**: Rate that data is written to the LevelDB database while it is being compacted (i.e. free space is reclaimed by deleting unnecessary data)
Instead of the _rate_ that data is read from, and written to, the LevelDB and ancients databases (as per `Data rate`), this panel tracks the total amount of data read and written across the entire time Geth is running.
These panels show the amount of time spent compacting the LevelDB database, duration write operations to the database are delayed due to compaction and the count of various types of compaction executions.
The current default Geth Grafana dashboard includes panels for light nodes. Light nodes are not currently functional since Ethereum moved to proof-of-stake.
If the default dashboard isn't right for you, you can update it in the browser. Remove panels by clicking on their titles and selecting `remove`. Add a new panel by clicking the "plus" icon in the upper right of the browser window. There, you will have to define an InfluxDB query for the metric you want to display. The endpoints for the various metrics that Geth reports are listed by Geth at the address/port combination passed to `--metrics.addr` and `metrics.port` on startup - by default `127.0.0.1:6060/debug/metrics`. It is also possible to configure a panel by providing a JSON configuration model. Individual components are defined using the following syntax (the example below is for the CPU panel):
