Confluence故障RCA(Root Cause Analysis)

本文记录我在去年给客户做的一次confluence故障原因排查，也希望借此机会与使用confluence的朋友交流一下。
本文内容均已脱敏。

问题

用户的监控系统报警confluence无法访问，主页无法打开。排查过程中我们工程师重启confluence（stop-confluence.sh/start-confluence.sh）并发现进程和端口并未能恢复正常。

问题原因（Root Cause）

故障触发原因

检查日志文件catalina.out，在07-Jul-2020 15:10:49.691处开始可见内存溢出（OOM），WebSocket Connection Manager因此停止，同时在下方日志出现“Exception in thread “synchronyProxyFilter-74905” java.lang.OutOfMemoryError: Java heap space”等多项Exception，由此判断提供8091端口的WebSocket服务的组件出现OOM。
在这里插入图片描述

核实8091端口对应的服务进程

根据上面得出的结果，我们判断需要恢复服务，就需要使8091端口的WebSocket重新工作，因此，需要核实该端口是由哪个应用提供服务。
通过命令netstat -tunlp | grep 8091可以获取端口的对应进程的PID，结果如下：
在这里插入图片描述
根据PID，可以通过命令ps -ed | grep java，我们可以得知以下四个信息：
1） PID 17511的进程为Synchrony
2） PID 17511的PPID（父进程）为16748
3） PPID 16748的进程为Confluence主程序
4） Synchrony进程的JVM配置了最大内存为1GB，Confluence的主进程JVM为8GB。
在这里插入图片描述

关于Synchrony

Synchrony是给Confluence提供协同编辑的引擎。它是一种允许实时同步任意数据模型的服务。
1）Synchrony的工作方式
在这里插入图片描述

Confluence使用appId和appSecret与Synchrony服务通信。
JSON Web Token（JWT）提供连接的详细信息给客户端。
在初始化Confluence编辑器时，会将Synchrony Javascript加载到浏览器中。
Synchrony通过JWT和正在编辑页面的contentId打开一个WebSocket会话。
WebSocket连接允许多个客户端保持同步。

所以，页面的内容数据将存储在Synchrony服务上，该服务将充当页面内容的真实来源。

核实Synchrony服务进程的启动方式

为了使Synchrony再次运作，必须找到对应的启动脚本。我们使用以下命令查找：
使用命令grep -R Synchrony ./*在/data/atlassian/confluence/bin内查找对应的启动文件。
由此落实几点：
1）Synchrony由./synchrony/start-synchrony.sh启动，由./synchrony/stop-synchrony.sh关闭。
2）start-confluence.sh里面没有发现Synchrony的启动脚本。
3）catalina.sh里面没有发现Synchrony的启动脚本。
4）/etc/init.d/内有与/synchrony/start-synchrony.sh关联的启动脚本。
在这里插入图片描述

启动Synchrony服务并观察Confluence是否连上

1）未重启Synchrony之前，我们可以看到日志上大量connect failed:
在这里插入图片描述
2）重启Synchrony之后，我们可以看到日志上大量的successfully connected:

3）故障分析
总结，由于Synchrony的OOM，导致confluence前端出现访问问题。
同时也是由于Synchrony的启动脚本与confluence的启动脚本分离，导致debug工作前30分钟被在集中研究confluence的启动问题而忽略了问题的根本原因是出在8091端口的WebSocket上。

Q&A

Q: 为什么debug期间前端会出现提示页面：BootstrapException: Unable to bootstrap application: failed to find config at: /data/atlassian/application-data/confluence/confluence.cfg.xml ?
A: 这个问题是由于debug过程中使用错误的启动脚本启动过confluence，导致confluence.cfg.xml用户权限变成root，之后再使用正确的脚本重启confluence时，由于用户组权限低于root，所以会导致无法覆盖文件的问题。
例如/data/atlassian/confluence/bin/startup.sh这个启动脚本，里面没有调用用户环境变量设置文件user.sh，也没有设置CONF_USER，从而导致问题发生，但这个并非本此故障的root cause。
正确的执行启动confluence方式是：
systemctl start confluence
或/etc/init.d/confluence start
或cd /data/atlassian/confluence/bin/再执行start-confluence.sh

Q: 目前单一节点故障导致业务中断的问题，是否有高可用或集群部署的可行性？
A: 参考官方资料：https://confluence.atlassian.com/doc/set-up-a-synchrony-cluster-for-confluence-data-center-958779073.html