重要指标

为了确保您的应用程序平稳运行，您应该监控

**服务器负载**——托管 Neo4j 的机器上的负载。
**Neo4j 负载**——Neo4j 上的负载。
**集群健康状况**——确保集群按预期工作。
Neo4j 实例的**工作负载**。

建议阅读性能部分，以更好地了解指标。

服务器负载指标

监控硬件资源显示了运行 Neo4j 的服务器上的负载。

您可以使用诸如 collectd 守护程序或 Linux 上的 `systemd` 之类的实用程序来收集有关系统的信息。这些指标可以帮助您在工作负载增长时进行容量规划。

指标名称

描述

CPU 使用率

如果达到 100%，您可能需要额外的 CPU 容量。

已用内存

此指标告诉您是否快用完服务器上的所有可用内存。确保您的峰值在 95% 或以下，以降低内存不足的风险。有关更多信息，请参阅内存配置。

可用磁盘空间

观察数据的增长速度，以便您可以在用完存储空间之前规划额外的存储空间。这适用于 Neo4j 正在写入的所有磁盘。您也可以选择将日志文件写入不同的磁盘。

磁盘空间不足可能会中断系统可用性并导致数据库离线，从而造成数据库或日志文件损坏的风险。为了避免这种情况，应配置系统监控工具以监控用于数据库、索引和事务日志的所有驱动器上的可用磁盘空间。有关更多建议，请参见磁盘、RAM 和其他提示，以及监控服务器和监控数据库在 Neo4j 集群中。

Neo4j 负载指标

Neo4j 负载指标监控 Neo4j 所承受的压力。它们可以帮助进行容量规划。

指标名称指标描述

指标名称	指标	描述
堆使用情况	`<prefix>.dbms.vm.heap.used`	如果 Neo4j 始终使用 100% 的堆，请增加初始堆大小和最大堆大小。有关更多信息，请参见内存配置.
页面缓存	`<prefix>.dbms.page_cache.hit_ratio` 和 `<prefix>.dbms.page_cache.usage_ratio`	当请求错过页面缓存时，必须从速度慢得多的磁盘中获取数据。理想情况下，hit_ratio 大多数情况下应高于 98%。这显示了分配给页面缓存的内存使用量。如果达到 100%，请考虑增加页面缓存大小。
JVM 垃圾回收	`<prefix>.dbms.vm.gc.time.%s`	JVM 用于回收堆而不是执行其他工作的时间的比例。当数据库内存不足时，此指标可能会出现峰值。如果发生这种情况，它可能会停止处理并导致查询执行错误。如果似乎是这种情况，请考虑增加数据库的大小。
检查点时间	`<prefix>.database.<db>.check_point.duration`	应监控检查点持续时间，以确保其不会开始接近检查点之间的间隔。如果发生这种情况，请考虑以下步骤以提高检查点性能提高`db.checkpoint.iops.limit` 以使检查点更快，但前提是存在足够的 IOPS 预算以避免减慢提交过程。 `server.memory.pagecache.flush.buffer.enabled` / `server.memory.pagecache.flush.buffer.size_in_pages` 通过以一种与底层磁盘配合良好的方式（与块大小的良好倍数）写入数据批次，使检查点更快。更改检查点策略（`db.checkpoint.*`，`db.checkpoint.interval.time`）以实现更频繁/更小的检查点、连续检查点或按体积或 `tx` 计数进行检查点。有关更多信息，请参见检查点 IOPS 限制和检查点和日志修剪.

堆使用情况

<prefix>.dbms.vm.heap.used

如果 Neo4j 始终使用 100% 的堆，请增加初始堆大小和最大堆大小。有关更多信息，请参见内存配置.

页面缓存

<prefix>.dbms.page_cache.hit_ratio 和 <prefix>.dbms.page_cache.usage_ratio

当请求错过页面缓存时，必须从速度慢得多的磁盘中获取数据。理想情况下，hit_ratio 大多数情况下应高于 98%。这显示了分配给页面缓存的内存使用量。如果达到 100%，请考虑增加页面缓存大小。

JVM 垃圾回收

