在大規模多租戶 n8n 平台中實施可觀測性的方法

問題
1

嗨各位
我正在擴展一個多租戶 n8n 平台，開始意識到基本日誌已經不夠用了。
負載均衡器
↓
多個 n8n 工作程序
↓
PostgreSQL + Redis + 外部 API
隨著租戶和工作流數量的增加，我發現很難回答以下問題：
• 哪個租戶產生的負載最大？
• 為什麼特定的工作流失敗了？
• 系統中的瓶頸在哪裡？
• 哪些外部 API 導致了延遲？
• 我如何在客戶注意到問題之前檢測到它們？
我正在考慮添加：
• 集中式日誌記錄
• 指標收集
• 分佈式追蹤
• 按租戶的儀表板
• 告警和異常檢測
tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency

描述問題/錯誤/問題

你在使用什麼可觀測性堆棧？哪些指標最有價值？

錯誤消息是什麼（如果有的話）？

請分享你的工作流

(選擇畫布上的節點，並使用鍵盤快捷鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 來複製和粘貼工作流。)

分享最後一個節點返回的輸出

關於你的 n8n 設置的信息

  • n8n 版本：
  • 數據庫（默認：SQLite）：
  • n8n EXECUTIONS_PROCESS 設置（默認：own、main）：
  • 運行 n8n 的方式（Docker、npm、n8n cloud、桌面應用）：
  • 操作系統：
2

你好 @Selena_Gloria 一旦你開始擴展到更多租戶和工作流程，僅靠查看日誌就變得很難理解發生了什麼。

常見的生產環境設置包括：
集中式日誌
指標收集
警報
追蹤（必要時）

我發現最有用的指標是：
• tenant_id
• workflow_id
• 執行時間
• 錯誤率
• 隊列深度
• 外部 API 響應時間

使用 tenant_id 標記日誌和指標，可以更輕鬆地排查特定客戶的問題，而不會影響其他人。

我也建議設置警報，用於高錯誤率、隊列積壓增長、工作進程故障、API 速度緩慢和意外流量激增等情況。這樣一來，你可以在用戶開始報告問題之前就捕捉到問題。

要避免的一個常見錯誤是僅依賴應用程序日誌或僅監控基礎設施。同時可視化基礎設施和工作流程，可以讓你更好地了解發生了什麼。

總的來說，集中式日誌記錄、指標、儀表板和警報的組合使得隨著平臺增長而保持其健康狀態變得容易得多。

3

很好的觀點，我特別同意使用 tenant_id 和 workflow_id 進行標記可以讓故障排除變得簡單得多。感謝分享！

4

我會新增一個不完全屬於基礎設施的指標：每次執行的動作收據。

Tenant、workflow、錯誤率和延遲會告訴你問題在哪裡。收據會告訴客戶發生了什麼：預期執行、使用的憑證/帳戶、接觸的記錄、呼叫的外部 API、最終物件/訊息 ID，以及暫停或重試狀態。