obproxy进程运行正常,OCP告警报obproxy进程不可用

【 使用环境 】生产环境
【 OB or 其他组件 】OCP4.3.1 OBProxy 4.3.2
【 使用版本 】社区版
【问题描述】清晰明确描述问题
OCP告警报55和57主机的obproxy进程不可用


登录终端查看obproxy进程运行均正常


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

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

根据您提供的信息,OCP 告警显示 OBProxy 进程不可用,但实际登录终端检查发现 OBProxy 进程运行正常。以下是可能的原因及排查步骤:


可能原因分析

  1. 网络通信问题
    OCP 与 OBProxy 之间的网络可能存在异常,导致 OCP 无法正确检测到 OBProxy 的状态。

  2. OBProxy 端口监听异常
    虽然 OBProxy 进程存在,但其监听端口可能未正常工作,导致 OCP 无法连接。

  3. OCP Agent 异常
    OCP 通过 Agent 检测 OBProxy 状态,Agent 自身可能存在故障或配置错误。

  4. 告警误报
    OCP 的告警机制可能存在短暂的误报情况,需进一步确认。

  5. OBProxy 配置问题
    OBProxy 的配置文件可能存在问题,导致其虽然启动成功,但无法正常提供服务。


排查步骤

1. 检查网络通信

  • 在 OCP 主机上执行以下命令,确认是否能与 OBProxy 的监听端口建立连接:
    netstat -a | grep -i established | grep "OBProxy_IP:OBProxy_Port"
    
    • 如果有回显信息,则网络通信正常。
    • 如果没有回显信息,则可能是网络通信故障,需进一步排查防火墙或网络配置。

2. 检查 OBProxy 监听端口

  • 登录 OBProxy 所在主机,确认其监听端口是否正常:
    netstat -anp | grep 2883
    
    • 如果监听端口不存在,说明 OBProxy 的服务未正常启动。

3. 检查 OCP Agent 状态

  • 在 OCP 界面中,选择告警的 OBProxy 主机,进入 OCP Agent 页签,查看 进程列表 中 OBProxy 相关进程是否异常。
  • 如果 OCP Agent 异常,可尝试重启 OCP Agent:
    ocp-agent restart
    

4. 检查 OBProxy 配置文件

  • 确认 OBProxy 的配置文件是否正确,尤其是监听端口、租户信息等关键配置。
  • 配置文件路径通常为:/home/admin/obproxy/etc/obproxy.conf

5. 手动测试 OBProxy 连接

  • 使用 telnetnc 命令测试 OBProxy 的监听端口是否可达:
    telnet OBProxy_IP 2883
    
    • 如果连接失败,可能是 OBProxy 服务异常或网络问题。

6. 收集日志信息

  • 如果以上步骤均未发现问题,收集 OBProxy 和 OCP 的相关日志信息:
    • OBProxy 日志路径:/home/admin/obproxy/log
    • OCP 告警事件页面查看是否存在 OBProxy 日志告警。
    • OS 日志路径:/var/log/messages,搜索 error 关键字。

7. 重启 OBProxy

  • 如果确认 OBProxy 存在异常,可以尝试手动拉起 OBProxy 守护进程(尽量避免直接在 OCP 白屏重启):
    cd /opt/taobao/install/obproxy-3.4.0 && bin/obproxyd.sh -c start -r /home/admin/logs/obproxy -n ODPT2 -p 2883
    

总结

如果经过上述排查后仍未解决问题,请将收集的日志信息提交给 OceanBase 技术支持团队进行进一步分析。同时,建议定期检查 OBProxy 和 OCP 的运行状态,确保其配置和网络环境正常。

希望以上信息对您有所帮助!

更多信息请查看:

  1. ODP 服务高可用
  2. system_obproxy_unavailable 系统 OBProxy 不可用
  3. 删除 OBProxy
  4. obproxyd_process_dead OBProxy 守护进程不存在
  5. obproxy_process_dead OBProxy 进程不存在
  6. odp_sql_execute_failed SQL 执行失败次数超限
  7. os_observer_not_exist OB server 进程不存在
  8. obproxyd_process_stop OBProxy 守护进程停止
  9. monitor_exporter_unavaliable 监控 exporter 异常
  10. obproxy_client_connections_usage_over_threshold OBProxy 客户端连接使用率超限