<prefix>.dbms.vm.gc.time.%s

JVM 用于回收堆而不是执行其他工作的时间的比例。当数据库内存不足时，此指标可能会出现峰值。如果发生这种情况，它可能会停止处理并导致查询执行错误。如果似乎是这种情况，请考虑增加数据库的大小。

检查点时间

<prefix>.database.<db>.check_point.duration

应监控检查点持续时间，以确保其不会开始接近检查点之间的间隔。如果发生这种情况，请考虑以下步骤以提高检查点性能

提高db.checkpoint.iops.limit 以使检查点更快，但前提是存在足够的 IOPS 预算以避免减慢提交过程。
server.memory.pagecache.flush.buffer.enabled / server.memory.pagecache.flush.buffer.size_in_pages 通过以一种与底层磁盘配合良好的方式（与块大小的良好倍数）写入数据批次，使检查点更快。
更改检查点策略（db.checkpoint.*，db.checkpoint.interval.time）以实现更频繁/更小的检查点、连续检查点或按体积或 tx 计数进行检查点。有关更多信息，请参见检查点 IOPS 限制和检查点和日志修剪.

Neo4j 集群健康指标

集群健康指标一目了然地表明集群成员的健康状况。了解哪个实例是领导者至关重要。领导者的负载模式不同于跟随者，跟随者应表现出类似的负载模式。

指标名称指标描述

指标名称	指标	描述
领导者	`<prefix>.database.<db>.cluster.raft.is_leader`	跟踪每个数据库主实例。如果它不是领导者，则报告 `0`，如果是领导者，则报告 `1`。所有这些的总和始终应为 `1`。但是，存在多个成员认为自己是领导者的瞬态时期，在此期间总和可能大于 `1`。
事务工作负载	`<prefix>.database.<db>.transaction.last_committed_tx_id`	最后提交的事务的 ID。跟踪每个 Neo4j 实例。它可能会分成单独的图表。它应该显示一条线，一直增加，如果其中一条线停止上升或落后，则很明显该实例不再复制数据，需要采取措施纠正这种情况。

领导者

<prefix>.database.<db>.cluster.raft.is_leader

跟踪每个数据库主实例。如果它不是领导者，则报告 0，如果是领导者，则报告 1。所有这些的总和始终应为 1。但是，存在多个成员认为自己是领导者的瞬态时期，在此期间总和可能大于 1。

事务工作负载

<prefix>.database.<db>.transaction.last_committed_tx_id

最后提交的事务的 ID。跟踪每个 Neo4j 实例。它可能会分成单独的图表。它应该显示一条线，一直增加，如果其中一条线停止上升或落后，则很明显该实例不再复制数据，需要采取措施纠正这种情况。

了解如何监控集群端点以获取状态信息的更多信息。

工作负载指标

这些指标有助于监控 Neo4j 实例的工作负载。这些指标的绝对值取决于您预期的工作负载类型。

指标名称指标描述

指标名称	指标	描述
Bolt 连接	`<prefix>.dbms.bolt.connections_running`	当前正在执行 Cypher 并返回结果的连接数。
节点/关系总数	`<prefix>.database.<db>.count.node` 和 `<prefix>.database.<db>.count.relationship`	（默认情况下未启用）不同关系类型的总数。不同属性名称的总数。关系的总数。节点的总数。
吞吐量	`<prefix>.database.<db>.db.query.execution.latency.millis`	此指标生成 99% 和 95% 百分位数事务延迟的直方图。有助于识别数据负载的峰值或增加。

Bolt 连接

<prefix>.dbms.bolt.connections_running

当前正在执行 Cypher 并返回结果的连接数。

节点/关系总数

<prefix>.database.<db>.count.node 和 <prefix>.database.<db>.count.relationship

（默认情况下未启用）不同关系类型的总数。不同属性名称的总数。关系的总数。节点的总数。

吞吐量

<prefix>.database.<db>.db.query.execution.latency.millis

此指标生成 99% 和 95% 百分位数事务延迟的直方图。有助于识别数据负载的峰值或增加。

有关 Neo4j 中所有可用指标的完整列表，请参见指标参考.