---
title: "仲裁服务监控 - OceanBase 数据库 V4.4.2 | OceanBase 文档中心"
description: 仲裁服务监控 功能适用性 该内容仅适用于 OceanBase 数据库企业版。OceanBase 数据库社区版暂不支持仲裁服务功能。 概述 仲裁服务（Arbitration Service）支持通过 Prometheus 协议采集监控指标。仲裁服务内置了标准的 GET /metrics 接口，可获取 arbserver…
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.4.2 LTS

# 仲裁服务监控

更新时间：2026-09-09 10:26:43

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.4.2/zh-CN/600.manage/700.monitor/500.arbitration-service-monitoring.md)

#### 功能适用性

该内容仅适用于 OceanBase 数据库企业版。OceanBase 数据库社区版暂不支持仲裁服务功能。

## 概述

仲裁服务（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 集群](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005283269)。
 - 已在外部环境部署 Prometheus Server，并确保 Prometheus Server 与 arbserver 之间网络互通。
 - （可选）如需可视化展示或告警，还需部署 Grafana 和 Alertmanager。

## 配置 Prometheus 抓取

### 配置指标采集端口

仲裁服务通过配置项 [`prometheus_metrics_port`](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007020161) 控制指标采集端口的开启与关闭。该服务的开启有两种方法：

#### 方法一：

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

```shell
-o "ob_startup_mode=arbitration,prometheus_metrics_port=2886"

```

完整的启动命令，请参见 [使用命令行部署两副本加仲裁服务的 OceanBase 集群](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005283269)。

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

```shell
-o "ob_startup_mode=arbitration,prometheus_metrics_port=0"

```

#### 方法二：

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

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

   ```shell
   alter system set prometheus_metrics_port = 2887；

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

仲裁服务是一个以特殊模式启动的轻量级 observer 进程，重启节点进程请参见[重启节点](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005282904)。

此时若想关闭指标采集接口，将 `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 或同一采集网络中的机器执行以下命令：

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

```

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

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

```

### 抓取配置

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

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

```

配置项说明如下：

| 参数 | 是否必选 | 说明 |
| --- | --- | --- |
| `job_name` | 是 | 抓取任务的名称，自定义即可。建议使用 `oceanbase-arbserver` 以便在 Prometheus 中快速识别。 |
| `metrics_path` | 否 | 指标暴露路径，默认为 `/metrics`，与 arbserver 内置接口一致，通常无需修改。 |
| `scrape_interval` | 否 | 抓取间隔，即 Prometheus 每次抓取指标数据的时间间隔。建议设置为 `15s`，过短会增加 arbserver 负载，过长会影响监控实时性。 |
| `targets` | 是 | arbserver 的访问地址，格式为 `<arbserver_ip>:<prometheus_metrics_port>`。其中 `prometheus_metrics_port` 为 arbserver 配置项 `prometheus_metrics_port` 的值，默认为 `2886`。如有多个 arbserver 实例，需将每个实例的地址加入该列表。 |
| `labels` | 否 | 为该抓取任务的所有指标附加自定义标签。示例中添加了 `service: arbserver` 标签，便于在 Grafana 或 PromQL 查询时按服务名过滤。 |

如有多个 arbserver 实例，需要将每个实例的地址加入 `targets` 列表，或接入部署平台已有的服务发现机制。有关 Prometheus 抓取配置的详细格式，请参见 [Prometheus Configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)。

### 验证抓取状态

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

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

   ```shell
   promtool check config <prometheus.yml>

   ```

   如果配置文件语法正确，输出结果中会显示 `SUCCESS`。
 2. 在 Prometheus Server 上 Reload 或重启 Prometheus 服务，使配置生效。

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

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

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

       ```shell
       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 状态，示例如下：

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

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

   ```shell
   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 的指标已正常采集，示例如下。

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

   ```

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

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

   ```

## 指标说明

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

### 资源和管理规模

| 指标 | 类型 | 含义 | 更新方式 |
| --- | --- | --- | --- |
| `arb_memory_usage_percent` | Gauge | arbserver 进程 VmRSS 占物理内存的百分比 | 每 10 秒 |
| `arb_cpu_usage_percent` | Gauge | arbserver 进程 CPU 使用率 | 每 10 秒，首次采样只建立基线 |
| `arb_disk_usage_percent` | Gauge | arbserver 数据目录所在文件系统使用率 | 每 10 秒 |
| `arb_cluster_count` | Gauge | 当前管理的集群数 | 生命周期事件更新 |
| `arb_tenant_count` | Gauge | 当前管理的租户数 | 生命周期事件更新 |
| `arb_ls_count` | Gauge | 当前管理的 LS 总数 | 生命周期事件更新 |

### LS 状态

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

| 指标 | 类型 | 含义 | 更新方式 |
| --- | --- | --- | --- |
| `arb_ls_has_leader` | Gauge | 仲裁视角下该 LS 是否存在 Leader；`1` 表示有，`0` 表示无 | 每 2 秒 |
| `arb_ls_election_count` | Counter | 仲裁侧观察到的选举次数 | 选举事件更新 |
| `arb_ls_config_version_proposal_id` | Gauge | `LogConfigVersion` 的 proposal id | 配置事件更新 |
| `arb_ls_config_version_config_seq` | Gauge | `LogConfigVersion` 的 config sequence | 配置事件更新 |
| `arb_ls_mode_version` | Gauge | `LogModeMeta` 的 mode version | 模式事件更新 |

### RPC 延迟

| 指标 | 类型 | 标签 | 含义 |
| --- | --- | --- | --- |
| `arb_rpc_process_latency_seconds` | Histogram | 无 | RPC 在 arbserver 端的排队加处理延迟 |
| `arb_rpc_transport_latency_seconds` | Histogram | 无 | 客户端发送到 arbserver 接收的传输延迟 |

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

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

```

#### 说明

两个 RPC Histogram 指标当前没有 pcode、cluster 或 tenant 标签，表示 arbserver 全局聚合结果。有关 Histogram 指标的查询方式，请参见 [Prometheus Histograms and Summaries](https://prometheus.io/docs/practices/histograms/)。

## 常用查询示例

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

- 查询 arbserver 抓取状态：

  ```promql
  up{job="oceanbase-arbserver"}

  ```
 - 查询当前无 Leader 的 LS：

  ```promql
  arb_ls_has_leader == 0

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

  ```promql
  increase(arb_ls_election_count[10m])

  ```
 - 查询服务端 RPC P99 延迟：

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

  ```
 - 查询网络传输 RPC P99 延迟：

  ```promql
  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` 以降低采集频率。

## 相关文档

- [监控概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005282454)
 - [系统监控指标概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005283395)
 - [仲裁服务概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005282750)
 - [为租户开启仲裁服务](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000005282746)

 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线