Add anchors to the metrics tables (#1225) (#1231)

Co-authored-by: Reneta Popova <[email protected]>

Author: NataliaIvakina

modules/ROOT/pages/monitoring/metrics/reference.adoc

@@ -39,14 +39,15 @@ In particular, the `neo4j.dbms.vm.thread.count` metric has a default user-config
 By default, global metrics include:
 
 
-* Bolt metrics
-* Page cache metrics
-* GC metrics
+* <<bolt-metrics, Bolt metrics>>
+* <<db-page-cache-metrics, Page cache metrics>>
+* <<gc-metrics, GC metrics>>
 * Thread metrics
-* Database operation metrics
+* <<db-operation-count-metrics, Database operation metrics>>
 * Web Server metrics
-* JVM metrics
+* <<jvm-metrics, JVM metrics>>
 
+[[database-metrics]]
 === Database metrics
 
 Each database metric is reported for a particular database only.
@@ -62,16 +63,17 @@ In particular, the `neo4j.database.mydb.transaction.started` metric has a defaul
 
 By default, database metrics include:
 
- * Transaction metrics
- * Checkpoint metrics
- * Log rotation metrics
- * Database data metrics
- * Cypher metrics
- * Clustering metrics
+ * <<db-tx-metrics, Transaction metrics>>
+ * <<checkpointing-metrics, Checkpoint metrics>>
+ * <<db-tx-log-metrics, Log rotation metrics>>
+ * <<db-data-metrics, Database data metrics>>
+ * <<cypher-metrics, Cypher metrics>>
+ * <<clustering-metrics, Clustering metrics>>
 
 [[metrics-general-purpose]]
 == General-purpose metrics
 
+[[bolt-metrics]]
 .Bolt metrics
 
 [options="header",cols="<3m,<4"]
@@ -96,6 +98,7 @@ By default, database metrics include:
 |<prefix>.bolt_driver.execute_calls|The total number of driver-level execute function calls. (counter)
 |===
 
+[[checkpointing-metrics]]
 .Database checkpointing metrics
 
 [options="header",cols="<3m,<4"]
@@ -112,6 +115,7 @@ By default, database metrics include:
 |<prefix>.check_point.io_limit|The IO limit used during the last checkpoint event. (gauge)
 |===
 
+[[cypher-metrics]]
 .Cypher metrics
 
 [options="header",cols="<3m,<4"]
@@ -121,6 +125,7 @@ By default, database metrics include:
 |<prefix>.cypher.replan_wait_time|The total number of seconds waited between query replans. (counter)
 |===
 
+[[db-data-count-metrics]]
 .Database data count metrics
 
 [options="header",cols="<3m,<4"]
@@ -130,6 +135,7 @@ By default, database metrics include:
 |<prefix>.neo4j.count.node|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)
 |===
 
+[[db-neo4j-pool-metrics]]
 .Database neo4j pools metrics
 
 [options="header",cols="<3m,<4"]
@@ -142,6 +148,8 @@ By default, database metrics include:
 |<prefix>.pool.<pool>.<database>.free|Available unused memory in the pool, in bytes. (gauge)
 |===
 
+
+[[db-operation-count-metrics]]
 .Database operation count metrics
 
 [options="header",cols="<3m,<4"]
@@ -155,6 +163,7 @@ By default, database metrics include:
 |<prefix>.db.operation.count.recovered|Count of database operations that failed previously but have recovered. (counter)
 |===
 
+[[db-state-count-metrics]]
 .Database state count metrics
 
 [options="header",cols="<3m,<4"]
@@ -165,6 +174,7 @@ By default, database metrics include:
 |<prefix>.db.state.count.desired_started|Databases that desire to be started on this server. (gauge)
 |===
 
+[[db-data-metrics]]
 .Database data metrics
 
 [options="header",cols="<3m,<4"]
@@ -176,6 +186,7 @@ By default, database metrics include:
 |<prefix>.ids_in_use.node|The total number of internally generated reusable IDs for the nodes stored in the database. These IDs do not reflect changes in the actual data. If you want to have a rough metric of how big your graph is, use `<prefix>.neo4j.count.node` instead. (gauge)
 |===
 
+[[global-neo4j-pools-metrics]]
 .Global neo4j pools metrics
 
 [options="header",cols="<3m,<4"]
@@ -188,6 +199,7 @@ By default, database metrics include:
 |<prefix>.dbms.pool.<pool>.free|Available unused memory in the pool, in bytes. (gauge)
 |===
 
+[[db-page-cache-metrics]]
 .Database page cache metrics
 
 [options="header",cols="<3m,<4"]
@@ -218,6 +230,7 @@ By default, database metrics include:
 |<prefix>.page_cache.pages_copied|The total number of page copies happened in the page cache. (counter)
 |===
 
+[[query-execution-metrics]]
 .Query execution metrics
 
 [options="header",cols="<3m,<4"]
