大型多租戶 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

嘿 @Greg_John 隨著你的平台成長，僅通過查看日誌就變得更難理解正在發生的事情。這就是為什麼擁有良好的可觀測性如此重要。

典型的生產環境設置包括：
集中式日誌記錄
指標收集
警報
追蹤（如需要）

最有用的監控項目包括：
• tenant_id
• workflow_id
• 執行時間
• 錯誤率
• 隊列深度
• 外部 API 響應時間

將 tenant_id 和 workflow_id 添加到你的日誌和指標中，可以大大簡化為特定客戶或工作流程查找和排除故障的過程。

為以下情況設置警報也是個不錯的主意：
高錯誤率
隊列積壓
工作者故障
外部 API 響應緩慢
流量意外激增

需要避免的一個錯誤是只依賴應用程序日誌或只監控你的基礎設施。你需要同時了解你的工作流程和運行它們的系統。

簡言之，集中你的日誌和指標、正確地標記它們，以及設置儀表板和警報，將幫助你及早發現問題，讓你的平台在成長過程中保持平穩運行。

3

嗨 @Greg_John
n8n 附帶自己的 Prometheus 端點，所以收集層是配置更改，而不是你需要構建的東西。在主節點和工作節點上設置以下內容：

N8N_METRICS=true
N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL=true
N8N_METRICS_INCLUDE_NODE_TYPE_LABEL=true
N8N_METRICS_INCLUDE_API_ENDPOINTS=true
N8N_METRICS_INCLUDE_QUEUE_METRICS=true

隊列深度來自 n8n_scaling_mode_queue_jobs_waiting 和 n8n_scaling_mode_queue_jobs_active。n8n 從 Bull 讀取這些指標，並僅在主節點上公開它們，因此請將抓取作業指向主節點以獲取隊列狀態，指向工作節點以獲取執行和節點計時。工作流 ID 是 n8n 發出的最細粒度標籤，沒有租戶維度，因此在 Prometheus 重新標籤或錄製規則中進行工作流到租戶的聯接，並在該時間序列上構建租戶視圖。將 /metrics 保持在內部網絡上，它公開有關實例的操作詳細信息。

4

謝謝，這真的很有幫助。我喜歡關於用 tenant_id 和 workflow_id 標記所有內容的觀點——這樣在多租戶設置中會讓故障排除變得容易得多。我也同意監控工作流程與監控基礎設施一樣重要。感謝你分享這些。

5

感謝你的見解！這是一個很有用的觀點，給了我一些改進設置的想法。我會研究那個方法，看看它如何適用於我的架構。

6

這個主題的大部分內容都是通用的可觀測性建議。n8n 特定的部分才是你五個問題的實際答案所在，所以：

隊列深度和每個租戶的負載已經公開——你不必自己構建。 n8n 附帶一個預設關閉的 Prometheus 端點：N8N_METRICS=true 在主服務上提供 /metrics。與你的情況相關的標誌是 N8N_METRICS_INCLUDE_QUEUE_METRICS（那就是你的 queue_depth）、N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL 和 N8N_METRICS_INCLUDE_NODE_TYPE_LABEL（按工作流程和按節點類型的數列，這樣「哪個租戶產生最多負載」和「哪個外部 API 很慢」就變成一個 PromQL 查詢而不是一個日誌記錄項目）。將其抓取到你已經運行的任何東西中。如果你有很多工作流程，要注意基數——workflow-id 標籤是讓它有用的東西，也是讓它很昂貴的東西。

你的 error_rate 指標會騙你，這是在多租戶規模上會咬你的指標。 n8n 執行在很多情況下都以 success 狀態完成，其中實際上什麼都沒發生：一個返回零項的節點只是將零項傳遞下游，它後面的所有內容都無聲地空操作；一個 IF 沒有匹配的分支；一個 Split In Batches 的 done 輸出沒有人接線。執行是綠色的，錯誤率保持平坦，租戶的數據根本沒有移動。所以不要只監控錯誤——對結果進行斷言。在每個租戶工作流程的末尾發出一個項目計數，並在 processed == 0 時發出警報，當零不是合法結果時。無聲成功是在到達你的儀表板之前到達你的客戶的失敗模式。

「在客戶注意到之前檢測問題」需要死人開關，而不是警報。 Error Trigger / Error Workflow 是正確的按租戶警報鉤子——按工作流程設置它，並在有效負載中放入足夠的操作內容（$execution.id、工作流程名稱、失敗的節點和最後一個節點的數據；一個只是說「工作流程失敗」的警報每次都會花費你一個除錯課程）。但請注意它在結構上無法做什麼：Error Trigger 永遠不會針對從未啟動的執行而觸發。 一個卡住的計劃觸發器、一個卡住的工作人員、一個某人停用的工作流程——它們都產生無聲，無聲看起來完全像「一切都很好」。修復是反轉的：讓每個租戶工作流程在完成時向看門狗發送 ping，並在 ping 缺失時發出警報。那一個檢查捕獲了日誌在構造上無法看到的整個失敗類別。

你的瓶頸可能是 execution_entity。 在多租戶卷下，執行數據表是使 Postgres 變慢的原因，它會悄悄地增長。EXECUTIONS_DATA_PRUNE=true 配合真正的 EXECUTIONS_DATA_MAX_AGE 和 EXECUTIONS_DATA_PRUNE_MAX_COUNT，對於高卷租戶，考慮 EXECUTIONS_DATA_SAVE_ON_SUCCESS=none——為你永遠不會打開的數據保留每次運行的完整成功有效負載是一大成本。在優化查詢之前進行修剪；很多「n8n 很慢」實際上是這個。

既然你是多租戶，值得早點決定的一件事是：該執行表保存你租戶的實際有效負載。如果其中任何一個在歐盟，執行數據庫是一個處理位置，保留那裡是一個合規問題，而不僅僅是磁盤問題。現在設置政策便宜得多，而不是稍後解釋它。