OCP 4.3.5部分接口数据异常

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OCP4.3.5
【 使用版本 】
【问题描述】
接口：/api/v2/compute/hosts
可以获取到所有服务器列表，示例：

{
    "alias": null,
    "architecture": "x86_64",
    "checkSystemInfoProductTypes": null,
    "checkSystemInfoRiskyCount": 0,
    "checkSystemInfoStatus": "UNINITIALIZED",
    "checkSystemInfoTaskId": -1,
    "createTime": "2023-08-30T11:23:26+08:00",
    "description": null,
    "hostAgentId": 9,
    "hostAgentStatus": "AVAILABLE",
    "hostAgentVersion": "4.3.5-20250319105844",
    "hostTags": [
        {
            "obproxyClusterId": 3,
            "obproxyClusterName": "idc1",
            "type": "idc1"
        }
    ],
    "id": 7,
    "idcDescription": null,
    "idcId": 6,
    "idcName": "idc1",
    "innerIpAddress": "10.10.10.142",
    "ioPerformance": [],
    "kind": "DEDICATED_PHYSICAL_MACHINE",
    "name": "xxxx",
    "operatingSystem": "5.10.0-25-amd64",
    "operatingSystemRelease": "10",
    "operatingTaskInstanceId": null,
    "publishPorts": null,
    "regionDescription": null,
    "regionId": 2,
    "regionName": "sys_region",
    "serialNumber": null,
    "services": [
        {
            "name": "xxxx",
            "softwarePackageId": 1,
            "type": "xxxx",
            "version": "4.2.0.0-7"
        }
    ],
    "sshPort": 22,
    "status": "ONLINE",
    "statusAnalysis": null,
    "tags": null,
    "typeDescription": null,
    "typeId": 2,
    "typeName": "xxxx",
    "updateTime": "2025-05-21T09:46:53+08:00",
    "vpcId": 1,
    "vpcName": "system-default"
}

值得注意的是 “hostAgentStatus”: “AVAILABLE”,是AVAILABLE但是入参请求以后：
/api/v2/compute/hosts?status=AVAILABLE

{
    "contents": [],
    "page": {
        "number": 1,
        "size": 5000,
        "totalElements": 0,
        "totalPages": 0
    }
}

结果就查不到了

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

1 个赞
#3

根据问题描述，您在使用 OCP 4.3.5 的 /api/v2/compute/hosts 接口时遇到了一个问题：虽然某些主机的 hostAgentStatus 状态为 AVAILABLE，但在通过查询参数 status=AVAILABLE 进行过滤时，却无法获取到这些主机的信息。

分析与解答

  1. 接口行为分析
    根据您提供的数据结构和接口返回结果：

    • /api/v2/compute/hosts 接口可以正常返回所有服务器列表，并且其中包含状态为 AVAILABLE 的主机。
    • 当使用查询参数 status=AVAILABLE 时，接口返回的结果为空 (totalElements: 0)。

    这表明接口的过滤逻辑可能存在问题，或者查询条件未能正确匹配到目标主机。

  2. 可能的原因

    • 字段映射问题：OCP 内部可能对 status 查询参数进行了额外的映射或转换，导致其与实际的 hostAgentStatus 字段不完全一致。例如，可能存在其他隐式的状态检查条件（如 operatingTaskInstanceId 或 checkSystemInfoStatus）影响了查询结果。
    • 缓存问题：OCP 的接口可能依赖于某种缓存机制，而缓存中的数据未及时更新，导致查询结果不一致。
    • 权限问题：当前用户可能没有足够的权限查看某些特定状态的主机。
    • API 实现问题：OCP 的 API 实现可能存在 bug，导致查询条件未能正确应用。

  3. 解决建议

    • 验证字段映射：尝试使用其他状态值（如 OFFLINE 或 RESTARTING）进行查询，观察是否能够正确返回结果。如果其他状态可以正常查询，而 AVAILABLE 无法查询，则可能是字段映射问题。
    • 检查日志：使用 obdiag 工具收集 OCP 的日志信息，查看是否有与该接口相关的错误或警告日志。
    • 升级版本：确认当前使用的 OCP 版本是否为最新稳定版本。如果不是，请尝试升级到最新版本以修复潜在的 bug。
    • 联系支持团队：如果上述方法无法解决问题，建议将问题详细信息（包括接口请求、返回结果、日志等）提交给 OceanBase 的官方支持团队，以便进一步排查。

  4. 临时解决方案
    如果需要快速获取状态为 AVAILABLE 的主机信息，可以考虑在客户端对返回的所有主机列表进行过滤。例如，使用 Python 脚本实现如下逻辑：

    import requests

# 获取所有主机信息
response = requests.get("http://<ocp-server>/api/v2/compute/hosts")
hosts = response.json()

# 过滤状态为 AVAILABLE 的主机
available_hosts = [host for host in hosts["contents"] if host["hostAgentStatus"] == "AVAILABLE"]

print(available_hosts)

  5. 总结
    根据文档库中的信息，目前无法直接确定问题的根本原因。建议按照上述步骤逐步排查，并在必要时联系 OceanBase 的官方支持团队以获取进一步帮助。

