监控集群端点以获取状态信息

集群公开了一些 HTTP 端点，可用于监控集群的健康状况。本节描述了这些端点并解释了它们的语义。

调整集群端点的安全设置

如果在 Neo4j 中启用了认证和授权，集群状态端点也需要认证凭据。设置 dbms.security.auth_enabled 控制是否启用原生认证提供者。对于某些负载均衡器和代理服务器，在请求中提供认证凭据并非一个选项。对于这些情况，请考虑在 neo4j.conf 中设置 dbms.security.cluster_status_auth_enabled=false 来禁用集群状态端点的认证。

统一端点

在主服务器和辅助服务器上都存在一组统一的端点，具有以下行为：

  • /db/<databasename>/cluster/writable — 用于将写流量导向特定实例。

  • /db/<databasename>/cluster/read-only — 用于将读流量导向特定实例。

  • /db/<databasename>/cluster/available — 可用于将任意请求类型导向可处理读事务的实例的通用情况。

  • /db/<databasename>/cluster/status — 提供此实例在集群中针对给定数据库的状态的详细描述。

  • /dbms/cluster/status — 提供此实例在集群中针对所有数据库的状态的详细描述。对于监控和协调滚动升级很有用。更多详情请参阅状态端点。

每个 /db/<databasename>/* 端点都指向一个特定的数据库。databaseName 路径参数代表数据库的名称。默认情况下，全新安装的 Neo4j 具有 system 和 neo4j 两个数据库，具有以下集群端点：

http://localhost:7474/dbms/cluster/status

http://localhost:7474/db/system/cluster/writable
http://localhost:7474/db/system/cluster/read-only
http://localhost:7474/db/system/cluster/available
http://localhost:7474/db/system/cluster/status

http://localhost:7474/db/neo4j/cluster/writable
http://localhost:7474/db/neo4j/cluster/read-only
http://localhost:7474/db/neo4j/cluster/available
http://localhost:7474/db/neo4j/cluster/status

尝试访问未托管在服务器上的数据库的端点将产生 404 响应。
表 1. 统一 HTTP 端点响应
端点 实例状态 返回码 响应体文本

/db/<databasename>/cluster/writable

领导者

200 OK

true

跟随者

404 Not Found

false

辅助

404 Not Found

false

/db/<databasename>/cluster/read-only

领导者

404 Not Found

false

跟随者

200 OK

true

辅助

200 OK

true

/db/<databasename>/cluster/available

领导者

200 OK

true

跟随者

200 OK

true

辅助

200 OK

true

/db/<databasename>/cluster/status

领导者

200 OK

JSON - 详情请参阅状态端点。

跟随者

200 OK

JSON - 详情请参阅状态端点。

辅助

200 OK

JSON - 详情请参阅状态端点。

/dbms/cluster/status

领导者

200 OK

JSON - 详情请参阅状态端点。

跟随者

200 OK

JSON - 详情请参阅状态端点。

辅助

200 OK

JSON - 详情请参阅状态端点。
示例 1. 使用集群监控端点

在命令行中，请求这些端点的常用方法是使用 curl。在没有参数的情况下，curl 会对提供的 URI 执行 HTTP GET 请求，并输出响应体文本（如果有）。如果需要响应码，只需添加 -v 标志以获取详细输出。以下是一些示例：

  • 在当前已选举为领导者的主服务器上请求 writable 端点，并输出详细信息

#> curl -v localhost:7474/db/neo4j/cluster/writable
* About to connect() to localhost port 7474 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 7474 (#0)
> GET /db/neo4j/cluster/writable HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
> Host: localhost:7474
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Access-Control-Allow-Origin: *
< Transfer-Encoding: chunked
< Server: Jetty(9.4.17)
<
* Connection #0 to host localhost left intact
true* Closing connection #0

状态端点

状态端点（位于 /db/<databasename>/cluster/status）用于协助滚动升级。更多信息请参阅《升级和迁移指南 → 集群》。

通常，在从集群中移除主数据库之前，需要确保每个主数据库都可以安全关闭。与直觉相反，主数据库可以安全关闭意味着**其他**大多数主数据库是健康的、已同步的，并且最近收到了该数据库领导者的消息。状态端点提供以下信息以帮助解决此类问题。

状态端点响应中的多个字段涉及到 Raft 算法的详细信息，该算法用于 Neo4j 集群以提供高可用性事务。在 Neo4j 集群中，每个数据库都有其独立的 Raft 组。因此，leader 和 raftCommandsPerSecond 等详细信息是特定于数据库的。
示例 2. 状态响应示例
{
  "lastAppliedRaftIndex":0,
  "votingMembers":["30edc1c4-519c-4030-8348-7cb7af44f591","80a7fb7b-c966-4ee7-88a9-35db8b4d68fe","f9301218-1fd4-4938-b9bb-a03453e1f779"],
  "memberId":"80a7fb7b-c966-4ee7-88a9-35db8b4d68fe",
  "leader":"30edc1c4-519c-4030-8348-7cb7af44f591",
  "millisSinceLastLeaderMessage":84545,
  "participatingInRaftGroup":true,
  "core":true,
  "isHealthy":true,
  "raftCommandsPerSecond":124
}
表 2. 状态端点描述
字段 类型 可选 示例 描述

core

布尔值

否

true

用于区分服务器是以主（核心）模式还是辅助模式托管数据库。

lastAppliedRaftIndex

数值

否

4321

集群中的每个事务都与一个 Raft 索引相关联。
指示最新应用的 Raft 日志索引是什么。

participatingInRaftGroup

布尔值

否

false

参与成员能够投票。当主服务器是投票成员的一部分并跟踪了领导者时，它被视为参与中。

votingMembers

字符串数组

否

[]

当领导者收到与该成员的通信时，该成员被视为投票成员。
此主服务器认为属于投票集成员的 memberId 列表。

isHealthy

布尔值

否

true

表示此集群成员上的本地数据库未遇到可能阻塞数据库操作的严重错误。

isHealthy 状态仅适用于此成员的本地数据库。它不反映集群数据库的整体健康状况。

即使数据库当前没有领导者且无法接受写事务，集群成员仍可能报告 "isHealthy": true。

memberId

字符串

否

30edc1c4-519c-4030-8348-7cb7af44f591

集群中的每个成员都有其唯一的 `memberId` 来标识自身。使用 `memberId` 来区分主服务器和辅助服务器。

leader

字符串

是

80a7fb7b-c966-4ee7-88a9-35db8b4d68fe

格式与 memberId 相同，但如果为空或缺失，则领导者未知。

millisSinceLastLeaderMessage

数值

是

1234

自上次类似心跳的领导者消息以来的毫秒数。与辅助服务器无关，因此不包括在内。

raftCommandsPerSecond 已弃用

数值

是

124

通过 clustering.status_throughput_window 设置可配置的采样窗口内 Raft 状态机平均吞吐量的估算值。raftCommandsPerSecond 并非一种有效的方式来监控服务器是否在更新中落后，因此已被弃用，并将在 Neo4j 的下一个主要版本中移除。建议在每个服务器上使用 <prefix>.clustering.core.commit_index 指标并查找差异。

实例启动后，可以访问状态端点以确保满足下表中列出的所有保证。

为了获得最准确的集群视图，强烈建议访问所有主成员上的 状态端点 并比较结果。下表解释了如何比较结果。

表 3. 通过状态端点访问的测量值
检查名称 计算方法 描述

allServersAreHealthy

每个主服务器的状态端点都指示 isHealthy==true。

确保整个集群的数据健康。每当任何主服务器的状态为 false 时，都表示存在更大的问题。

allVotingSetsAreEqual

对于任意两个主服务器（A 和 B），状态端点 A 的 votingMembers == 状态端点 B 的 votingMembers。

当投票开始时，所有主服务器彼此相等，并且所有成员都同意成员资格。

allVotingSetsContainAtLeastTargetCluster

对于所有主服务器（S），排除主服务器 Z（待关闭），S 中的每个成员在其投票集中都包含 S。成员资格是使用状态端点中的 memberId 和 votingMembers 确定的。

有时网络条件不理想，关闭与最初计划不同的主服务器可能更合理。如果对所有主服务器运行此检查，符合此条件的服务器可以被关闭（前提是其他条件也已满足）。

hasOneLeader

对于任意两个主服务器（A 和 B），A.leader == B.leader && leader!=null。

如果领导者不同，则可能存在分区（或者，这也可能由于时机不当而发生）。如果领导者未知，则表示领导者消息实际上已超时。

noMembersLagging

对于 lastAppliedRaftIndex = min 的主服务器 A 和 lastAppliedRaftIndex = max 的主服务器 B，B.lastAppliedRaftIndex-A.lastAppliedRaftIndex<raftIndexLagThreshold。

如果主服务器之间应用的索引存在较大差异，则关闭主服务器可能存在危险。

raftIndexLagThreshold 帮助您监控集群中应用 Raft 日志条目的延迟并设置适当的阈值。您应该选择适合您的特定集群和工作负载的 raftIndexLagThreshold。在正常情况下测量报告的延迟并选择略高于该值的阈值是选择合适值的好方法。例如，您在特定工作负载的所有阶段观察该指标（最大和最小 lastAppliedRaftIndex 之间的差异），发现它在所有工作时间都在 100 或更少，但在周六会飙升到 5,000 几个小时。然后，根据您的监控需求或能力，您可以设置一个工作日阈值 120 和一个周末阈值 6,000，或者只设置一个整体阈值 6,000。这些阈值有助于识别性能问题。

组合状态端点

在使用状态端点支持滚动升级时，需要评估主服务器是否可以安全地关闭**所有**数据库。为了避免对每个 /db/<databasename>/cluster/status 端点发出单独的请求，请改用 /dbms/cluster/status。

此端点返回一个 JSON 数组，其元素包含与单数据库版本相同的字段，以及 databaseName 和 databaseUuid 字段。

示例 3. 组合状态响应示例
[
  {
    "databaseName": "neo4j",
    "databaseUuid": "f4dacc01-f88a-4512-b3bf-68f7539c941e",
    "databaseStatus": {
      "lastAppliedRaftIndex": -1,
      "votingMembers": [
        "0cff51ad-7cee-44cc-9102-538fc4544b95",
        "90ff5df1-f5f8-4b4c-8289-a0e3deb2235c",
        "99ca7cd0-6072-4387-bd41-7566a98c6afc"
      ],
      "memberId": "90ff5df1-f5f8-4b4c-8289-a0e3deb2235c",
      "leader": "90ff5df1-f5f8-4b4c-8289-a0e3deb2235c",
      "millisSinceLastLeaderMessage": 0,
      "raftCommandsPerSecond": 0.0,
      "core": true,
      "participatingInRaftGroup": true,
      "healthy": true
    }
  },
  {
    "databaseName": "system",
    "databaseUuid": "00000000-0000-0000-0000-000000000001",
    "databaseStatus": {
      "lastAppliedRaftIndex": 7,
      "votingMembers": [
        "0cff51ad-7cee-44cc-9102-538fc4544b95",
        "90ff5df1-f5f8-4b4c-8289-a0e3deb2235c",
        "99ca7cd0-6072-4387-bd41-7566a98c6afc"
      ],
      "memberId": "90ff5df1-f5f8-4b4c-8289-a0e3deb2235c",
      "leader": "90ff5df1-f5f8-4b4c-8289-a0e3deb2235c",
      "millisSinceLastLeaderMessage": 0,
      "raftCommandsPerSecond": 0.0,
      "core": true,
      "participatingInRaftGroup": true,
      "healthy": true
    }
  }
]
© . All rights reserved.