原来没有什么事变，删了服务器上一个文件夹，导致忙了快两个星期 ...

我不在的大半年，大数据服务根本没问题，只过来维护过一两次

2024年大半年，大数据服务都比较稳定，我也只过来维护过一两次。8月份我又过来了，交代完离职同事的工作，原来没什么事变。
StatHub页面服务状态不刷新

StatHub是一个集群管理/应用编排/进程保卫工具，可以用来高效的管理服务集群。具有节点进程管理和应用管理功能。
StatHub包括master和agent两个部分：
stat-server，即master，提供服务编排界面。
stat-agent，运行在工作节点，保卫工作进程。
StatHub源代码地址：https://github.com/rm-vrf/stat
在这工作的另一家公司的大数据研发说，StatHub页面服务状态不刷新。我说你的服务是正常的吗？他说是正常的。我说不消管它，等哪天有空我再看看。
完蛋了，删了不该删的文件夹

闲下来之后，我就尝试办理StatHub的问题。其实以前是有办理方案的，就是查找各服务器节点上的.stat_agent文件夹中的app和proc文件夹中的巨细为0的文件并删除，就可以了。
但是我一时半会没想起来这个办理方案，于是想着通过重启办理，我重启了不正常节点的stat-agent，又多次重启了stat-server，都不行。
我想，是不是什么缓存造成的，.stat_server这个文件夹最开始部署StatHub的时间肯定是不存在的，它应该是自动天生的，我先停了stat-server，再把它删了，然后重启试试。于是，我就这样删除了.stat-server，重启StatHub成功，.stat-server文件夹又自动重新天生了。但是很快我就发现了一个严重问题，StatHub页面上的那100多个服务全没了！页面空了！
跑路吧，要失业了，卧槽！
虽然100多个服务离开管理了，但服务应该都照旧在正常运行的，只要服务不挂，一时半会是没有问题的。
怎么办？恢复数据？谁人服务器很重要，上面跑了不少重要的服务，万一搞坏了，就真的完了。
找到方法，逐步恢复StatHub页面的服务管理

幸亏，我发现stat-agent所在的20多台服务器上的.stat_agent文件夹中的proc文件夹中的各服务的进程信息都在(另一个重要的app文件夹在stat-server重启后被自动清空了)，那里面有服务的名称和启动命令，可以用来在StatHub页面中重新录入服务信息，重要是启动参数，由于有些java和spark服务的启动参数比较复杂。于是我把20多台服务器上的proc文件夹中的服务名称和启动命令做了备份。然后，先恢复了2、3个服务的管理，但是服务状态刷新不出来，也无法正常停止和启动服务，我只能到服务所在呆板上，敲Linux命令查看服务运行状态。
修改StatHub源码，办理服务状态不正常的问题

打开StatHub的源码，发现遍历各节点信息时，加了try catch，但只catch了ResourceAccessException异常，其它异常会导致for循环挂了，所有节点和进程信息都获取失败了。以是我修改了代码，加了一个catch (Exception e)，并打印日记，提交，重新发布启动stat-server，查看stat-server日记，确定了异常节点，把异常节点服务器上的巨细为0的文件删除，服务状态就正常了。
又出现新环境，StatHub页面节点列表中162这台呆板的节点信息不见了

由于某原因重启162节点上的stat-agent后，StatHub页面节点列表中162这台呆板的节点信息不见了。最后发现是服务器出了问题，mount命令，卡一会，一堆挂载，不知为何。df -hl命令也会卡一会才出来信息，这个问题导致stat-agent遍历磁盘信息时，卡住了。
ClickHouse也出问题了，一个服务插入数据时频繁报Too many parts异常

之前办理过一次，思绪就是增加每次批量插入的数据量，以镌汰插入次数。当时服务暂时稳定了，我以为办理了，其实并没有办理。服务消费的kafka的topic共有78个分区，rdd.foreachPartition的并行度是78，太大了，怎么镌汰并行度呢？当时我并不知道怎么办理。这次，我把代码改成了rdd.coalesce(1).foreachPartition，coalesce的作用是镌汰分区，这样就可以镌汰数据插入ClickHouse的并行度，我把并行度设置为1。按理说问题应该办理了，但照旧报Too many parts异常，数据插入成功几次失败几次。
重启ClickHouse

没有什么是重启办理不了的，如果不行，就再重启一次。
于是我就决定重启4个节点的ClickHouse服务。
重启第3个节点时，服务器突然失联，我就重启个ClickHouse就把服务器搞挂了？幸亏有惊无险，过了一会，又连上了。
重启第4个节点时，发现起不来了啊！查看监控页面，发现所有写入ClickHouse的服务，都报红了！我又重启了依赖的zookeeper服务，又多次重启了ClickHouse，都不行。
部分报错信息：DB::Exception: The local set of parts of table 'xxx' doesn't look like the set of parts in ZooKeeper: xxx billion rows of xxx billion total rows in filesystem are suspicious. ... Cannot attach table 'xxx' from metadata file /var/lib/clickhouse/metadata/xxx/xxx.sql from query ATTACH TABLE ...
百度搜到一个类似问题https://support.huaweicloud.com/intl/zh-cn/trouble-mrs/mrs_03_0281.html，步骤太多，没太看明确，不敢操作。
办理问题，重启ClickHouse成功

我注意到报错信息中的metadata file，心生一计，把错误日记中提到的那两个.sql文件改名成xxx.sql.bak备份一下，然后重启ClickHouse，成功了！然后把那两个文件又改名回来。然后观察那些写入ClickHouse的服务，全都正常了，部分服务失败了没有自动重启就手动重启了一下。然后发现Too many parts的问题也办理了。
162服务器也正常了

另一家公司的大数据研发，经过准备工作，重启了这台呆板办理了问题。
StatHub页面的服务管理恢复了大半

经过这几天的手动录入，StatHub页面的服务管理恢复了大半。
我把stat-server所在服务器上的.stat_server文件夹中的app和choreo文件夹做了备份。以前没想到这个文件夹如此重要，也没想过会被删，从来没有备份过。
剩下的服务，逐步录入，或者等服务出问题需要重启的时间再录入也行。
这一个多星期的工作是无中生有吗？

也不全是

• StatHub页面服务状态不正常，照旧需要处理的。但是我犯了错误，把不该删的文件夹删除了。经过这次教训，我做了备份。
  
• ClickHouse出问题是迟早的，由于之前写的spark服务，始终没有优化好，数据插入并行度太大。
  
• 162服务器早就有问题了，但只要不重启stat-agent就没事。
  

问题处理的差不多了

还有一个问题，StatHub页面的100多个服务，只恢复了大半。恢复服务管理，是需要重启服务的，许多服务并不是我写的，也不是我部署的，我不熟悉，万一起不来，影响了业务，就会造成不须要的麻烦。但服务离开管理，万一哪天挂了，又不知道，也会给排查问题造成麻烦。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。