事後分析: Bad Gateway

概要#

2024-01-11，Logto 服務出現中斷，並出現大量 502 Bad Gateway 錯誤。

• 開始時間： 大約 2024-01-11 15:28 UTC
• 解決時間： 大約 2024-01-12 00:49 UTC
• 持續時間： 大約 9 小時
• 受影響的服務： Logto 認證服務，Logto 雲服務
• 影響等級： 嚴重
• 根本原因： logto.app 域名過期，續約未能成功完成。

時間線#

• 2024-01-11 15:28 UTC 使用者報告在訪問 Logto 認證服務時遇到 502 Bad Gateway 錯誤。
• 2024-01-11 15:42 UTC 更多使用者報告同樣的問題。
• 2024-01-11 15:50 UTC 我們的團隊成員開始調查問題，並打電話給其他團隊成員。由於對某些團隊成員來說已經是深夜，普通電話不足以叫醒他們。
• 2024-01-12 23:54 UTC 我們發現雲服務正在發送請求給認證服務，但請求失敗並顯示 ERR_TLS_CERT_ALTNAME_INVALID 錯誤。
• 2024-01-12 00:36 UTC 我們清除了 DNS 快取看看是否有幫助。事與願違。
• 2024-01-12 00:38 UTC 我們重新簽發了 TLS 憑證看看是否有幫助。事與願違。
• 2024-01-12 00:45 UTC 我們注意到 logto.app 域名可能已經過期。我們檢查了域名註冊商後發現它沒有成功續約並且域名已過期。
• 2024-01-12 00:49 UTC 域名續約完成。服務逐漸恢復正常。

事件分析#

發生了什麼事？#

我們的域名通常通過域名註冊商自動續約。然而，在這個案例中，因為可能的配置錯誤導致續約過程失敗。因此，logto.app 域名過期，並且 DNS 記錄被更新指向註冊商的停泊頁。

截至目前，認證服務保持運行，但大多數請求無法到達它。例外的是 Logto 管理員租戶，它綁定到 auth.logto.io 域名並不受過期影響。

除了認證服務，我們還有一個雲服務，負責協調 Logto 租戶並提供 Logto 雲控制台（前端應用）。

當使用者操作雲控制台時，應用並不直接調用認證服務；而是向雲服務發出所有管理操作的請求。

為了與 Logto 管理 API 保持一致，我們設計了一個「管理 API 代理」端點，將請求委託給認證服務。整個流程如下所示：

由於 *.logto.app 域名有憑證不匹配問題，雲服務 (Node.js) 拒絕請求並拋出錯誤。

通常，請求錯誤會被捕捉以防止整個服務崩潰。然而，因為錯誤是從代理模組傳播出來的，現有的錯誤處理邏輯無法捕捉到它，導致服務崩潰。

儘管每個 Logto 服務至少有三個副本，但由於錯誤發生在幾乎每個來自雲控制台的請求，所有副本都容易崩潰。自動恢復機制啓動需要時間，導致服務暫時不可用。

這就是為什麼使用者會看到 502 Bad Gateway 錯誤（所有副本崩潰）。當雲服務恢復，新的和重試的雲控制台請求進來，崩潰循環繼續。

當雲服務宕機，它也會影響認證服務的某些端點，主要是 /api/.well-known/sign-in-exp。這個端點用於獲取登入體驗配置，包括需要從雲服務獲取的連接器信息。

解決方案#

• 手動續約域名。

教訓#

• 始終設置域名到期監控或購買較長期限。
• 注意時區差異可能會導致事件響應延遲。
• 確保監控涵蓋所有域名。
• 與可以拋出異常的模組互動時要謹慎，確保能夠正確捕捉和處理錯誤。

糾正和預防措施#

• ✅ 增加每月的域名到期監控，無論是否啟用自動續約。
• ✅ 增加對 logto.app 的監控。
• ✅ 更新雲服務的錯誤處理邏輯，以正確捕捉和處理代理錯誤。
• ✅ 在有全時區覆蓋的 SRE 團隊之前，實施更強的警報，讓團隊在事件發生時被喚醒。