記一次confluence故障的RCA

• Confluence故障RCA(Root Cause Analysis)
• • 問題
  • 問題原因（Root Cause）
  • • 故障觸發原因
    • 核實8091端口對應的服務進程
    • • 關于Synchrony
    • 核實Synchrony服務進程的啟動方式
    • 啟動Synchrony服務并觀察Confluence是否連上
    • Q&A

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

總結

以上是生活随笔為你收集整理的记一次confluence故障的RCA的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。