1 个赞

包含告警时段的 obproxy.log,obproxy_error.log 麻烦发下

1 个赞

好的,审核完社区邮箱私发

1 个赞

好的,感谢您的理解与配合!如果您在审核过程中有任何疑问或需要进一步的技术支持,可以随时联系我或 OceanBase 的技术支持团队。社区邮箱是一个很好的交流渠道,期待您的私信。

同时,为了帮助您更高效地解决问题,以下是一些常用的资源和工具:

  1. OceanBase 社区文档

  2. OBDiag 工具

    • 用于快速收集诊断信息,便于问题定位。
    • 使用方法:obdiag collect logobdiag collect system_info
  3. OCP 平台

    • 如果您使用 OCP 进行集群管理,可以通过其内置的告警和日志功能快速定位问题。

如有需要,请随时召唤我!祝您问题顺利解决,使用 OceanBase 社区版愉快! :blush:

更多信息请查看:

  1. 获取所有资源池信息
  2. 修改集群级日志归档状态
  3. 新增租户副本
  4. 删除租户副本
  5. 查看集群级备份任务
  6. 发起单个租户备份
  7. 获取回收站中的所有租户信息
  8. 修改单个租户日志归档状态
  9. 查看单个租户备份任务
  10. 修改租户副本

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

1 个赞

邮箱私发我一下,我邮箱转给你

1 个赞

OK

1 个赞

好的,老师,邮箱已经转发,内容有55和57两台主机的obproxy相关日志

1 个赞

从日志看是有obproxy进程频繁启动失败的报错,
除了55和57节点这个集群还有其它不告警的obproxy节点吗?

另外麻烦取下55和57节点包含告警时间的 monagent.log和mgragent.log

55

