【 使用环境 】测试环境
【 OB or 其他组件 】OB和OCP
【 使用版本 】OB 4.3.5.2，OCP 4.3.6
【问题描述】oceanbase集群新增zone总卡在Restart observer process，提示observer which occupied port:2882 is not found in host 1000006，查看observer进程已经有了，但是2882端口没起来，任务失败后重试就会提示OBServer 1,000,006 has not exited
围观一下
OCP的完整任务日志 右上角 下载发下吧
应该是observer 没有启动成功，刚开始新增zone时的observer.log 有多保留几个吗？
如果有麻烦发下 刚开始时间点的2～3个observer.log
如果没有保留，麻烦回滚任务 重新增加zone，保留开始时间点的2～3个observer.log 发下
放了一中午以后再重试就好了，现在已经加上了，这是这次新增zone里的两台机器上的observer.log，我这两台是虚拟机，Ubuntu上装的kvm，有没有可能跟虚拟机性能有关系呢？
observer236.zip (21.2 MB)
observer237.zip (1.2 MB)
机器配置怎样的？正常observer从初始化到启动 流程 很快的
可以跑个巡检看下
obdiag check run
实体机是16核cpu、64G内存，运行的虚拟机是16核cpu、32G内存
那我试一下
应该还有个巡检报告文件 .table
好像没有找到这个文件 
刚给又重新跑了一遍，日志还是跑到这就卡住了，就没再跑下去了
我找obdiag的老师看下
table.macroblock_utilization_rate_table 这个巡检项里的sql未能返回导致的问题。此时的sql可能返回较慢。
obdiag的巡检项是可插拔的，可以通过删除这个巡检项来实现绕过
rm -rf ~/.obdiag/check/tasks/observer/table/macroblock_utilization_rate_table.py
这个是删除当前用户下的巡检项，不会影响到原包的内容。
后续需要恢复的话执行如下指令即可，巡检文件在 /opt/oceanbase-diagnostic-tool/plugins/ 里有备份
cp -rf /opt/oceanbase-diagnostic-tool/plugins/* ~/.obdiag/
如果后续再出现这个情况，麻烦保留下的observer.log，observer开始启动时间的2～3个observer.log
obdiag的问题后续会修复
