Metrics referenceEnterprise Edition
You should use caution when interpreting unfamiliar metrics. Reading the Performance section is recommended to better understand the metrics. |
Types of metrics
Neo4j has the following types of metrics:
-
Global — covers the whole Neo4j DBMS.
-
Per database — covers an individual database.
The metrics fall into one of the following categories:
-
Gauge — shows an instantaneous reading of a particular value.
-
Counter — shows an accumulated value.
-
Histogram — shows the distribution of values.
Global metrics
Global metrics cover the whole database management system, and represents the status of the system as a whole.
Global metrics have the following name format: <user-configured-prefix>.<metric-name>
if metrics.namespaces.enabled
is false
, or <user-configured-prefix>.dbms.<metric-name>
if the setting is true
.
The <user-configured-prefix> can be configured with the metrics.prefix
configuration setting.
Metrics of this type are reported as soon as the database management system is available.
For example, all JVM related metrics are global.
In particular, the neo4j.vm.thread.count
metric has a default user-configured-prefix neo4j
and the metric name is vm.thread.count
.
By default, global metrics include:
-
Bolt metrics
-
Page cache metrics
-
GC metrics
-
Thread metrics
-
Database operation metrics
-
Web Server metrics
-
JVM metrics
Database metrics
Each database metric is reported for a particular database only. Database metrics are only available during the lifetime of the database. When a database becomes unavailable, all of its metrics become unavailable also.
Database metrics have the following name format: <user-configured-prefix>.<database-name>.<metric-name>
if metrics.namespaces.enabled
is false
, or <user-configured-prefix>.database.<database-name>.<metric-name>
if the setting is true
.
The <user-configured-prefix> can be configured with the metrics.prefix
configuration setting.
For example, any transaction metric is a database metric.
In particular, the neo4j.mydb.transaction.started
metric has a default user-configured-prefix neo4j
and is a metric for the mydb
database.
By default, database metrics include:
-
Transaction metrics
-
Checkpoint metrics
-
Log rotation metrics
-
Database data metrics
-
Cypher metrics
-
Causal clustering metrics
General-purpose metrics
Name | Description |
---|---|
|
The total number of Bolt sessions created by users since startup. This includes both succeeded and failed sessions (deprecated, use connections_opened instead). Useful for monitoring load via the Bolt drivers in combination with other metrics. (counter) |
|
The total number of Bolt connections opened since startup. This includes both succeeded and failed connections. Useful for monitoring load via the Bolt drivers in combination with other metrics. (counter) |
|
The total number of Bolt connections closed since startup. This includes both properly and abnormally ended connections. Useful for monitoring load via Bolt drivers in combination with other metrics. (counter) |
|
The total number of Bolt connections that are currently executing Cypher and returning results. Useful to track the overall load on Bolt connections. This is limited to the number of Bolt worker threads that have been configured via |
|
The total number of Bolt connections that are not currently executing Cypher or returning results. (gauge) |
|
The total number of messages received via Bolt since startup. Useful to track general message activity in combination with other metrics. (counter) |
|
The total number of messages that have started processing since being received. A received message may have begun processing until a Bolt worker thread becomes available. A large gap being observed between between |
|
The total number of Bolt messages that have completed processing whether successfully or unsuccessfully. Useful for tracking overall load. (counter) |
|
The total number of messages that have failed while processing. A high number of failures may indicate an issue with server and further investigation of the logs is recommended. (counter) |
|
(unsupported feature) When |
|
The total amount of time in milliseconds that worker threads have been processing messages. Useful for monitoring load via Bolt drivers in combination with other metrics. (counter) |
Name | Description |
---|---|
|
The total number of check point events executed so far. (counter) |
|
The total time, in milliseconds, spent in check pointing so far. (counter) |
|
The duration, in milliseconds, of the last check point event. Checkpoints should generally take several seconds to several minutes. Long checkpoints can be an issue, as these are invoked when the database stops, when a hot backup is taken, and periodically as well. Values over |
Name | Description |
---|---|
|
The total number of times Cypher has decided to re-plan a query. Neo4j caches 1000 plans by default. Seeing sustained replanning events or large spikes could indicate an issue that needs to be investigated. (counter) |
|
The total number of seconds waited between query replans. (counter) |
Name | Description |
---|---|
|
The total number of relationships in the database. (gauge) |
|
The total number of nodes in the database. A rough metric of how big your graph is. And if you are running a bulk insert operation you can see this tick up. (gauge) |
Name | Description |
---|---|
|
Used or reserved heap memory in bytes. (gauge) |
|
Used or reserved native memory in bytes. (gauge) |
|
Sum total used heap and native memory in bytes. (gauge) |
|
Sum total size of capacity of the heap and/or native memory pool. (gauge) |
|
Available unused memory in the pool, in bytes. (gauge) |
Name | Description |
---|---|
|
Count of successful database create operations. (counter) |
|
Count of successful database start operations. (counter) |
|
Count of successful database stop operations. (counter) |
|
Count of successful database drop operations. (counter) |
|
Count of failed database operations. (counter) |
|
Count of database operations which failed previously but have recovered. (counter) |
Name | Description |
---|---|
|
The total number of different relationship types stored in the database. Informational, not an indication of any issue. Spikes or large increases indicate large data loads, which could correspond with some behavior you are investigating. (gauge) |
|
The total number of different property names used in the database. Informational, not an indication of any issue. Spikes or large increases indicate large data loads, which could correspond with some behavior you are investigating. (gauge) |
|
The total number of relationships stored in the database. Informational, not an indication of any issue. Spikes or large increases indicate large data loads, which could correspond with some behavior you are investigating. (gauge) |
|
The total number of nodes stored in the database. Informational, not an indication of any issue. Spikes or large increases indicate large data loads, which could correspond with some behavior you are investigating. (gauge) |
Name | Description |
---|---|
|
Used or reserved heap memory in bytes. (gauge) |
|
Used or reserved native memory in bytes. (gauge) |
|
Sum total used heap and native memory in bytes. (gauge) |
|
Sum total size of capacity of the heap and/or native memory pool. (gauge) |
|
Available unused memory in the pool, in bytes. (gauge) |
Name | Description |
---|---|
|
The total number of exceptions seen during the eviction process in the page cache. (counter) |
|
The total number of page flushes executed by the page cache. (counter) |
|
The total number of page merges executed by the page cache. (counter) |
|
The total number of page unpins executed by the page cache. (counter) |
|
The total number of page pins executed by the page cache. (counter) |
|
The total number of page evictions executed by the page cache. (counter) |
|
The total number of cooperative page evictions executed by the page cache due to low available pages. (counter) |
|
The total number of page faults in the page cache. If this count keeps increasing over time, it may indicate that more page cache is required. However, note that when Neo4j Enterprise starts up, all page cache warmup activities result in page faults. Therefore, it is normal to observe a significant page fault count immediately after startup.(counter) |
|
The total number of page hits happened in the page cache. (counter) |
|
The ratio of hits to the total number of lookups in the page cache. Performance relies on efficiently using the page cache, so this metric should be in the 98-100% range consistently. If it is much lower than that, then the database is going to disk too often. (gauge) |
|
The ratio of number of used pages to total number of available pages. This metric shows what percentage of the allocated page cache is actually being used. If it is 100%, then it is likely that the hit ratio will start dropping, and you should consider allocating more RAM to page cache. (gauge) |
|
The total number of bytes read by the page cache. (counter) |
|
The total number of bytes written by the page cache. (counter) |
|
The total number of IO operations performed by page cache. |
|
The total number of times page cache flush IO limiter was throttled during ongoing IO operations. |
|
The total number of millis page cache flush IO limiter was throttled during ongoing IO operations. |
Name | Description |
---|---|
|
Count of successful queries executed. (counter) |
|
Count of failed queries executed. (counter) |
|
Execution time in milliseconds of queries executed successfully. (histogram) |
Name | Description |
---|---|
|
The total size of the database and transaction logs, in bytes. The total size of the database helps determine how much cache page is required. It also helps compare the total disk space used by the data store and how much is available. (gauge) |
|
The size of the database, in bytes. The total size of the database helps determine how much cache page is required. It also helps compare the total disk space used by the data store and how much is available. (gauge) |
Name | Description |
---|---|
|
The total number of transaction log rotations executed so far. (counter) |
|
The total time, in milliseconds, spent in rotating transaction logs so far. (counter) |
|
The duration, in milliseconds, of the last log rotation event. (gauge) |
|
The total number of bytes appended to transaction log. (counter) |
|
The total number of transaction log flushes. (counter) |
|
The size of the last transaction append batch. (gauge) |
Name | Description |
---|---|
|
The total number of started transactions. (counter) |
|
The highest peak of concurrent transactions. This is a useful value to understand. It can help you with the design for the highest load scenarios and whether the Bolt thread settings should be altered. (counter) |
|
The number of currently active transactions. Informational, not an indication of any issue. Spikes or large increases could indicate large data loads, or just high read load. (gauge) |
|
The number of currently active read transactions. (gauge) |
|
The number of currently active write transactions. (gauge) |
|
The total number of committed transactions. Informational, not an indication of any issue. Spikes or large increases indicate large data loads, or just high read load. (counter) |
|
The total number of committed read transactions. Informational, not an indication of any issue. Spikes or large increases indicate high read load. (counter) |
|
The total number of committed write transactions. Informational, not an indication of any issue. Spikes or large increases indicate large data loads, which could correspond with some behavior you are investigating. (counter) |
|
The total number of rolled back transactions. (counter) |
|
The total number of rolled back read transactions. (counter) |
|
The total number of rolled back write transactions. Seeing a lot of writes rolled back may indicate various issues with locking, transaction timeouts, etc. (counter) |
|
The total number of terminated transactions. (counter) |
|
The total number of terminated read transactions. (counter) |
|
The total number of terminated write transactions. (counter) |
|
The ID of the last committed transaction. Track this for each instance. (Cluster) Track this for each Core cluster member, and each Read Replica. Might break into separate charts. It should show one line, ever increasing, and if one of the lines levels off or falls behind, it is clear that this member is no longer replicating data and action is needed to rectify the situation. (counter) |
|
The ID of the last closed transaction. (counter) |
|
The transactions' size on heap in bytes. (histogram) |
|
The transactions' size in native memory in bytes. (histogram) |
Name | Description |
---|---|
|
The total number of idle threads in the jetty pool. (gauge) |
|
The total number of threads (both idle and busy) in the jetty pool. (gauge) |
Metrics specific to Causal Clustering
Name | Description |
---|---|
|
TX pull requests received from read replicas. (counter) |
Name | Description |
---|---|
|
Size of replicated data structures. (gauge) |
|
Discovery cluster member size. (gauge) |
|
Discovery cluster unreachable size. (gauge) |
|
Discovery cluster convergence. (gauge) |
Name | Description |
---|---|
|
The append index of the Raft log. Each index represents a write transaction (possibly internal) proposed for commitment. The values mostly increase, but sometimes they can decrease as a consequence of leader changes. The append index should always be less than or equal to the commit index. (gauge) |
|
The commit index of the Raft log. Represents the commitment of previously appended entries. Its value increases monotonically if you do not unbind the cluster state. The commit index should always be bigger than or equal to the append index. (gauge) |
|
The applied index of the Raft log. Represents the application of the committed Raft log entries to the database and internal state. The applied index should always be bigger than or equal to the commit index. The difference between this and the commit index can be used to monitor how up-to-date the follower database is. (gauge) |
|
The Raft Term of this server. It increases monotonically if you do not unbind the cluster state. (gauge) |
|
Transaction retries. (counter) |
|
Is this server the leader? Track this for each Core cluster member. It will report |
|
In-flight cache total bytes. (gauge) |
|
In-flight cache max bytes. (gauge) |
|
In-flight cache element count. (gauge) |
|
In-flight cache maximum elements. (gauge) |
|
In-flight cache hits. (counter) |
|
In-flight cache misses. (counter) |
|
Raft Log Entry Prefetch Lag. (gauge) |
|
Raft Log Entry Prefetch total bytes. (gauge) |
|
Raft Log Entry Prefetch buffer size. (gauge) |
|
Raft Log Entry Prefetch buffer async puts. (gauge) |
|
Raft Log Entry Prefetch buffer sync puts. (gauge) |
|
Delay between Raft message receive and process. (gauge) |
|
Timer for Raft message processing. (counter, histogram) |
|
The total number of Raft replication requests. It increases with write transactions (possibly internal) activity. (counter) |
|
The total number of Raft replication requests attempts. It is bigger or equal than the replication requests. (counter) |
|
The total number of Raft replication attempts that have failed. (counter) |
|
Raft Replication maybe count. (counter) |
|
The total number of Raft replication requests that have succeeded. (counter) |
|
The time elapsed since the last message from a leader in milliseconds. Should reset periodically. (gauge) |
Name | Description |
---|---|
|
The total number of pull requests made by this instance. (counter) |
|
The highest transaction id requested in a pull update by this instance. (counter) |
|
The highest transaction id that has been pulled in the last pull updates by this instance. (counter) |
Java Virtual Machine Metrics
The JVM metrics show information about garbage collections (for example, the number of events and time spent collecting), memory pools and buffers, and the number of active threads running.
They are environment dependent and therefore, may vary on different hardware and with different JVM configurations.
The metrics about the JVM’s memory usage expose values that are provided by the MemoryPoolMXBeans and BufferPoolMXBeans.
The memory pools are memory managed by the JVM, for example, neo4j.vm.memory.pool.g1_survivor_space
.
Therefore, if necessary, you can tune them using the JVM settings.
The buffer pools are space outside of the memory managed by the garbage collector.
Neo4j allocates buffers in those pools as it needs them.
You can limit this memory using JVM settings, but there is never any good reason for you to set them.
Name | Description |
---|---|
|
The current number of open file descriptors. (gauge) |
|
(OS setting) The maximum number of open file descriptors. It is recommended to be set to 40K file handles, because of the native and Lucene indexing Neo4j uses. If this metric gets close to the limit, you should consider raising it. (gauge) |
Name | Description |
---|---|
|
Accumulated garbage collection time in milliseconds. Long GCs can be an indication of performance issues, or potentially instability. If this approaches the heartbeat timeout in a cluster, it may cause unwanted leader switches. (counter) |
|
Total number of garbage collections. (counter) |
Name | Description |
---|---|
|
Amount of memory (in bytes) guaranteed to be available for use by the JVM. (gauge) |
|
Amount of memory (in bytes) currently used. This is the amount of heap space currently used at a given point in time. Monitor this to identify if you are maxing out consistently, in which case, you should increase initial and max heap size, or if you are underutilizing, you should decrease the initial and max heap sizes. (gauge) |
|
Maximum amount of heap memory (in bytes) that can be used. This is the amount of heap space currently used at a given point in time. Monitor this to identify if you are maxing out consistently, in which case, you should increase initial and max heap size, or if you are underutilizing, you should decrease the initial and max heap sizes. (gauge) |
Name | Description |
---|---|
|
Estimated number of buffers in the pool. (gauge) |
|
Estimated amount of memory used by the pool. (gauge) |
|
Estimated total capacity of buffers in the pool. (gauge) |
Name | Description |
---|---|
|
Estimated amount of memory in bytes used by the pool. (gauge) |
Name | Description |
---|---|
|
Accumulated detected VM pause time. (gauge) |
Name | Description |
---|---|
|
Estimated number of active threads in the current thread group. (gauge) |
|
The total number of live threads including daemon and non-daemon threads. (gauge) |