更多信息请查看:

  1. 查询主机列表
1 个赞
#5

写成hostAgentStatus呢？
/api/v2/compute/hosts?hostAgentStatus=AVAILABLE

1 个赞
#6

是的，入参这个是有的，这个感觉是ocp在设计字段的时候入参没有协调好导致的

2 个赞
#7

根据您的补充说明，问题可能确实与 OCP 在设计接口字段时的不一致或不协调有关。以下是进一步的分析和建议：

分析

  1. 字段设计不一致
    如果 /api/v2/compute/hosts 接口返回的 hostAgentStatus 字段值为 AVAILABLE，但在使用查询参数 status=AVAILABLE 时无法匹配到对应主机，这可能表明：

    • 查询参数 status 并未直接映射到 hostAgentStatus 字段。
    • OCP 内部可能存在多层状态转换逻辑，导致外部可见的状态（如 hostAgentStatus）与内部实际使用的状态（如 status 参数对应的字段）不一致。

  2. 潜在的设计问题

    • 字段命名冲突：OCP 的 API 设计中可能存在字段命名冲突或语义模糊的问题，导致用户难以理解 status 参数的具体含义。
    • 隐式条件限制：即使 hostAgentStatus 为 AVAILABLE，OCP 可能还会检查其他字段（如 checkSystemInfoStatus 或 operatingTaskInstanceId），只有在所有条件都满足时才会将主机包含在查询结果中。

建议

  1. 确认字段映射关系

    • 检查 OCP 的官方文档或联系技术支持团队，明确 status 查询参数具体映射到哪个内部字段。
    • 如果 status 确实未直接映射到 hostAgentStatus，可以尝试通过其他字段进行过滤。例如，如果 checkSystemInfoStatus 也影响查询结果，可以尝试构造更复杂的查询条件。

  2. 反馈设计问题

    • 将此问题反馈给 OCP 的开发团队，建议优化 API 设计，确保字段命名清晰、语义明确，并减少不必要的隐式条件限制。
    • 提供详细的复现步骤和日志信息，以便开发团队更快定位问题。

  3. 临时解决方案
    在问题修复之前，您可以继续使用客户端过滤的方式获取目标主机信息。例如，基于 Python 的脚本如下：

    import requests

# 获取所有主机信息
response = requests.get("http://<ocp-server>/api/v2/compute/hosts")
hosts = response.json()

# 过滤状态为 AVAILABLE 的主机
available_hosts = [host for host in hosts["contents"] if host["hostAgentStatus"] == "AVAILABLE"]

print(available_hosts)

  4. 升级版本
    如果当前使用的 OCP 版本较旧，建议升级到最新版本。新版本可能已经修复了类似的字段设计问题。

总结

根据文档库中的信息，目前无法确定 OCP 是否已知并修复了此类字段设计问题。建议您按照上述步骤排查问题，并在必要时联系 OceanBase 的官方支持团队以获取进一步帮助。同时，反馈此问题有助于 OCP 团队改进 API 设计，提升用户体验。

检索到的文档如下:

  1. ob_cluster_frozen_version_delta_over_threshold OB 集群冻结版本和基线版本的差值超限
  2. 查看采集项
  3. 执行计划变动导致性能变差
  4. ocp_http_request_timeout OCP HTTP 接口请求超时
  5. tenant_memstore_percent_over_threshold OB 租户内存使用百分比超限
  6. OCP 系统常见问题
  7. ob_tenant500_storage_short_meta_mem_hold_high OceanBase 500 租户 STORAGE_SHORT_TERM 模块内存占比过高
  8. ob_host_partition_count_over_threshold OB 服务器分区数量超限
  9. ob_tenant_compaction_error OB 租户合并出错
  10. ob_tenant_log_disk_usage_high OB 租户日志磁盘使用率超限

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

1 个赞
#8

结果中是有status的，你传入status=ONLINE 或则 hostAgentStatus=AVAILABLE 应该都可以

传status=AVAILABLE 是错误的

1 个赞
#9

是的，所以OCP这里的接口请求有问题，还是数据库设计有问题？创建 Binlog 集群里面的主机部分的列表接口就是这样入参的，所以获取不到数据！

1 个赞
#10

传错参数查不到数据 是符合预期的，
另一个问题：创建 Binlog 集群里面的主机部分的列表接口就是这样入参的，所以获取不到数据！

这个有相关日志或者截图吗？麻烦发下看下

1 个赞
#11

image
image2273×1656 274 KB

#12

好的，我看下，这个导致获取不到主机吗 部署失败了吗？

#13

接口请求如上所示，入参错了就是获取不到host列表

#14

这个接口获取不到应该是是预期的，这个是包含binlog服务的主机，不影响binlog集群的创建，
具体为什么这样传参 我再咨询下这块老师

image
image2920×1332 417 KB

#15

核心问题是服务器管理里面没有添加binlog服务器的功能或者选项，也没有添加binlog服务器的标签，这一点是很不合理的

#16

OCP这边的老师回复是这个接口的逻辑是： 查询的主机就是 可用且没有部署其他服务