[2025-05-12 11:06:34.903985] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [60230][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f54dc854555 0x1e4e47
[2025-05-12 11:06:36.019213] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [60382][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f9e9a3ef555 0x1e4e47
[2025-05-12 11:06:39.499741] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [60551][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fb845bbb555 0x1e4e47
[2025-05-12 11:06:40.328145] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [60801][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fed5f0e2555 0x1e4e47
[2025-05-12 11:06:41.417660] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [60958][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f704f477555 0x1e4e47
[2025-05-12 11:06:42.530299] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [61115][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fef91572555 0x1e4e47
[2025-05-12 11:06:43.612687] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [61309][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f9808d9b555 0x1e4e47
[2025-05-12 11:06:44.749094] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [61461][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f029852b555 0x1e4e47
……
grep "obproxy start failed" obproxy\ \(6\).log|wc -l
     227

57

[2025-05-12 11:10:30.087835] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [1801][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fc08b093555 0x1e4e47
[2025-05-12 11:10:31.170923] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2029][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f616a26c555 0x1e4e47
[2025-05-12 11:10:32.383642] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2185][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f93e598c555 0x1e4e47
[2025-05-12 11:10:33.336195] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2375][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fcbee029555 0x1e4e47
[2025-05-12 11:10:34.430592] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2585][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7effd7422555 0x1e4e47
[2025-05-12 11:10:35.516723] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2744][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f275a9b6555 0x1e4e47
[2025-05-12 11:10:36.722007] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2903][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
[2025-05-12 11:10:37.694010] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [3059][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fcc97a62555 0x1e4e47
[2025-05-12 11:10:38.769328] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [3218][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f7b9f428555 0x1e4e47
[2025-05-12 11:10:39.867512] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [3375][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7fc217191555 0x1e4e47
[2025-05-12 11:10:40.943864] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [3531][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f95ce1ab555 0x1e4e47
[2025-05-12 11:10:42.035924] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [4062][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f6463453555 0x1e4e47
[2025-05-12 11:10:56.039830] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [4404][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7ff7bdffd555 0x1e4e47
grep "obproxy start failed" obproxy57.log|wc -l     
      55

有不告警的obproxy节点

那应该是不告警的节点在持续提供服务,这两个节点确实有异常,需要再分析下

老师,邮箱发过去了

本质上还是proxy的端口被占用了,这个obproxy集群是使用OCP新部署的还是升级上来的?
如果是新部署的 部署好就出现这个现象了吗?
有使用负载均衡吗?

[2025-05-12 11:10:36.721805] INFO  [PROXY] start_read_stale_feedback_clean_task (ob_read_stale_processor.cpp:460) [2903][Y0-0000000000000000] [lt=0] [dc=0] succ to start read stale feedback clean task(interval=17522494)
[2025-05-12 11:10:36.721895] WDIAG [PROXY.SOCK] listen_proxy_mode (ob_connection.cpp:588) [2903][Y0-0000000000000000] [lt=0] [dc=0] fail to bind(addr_={0.0.0.0:2883}, errno=98, errmsg="Address already in use", ret=-10098)
[2025-05-12 11:10:36.721922] WDIAG [PROXY.SOCK] listen (ob_connection.cpp:522) [2903][Y0-0000000000000000] [lt=0] [dc=0] listen proxy mode failed(ret=-10098)
[2025-05-12 11:10:36.721924] EDIAG [PROXY.NET] do_listen (ob_net_accept.cpp:298) [2903][Y0-0000000000000000] [lt=0] [dc=0] fail to listen(server_.accept_addr_={0.0.0.0:2883}, errno=98, errmsg="Address already in use", ret=-10098) BACKTRACE:0x240933 0x2261ca 0x1edfa0 0x14f1df7 0x653f44 0x650dfb 0x6858de 0x41dbfb 0x40c349 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
[2025-05-12 11:10:36.721970] EDIAG [PROXY.NET] main_event (ob_mysql_session_accept.cpp:64) [2903][Y0-0000000000000000] [lt=0] [dc=0] ObNetAccept fail to do listen(event=204, ret=-10098) BACKTRACE:0x240933 0x2261ca 0x1ed359 0x6ad894 0x14f214f 0x653f44 0x650dfb 0x6858de 0x41dbfb 0x40c349 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
[2025-05-12 11:10:36.721985] EDIAG [PROXY.NET] accept_internal (ob_unix_net_processor.cpp:164) [2903][Y0-0000000000000000] [lt=0] [dc=0] fail to do_listen BLOCKING(ret=-10098) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x654cf2 0x650dfb 0x6858de 0x41dbfb 0x40c349 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
[2025-05-12 11:10:36.721993] EDIAG [PROXY] start_mysql_proxy_acceptor (ob_mysql_proxy_server_main.cpp:180) [2903][Y0-0000000000000000] [lt=0] [dc=0] fail to execute ipv4 main accept(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x685969 0x41dbfb 0x40c349 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
[2025-05-12 11:10:36.722001] EDIAG [PROXY] start (ob_proxy.cpp:450) [2903][Y0-0000000000000000] [lt=0] [dc=0] fail to start mysql accept server(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x41e3f3 0x40c349 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
[2025-05-12 11:10:36.722007] EDIAG [PROXY] do_start_work (ob_proxy_main.cpp:743) [2903][Y0-0000000000000000] [lt=0] [dc=0] obproxy start failed(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x40c510 0x413213 0x1c73f4 0x7f56a1ca2555 0x1e4e47
----------------------------------------------------------------------------------
[2025-05-12 11:10:36.722022] EDIAG [PROXY] start (ob_proxy_main.cpp:519) [2903][Y0-0000000000000000] [lt=0] [dc=0] fail to do start work(ret=-4016) BACKTRACE:0x240933 0x2261ca 0x1ebbef 0x41356f 0x1c73f4 0x7f56a1ca2555 0x1e4e47

OCP部署的,最近出现的这个现象,最近只有binlog_server_ip配置的变更,目前取消binlog_server_ip设置,重启obproxy进程才解决的。我们ODP用的是域名

obbinlog使用的哪个版本?binlog_server_ip怎么变更的呢?

4.0.1,binlog_server_ip参数就是在OCP上设置的

意思是取消binlog_server_ip参数设置,重启obproxy进程后, obproxy告警就没有了?

是的,重启进程前还调整了一下ODP内存到8G,但是我们发现调整完内存参数后ODP进程还是以2G运行的,kill进程重启后发现ODP进程不是以2G运行的,目前也没有报错