仲裁服务监控

概述

仲裁服务（Arbitration Service）支持通过 Prometheus 协议采集监控指标。仲裁服务内置了标准的 GET /metrics 接口，可获取 arbserver 的 CPU、内存和磁盘使用率，以及当前管理的集群、租户、LS、选举、配置版本、模式版本和 RPC 延迟等指标。

仲裁服务通过内置 HTTP Server 暴露监控指标，您可以使用 Prometheus Server 抓取和存储这些指标数据，并配合 Grafana 进行指标展示、使用 Alertmanager 进行告警。该功能不涉及 Prometheus、Grafana 和 Alertmanager 的安装与配置，您需要自行部署和配置这些外部组件。

通过仲裁服务的 Prometheus 监控指标，可以实时掌握 arbserver 的资源使用状况（CPU、内存、磁盘使用率），了解当前管理的集群、租户和 LS 数量，监控各 LS 的 Leader 状态及选举频率，跟踪配置版本和模式版本的变化情况，以及分析 RPC 延迟在网络传输和服务端处理阶段的分布。

前提条件

• 当前集群中已部署仲裁服务，部署仲裁服务的详细操作请参见 部署两副本加仲裁服务的 OceanBase 集群。
• 已在外部环境部署 Prometheus Server，并确保 Prometheus Server 与 arbserver 之间网络互通。
• （可选）如需可视化展示或告警，还需部署 Grafana 和 Alertmanager。

配置 Prometheus 抓取

配置指标采集端口

仲裁服务通过配置项 prometheus_metrics_port 控制指标采集端口的开启与关闭。该服务的开启有两种方法：

方法一：

在仲裁服务中启动配置中追加端口参数，即可开启指标采集接口。示例如下：

-o "ob_startup_mode=arbitration,prometheus_metrics_port=2886"

完整的启动命令，请参见 使用命令行部署两副本加仲裁服务的 OceanBase 集群。

使用默认配置时无需显式填写端口，arbserver 会尝试监听 2886。如需关闭指标采集接口，将该参数设为 0 即可。示例如下：

-o "ob_startup_mode=arbitration,prometheus_metrics_port=0"

方法二：

在集群运行期通过 alter system set 修改端口，重启 arbserver 进程后生效。

1. 通过 alter system set 修改端口。

   alter system set prometheus_metrics_port = 2887；
   

2. 重启仲裁服务进程后生效。

仲裁服务是一个以特殊模式启动的轻量级 observer 进程，重启节点进程请参见重启节点。

此时若想关闭指标采集接口，将 prometheus_metrics_port 的端口号改为 0 后，仍需重启生效。

行为说明

prometheus_metrics_port 配置项在不同配置场景下的行为说明如下。

• 未显式配置端口：使用默认端口 2886 暴露 /metrics。
• 配置为其他正数：arbserver 重启后改为监听指定端口。
• 配置为 0：不启动指标 HTTP Server，/metrics 不可访问。
• 修改端口但未重启：继续使用原端口，直到 arbserver 重启。
• 端口已被占用或监听失败：指标服务初始化失败并自动关闭，所有指标不再更新，但不影响 arbserver 正常启动，同时系统会在日志中记录 WARN 级别的监听错误信息（disable Prometheus monitoring）；待端口冲突问题解决后，需重启 arbserver 才能恢复指标采集。
• 一个 arbserver 服务多个集群：只需抓取一次 endpoint；LS 指标通过标签区分集群、租户和 LS。
• arbserver 重启：从持久化状态重新加载管理对象及相关版本指标。

验证指标接口可用性

配置完成后，可以通过 curl 命令验证指标接口是否可正常访问。

从 Prometheus Server 或同一采集网络中的机器执行以下命令：

curl -fsS http://<arbserver_ip>:2886/metrics

正常响应会包含 # HELP、# TYPE 以及 arb_* 指标数据。示例响应如下：

# HELP arb_cluster_count number of clusters managed
# TYPE arb_cluster_count gauge
arb_cluster_count 1

抓取配置

在 Prometheus 配置文件即 prometheus.yml 中增加一个 scrape job，用于抓取 arbserver 的指标数据。配置示例如下：

scrape_configs:
  - job_name: oceanbase-arbserver
    metrics_path: /metrics
    scrape_interval: 15s
    static_configs:
      - targets:
          - <arbserver_ip>:2886
        labels:
          service: arbserver

配置项说明如下：

如有多个 arbserver 实例，需要将每个实例的地址加入 targets 列表，或接入部署平台已有的服务发现机制。有关 Prometheus 抓取配置的详细格式，请参见 Prometheus Configuration。

验证抓取状态

完成抓取配置后，请按以下步骤验证 Prometheus 是否已成功抓取 arbserver 指标。

1. 在 Prometheus Server 上使用 prometheus 用户检查配置文件语法是否正确。

   promtool check config <prometheus.yml>
   

   如果配置文件语法正确，输出结果中会显示 SUCCESS。

2. 在 Prometheus Server 上 Reload 或重启 Prometheus 服务，使配置生效。

   • 如果 Prometheus 已启用热重载功能，可以使用任意有网络访问权限的用户通过 HTTP API 触发配置重载：

     curl -X POST http://<prometheus_ip>:9090/-/reload
     

   • 也可以使用 root 用户或通过 sudo 权限直接重启 Prometheus 服务：

     sudo systemctl restart prometheus
     

   查看日志 sudo journalctl -u prometheus -f，确认出现 Completed loading of configuration file 且无报错。

