背景：
先介绍下我们ocp的情况，前期使用a,b,c三个节点搭建的1-1-1架构的ocp，后期因监控数据量太大，需要更大的存储空间原机器没有多余的磁盘。
就找了d,e,f三台存储容量更大的服务器，数据盘划分了15T，文件系统格式化为了ext4，预留了5T，我们把ocp从abc三台机器迁移到了def，随着监控数据的增长，发现15T的数据盘使用水位也很高，我们临时先把保留周期调小，尝试把预留的空间分配给数据目录。
发现ext4的文件格式不支持16T以上的空间，需要重新格式磁盘格式为xfs。
因为无法直接在线修改数据文件格式，就找了一台同规格机器，把meta库数据迁移过去，把d,e,f三台ocp机器上的metadb的docker释放掉，重新格式化。
问题：
因为替换机器只有一台，而且为了稳妥起见，我先尝试替换了一台ocp机器。因为数据量比较大，数据迁出迁入，每个节点大概要耗费3天，中间有些小问题，在这篇分享里暂且不提。因为ocp也有f5负载，所以替换过程中和替换后，ocp没有影响使用，但是检查告警发现有agent告警，因为agent在metadb的docker里替换回来之后agent没有安装，前台点重装agent直接报404报错了。
我检查报错是有访问软件包的报错，我前台点软件包的页面，也有404的报错。申请了工单老师协助排查。
f12调试
点进去
查看信息如下
这里基本可以确定是有脏数据导致的，这些脏数据都要清掉，不然JPA在找关联对象找不到，就会报404
因为这些机器查不到ip了根据集群id可以确认是一开始的a,b,c老的ocp机器的残留，因为我们ocp最初版本较旧，metadb和proxy在单独的docker，所以一直替换都是后台操作的，ocp的机器信息好多都是黑屏后台去清理修改的，所以这里可能没有清理到，导致残留了，手工清理到这些脏数据就正常了，重装agent后正常。
结论：
该问题比较特殊，可能参考价值不是特别大，仅为了给大家一个参考，也是我自己记录下。
行之所向，莫问远方。