@@ -237,6 +250,7 @@ By default, database metrics include:
 |<prefix>.db.query.execution.slotted.latency.millis|Execution time in milliseconds of queries executed successfully in slotted runtime. (histogram)
 |===
 
+[[query-routing-metrics]]
 .Query routing metrics
 
 [options="header",cols="<3m,<4"]
@@ -250,6 +264,7 @@ The total number of queries executed remotely to a member of the same cluster. (
 The total number of queries executed remotely to a member of a different cluster. (counter)
 |===
 
+[[db-store-size-metrics]]
 .Database store size metrics
 
 [options="header",cols="<3m,<4"]
@@ -259,6 +274,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.store.size.database|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)
 |===
 
+[[db-tx-log-metrics]]
 .Database transaction log metrics
 
 [options="header",cols="<3m,<4"]
@@ -272,6 +288,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.log.append_batch_size|The size of the last transaction append batch. (gauge)
 |===
 
+[[db-tx-metrics]]
 .Database transaction metrics
 
 [options="header",cols="<3m,<4"]
@@ -297,6 +314,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.transaction.tx_size_native|The transactions' size in native memory in bytes. (histogram)
 |===
 
+[[db-index-metrics]]
 .Database index metrics
 
 [options="header",cols="<3m,<4"]
@@ -321,6 +339,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.index.vector.populated|The total number of vector index population jobs that have been completed. (counter)
 |===
 
+[[server-metrics]]
 .Server metrics
 
 [options="header",cols="<3m,<4"]
@@ -334,6 +353,7 @@ The total number of queries executed remotely to a member of a different cluster
 [[clustering-metrics]]
 == Metrics specific to clustering
 
+[[catchup-metrics]]
 .Catchup metrics
 
 [options="header",cols="<3m,<4"]
@@ -342,6 +362,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.cluster.catchup.tx_pull_requests_received|TX pull requests received from secondaries. (counter)
 |===
 
+[[discovery-db-primary-metrics]]
 .Discovery database primary metrics
 
 [options="header",cols="<3m,<4"]
@@ -355,6 +376,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.cluster.discovery.restart.failed_count|Discovery restart failed count. (gauge)
 |===
 
+[[raft-db-primary-metrics]]
 .Raft database primary metrics
 
 [options="header",cols="<3m,<4"]
@@ -388,6 +410,7 @@ The total number of queries executed remotely to a member of a different cluster
 |<prefix>.cluster.raft.last_leader_message|The time elapsed since the last message from a leader in milliseconds. Should reset periodically. (gauge)
 |===
 
+[[store-copy-metrics]]
 .Store copy metrics
 
 [options="header",cols="<3m,<4"]
@@ -413,7 +436,8 @@ The buffer pools are space outside of the memory managed by the garbage collecto
 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.
 
-.JVM file descriptor metrics.
+[[jvm-file-descriptor-metrics]]
+.JVM file descriptor metrics
 
 [options="header",cols="<3m,<4"]
 |===
@@ -422,7 +446,8 @@ You can limit this memory using JVM settings, but there is never any good reason
 |<prefix>.vm.file.descriptors.maximum|(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)
 |===
 
-.GC metrics.
+[[gc-metrics]]
+.GC metrics
 
 [options="header",cols="<3m,<4"]
 |===
@@ -431,7 +456,8 @@ You can limit this memory using JVM settings, but there is never any good reason
 |<prefix>.vm.gc.count.<gc>|Total number of garbage collections. (counter)
 |===
 
-.JVM Heap metrics.
+[[jvm-heap-metrics]]
+.JVM heap metrics
 
 [options="header",cols="<3m,<4"]
 |===
@@ -441,7 +467,8 @@ You can limit this memory using JVM settings, but there is never any good reason
 |<prefix>.vm.heap.max|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 the initial and max heap size, or if you are underutilizing, you should decrease the initial and max heap sizes. (gauge)
 |===
 
-.JVM memory buffers metrics.
+[[jvm-memory-buffers-metrics]]
+.JVM memory buffers metrics
 
 [options="header",cols="<3m,<4"]
 |===
@@ -451,23 +478,26 @@ You can limit this memory using JVM settings, but there is never any good reason
 |<prefix>.vm.memory.buffer.<bufferpool>.capacity|Estimated total capacity of buffers in the pool. (gauge)
 |===
 
-.JVM memory pools metrics.
+[[jvm-memory-pools-metrics]]
+.JVM memory pools metrics
 
 [options="header",cols="<3m,<4"]
 |===
 |Name |Description
 |<prefix>.vm.memory.pool.<pool>|Estimated amount of memory in bytes used by the pool. (gauge)
 |===
 
-.JVM pause time metrics.
+[[jvm-pause-time-metrics]]
+.JVM pause time metrics
 
 [options="header",cols="<3m,<4"]
 |===
 |Name |Description
 |<prefix>.vm.pause_time|Accumulated detected VM pause time. (counter)
 |===
 
-.JVM threads metrics.
+[[jvm-threads-metrics]]
+.JVM threads metrics
 
 [options="header",cols="<3m,<4"]
 |===