3. 在任意可访问 Prometheus Web UI 的机器上，确认 arbserver 的 target 状态为 UP。

   说明

   up 是 Prometheus 为每个抓取目标自动生成的指标，不属于 arbserver 自身暴露的 arb_* 指标。状态为 UP 说明 Prometheus 服务器成功向 arbserver 的 exposer 发起了 HTTP 请求，并且成功收到了符合格式的响应。

   • 使用浏览器访问 http://<prometheus_ip>:9090/targets，在 target 列表中找到 oceanbase-arbserver，确认其状态为 UP。

   • 也可以在任意可访问 Prometheus API 的机器上通过命令查询 target 状态，示例如下：

     curl -s http://<prometheus_ip>:9090/api/v1/targets | grep -o '"health":"[^"]*"'
     

4. 在任意可访问 Prometheus API 的机器上，查询 up 指标确认 arbserver 已被成功抓取，示例如下。

   curl -s "http://<prometheus_ip>:9090/api/v1/query?query=up%7Bjob%3D%22oceanbase-arbserver%22%7D"
   

   如果返回结果中 value 为 1，表示抓取正常；如果为 0，表示抓取失败，需要排查 Prometheus 与 arbserver 之间的网络连通性和端口配置。

5. 在任意可访问 Prometheus API 的机器上，查询 arb_cluster_count、arb_ls_has_leader 等业务指标，确认 arbserver 的指标已正常采集，示例如下。

   curl -s "http://<prometheus_ip>:9090/api/v1/query?query=arb_cluster_count"
   

   也可以列出所有 arb_ 前缀的指标，确认指标已完整采集，示例如下：

   curl -s "http://<prometheus_ip>:9090/api/v1/label/__name__/values" | grep '^arb_'
   

指标说明

arbserver 当前共提供 13 个逻辑指标，分为资源与管理规模、LS 状态和 RPC 延迟三大类。

资源和管理规模

LS 状态

以下指标均带有 cluster_id、tenant_id、ls_id 标签，用于区分不同的集群、租户和日志流。

RPC 延迟

Histogram 类型指标会在 /metrics 中展开为 _bucket、_sum 和 _count。默认 bucket 如下：

100us, 500us, 1ms, 5ms, 10ms, 50ms,
100ms, 500ms, 1s, 5s, 10s, +Inf

常用查询示例

以下查询语句可在 Prometheus Web UI 的查询框中直接执行，也可通过 Prometheus HTTP API 进行查询。

• 查询 arbserver 抓取状态：

  up{job="oceanbase-arbserver"}
  

• 查询当前无 Leader 的 LS：

  arb_ls_has_leader == 0
  

• 查询 10 分钟内的选举次数：

  increase(arb_ls_election_count[10m])
  

• 查询服务端 RPC P99 延迟：

  histogram_quantile(
    0.99,
    sum by (le) (rate(arb_rpc_process_latency_seconds_bucket[5m]))
  )
  

• 查询网络传输 RPC P99 延迟：

  histogram_quantile(
    0.99,
    sum by (le) (rate(arb_rpc_transport_latency_seconds_bucket[5m]))
  )
  

使用限制

• 当前不支持通过 SQL 在线切换指标采集端口，配置项 prometheus_metrics_port 为静态生效，修改后需要重启 arbserver 才能生效。
• 当前不支持 HTTPS 和接口认证，/metrics 接口为明文 HTTP，无认证和 TLS 加密。
• 当前不支持监听 IPv6 地址，固定监听 IPv4 地址 0.0.0.0。如果 observer 使用 IPv6 地址部署，Prometheus 将无法通过 IPv6 地址访问 /metrics 接口，导致仲裁服务监控没有数据。
• 当前不提供 arbserver 的自动发现机制，需要在 Prometheus 中手动配置静态 target，或接入部署平台已有的服务发现机制。
• 当前不提供预置的 Grafana Dashboard 和 Alertmanager 告警规则，需要您在 Grafana 和 Alertmanager 中自行创建和配置。
• 当前仅提供 CPU 使用率、内存使用率和磁盘使用率三个资源类指标，不包含完整的宿主机网络和文件系统监控；如需监控丢包、重传、只读文件系统等指标，建议使用 node_exporter。
• 当前 arbserver 指标不包含 observer 日志复制落后或 FPAXOS 状态信息，如 follower lag、Q1/Q2 或 Reconfirm 等待成员等。
• 当前两个 RPC Histogram 指标只有全局聚合值，不支持按 RPC 类型、集群或租户分析延迟。

安全与容量注意事项

• /metrics 接口监听所有 IPv4 网卡，且无认证和 TLS 加密。建议通过安全组、防火墙、容器网络或反向代理等方式，仅允许 Prometheus 采集网络访问该接口，避免将接口直接暴露到不可信网络。

• 同一机器上运行多个 arbserver 实例时，每个实例必须使用不同的端口。修改端口后，请同步更新 Prometheus 的 target 配置。

• 资源指标每 10 秒采样一次，Leader 状态每 2 秒刷新一次，实际监控数据的刷新延迟为 arbserver 采样间隔与 Prometheus scrape_interval 的叠加。建议在告警规则中结合状态持续时间设置 for 参数，避免因单次采样波动立即触发告警。

• 每个 LS 会生成 5 组带 cluster_id、tenant_id、ls_id 标签的指标。在大规模 LS 场景下，请评估抓取响应大小、Prometheus series 数量、存储成本和查询开销，必要时可适当增大 scrape_interval 以降低采集频率。

相关文档

• 监控概述

• 系统监控指标概述

• 仲裁服务概述

• 为租户开启仲裁服务