我不在的大半年，大数据服务基本没问题，只过来维护过一两次
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多个服务，只恢复了大半。恢复服务管理，是需要重启服务的，很多服务并不是我写的，也不是我部署的，我不熟悉，万一起不来，影响了业务，就会造成不必要的麻烦。但服务脱离管理，万一哪天挂了，又不知道，也会给排查问题造成麻烦。