我需要開始更好地監控工作流程。
你們是怎麼做的？
@patriciaLee 大多數人忽略的原生解決方案是錯誤工作流程，在設定中全域設定一個，它會在任何執行失敗時觸發，這樣你可以將錯誤推送到 slack/email/任何地方，無需輪詢。若要瀏覽/稽核，則有具備狀態篩選器的執行檢視。如果你是自託管的，設定 N8N_METRICS=true 來公開一個 prometheus /metrics 端點，你可以將其抓取到 grafana 建立儀表板和警示。錯誤工作流程 + 指標涵蓋了大多數生產環境設定。
我評估兩個類別。第一個類別是執行健康狀況。我想知道執行是否已開始、完成或遇到錯誤。另一個類別是業務成果。我必須確定執行是否完成了應該完成的任務。這個類別更難評估。例如，如果執行導致篩選器跳過所有記錄，那麼執行會成功，但卻完全無用。
如果工作流程足夠重要，我會記錄更多詳情，包括處理的記錄數量、工作流程的最終狀態、工作流程失敗的原因、工作流程的擁有者以及建議的後續步驟。
除了錯誤外，我還監控一些其他症狀。例如，如果工作流程未成功完成、處理的記錄數量降至 0，或重試嘗試次數增加，我就會發出警報。我始終努力使警報可據以採取行動。
@patriciaLee achamm 涵蓋了核心部分（Error Workflow + Executions view + Prometheus/Grafana）——那是正確的基礎。我還想補充兩件事，以抓住那些遺漏的部分：
-
讓 Error Workflow 真正可操作。一個光禿禿的「workflow 失敗」警報還不夠。在你的全局 Error Workflow 中，推送一條包含 workflow 名稱、execution URL、失敗節點和錯誤訊息的訊息——這樣就能把 20 分鐘的搜尋變成一鍵跳轉到有問題的執行。同時設定 EXECUTIONS_DATA_SAVE_ON_ERROR=all（並用 data-prune 設定來清除成功的執行），這樣你就能保留失敗的 execution 用於除錯，而不會讓資料庫爆炸。
-
留意「靜默失敗」——真正的盲點。Error Workflow + metrics 只在 workflow 執行並拋出錯誤時觸發。它們「不會」捕捉到一個 workflow 靜默停止執行的情況——一個觸發器已死、一個 webhook 被註銷了、一個 cron 悄悄停止了。這是真正傷害的失敗，因為你幾天後才從客戶那裡發現。解決方案是死人開關（dead-man’s switch）：一個 Schedule 觸發器每隔幾分鐘向心跳服務（Healthchecks、Better Stack 或自主託管的 Uptime Kuma）發送 ping。如果 ping 停止到達，它就會提醒你——這樣你就能捕捉到「它根本停止執行了」，而不只是「它執行了但出錯了」。
如果你是自主託管，我還建議在 n8n 實例/容器本身上放一個基本的正常運行時間監控器，這樣你就知道整個東西是否宕機，還是只是一個 workflow 有問題。
我會運行的分層設定是：帶有豐富上下文的 Error Workflow 用於執行時失敗 → Prometheus/Grafana 用於聚合健康狀況 → 心跳/死人開關用於靜默停止 → 實例上的正常運行時間監控器。大多數人設定前兩個；心跳是幾乎每個人都忘記的，直到它咬他們一口。
@ShawnWilliams 關於執行完整性與業務成果的區分提出了很好的觀點。來自第二類的一個例子可能會有所幫助：我構建了一個日常工作流程，它不是監控錯誤，而是監控內容機會，它搜索論壇帖子並透過 LLM 評估它們是否與我相關，然後透過郵件發送摘要。
重點是：「監控」不一定只意味著錯誤。你可以使用相同的錯誤工作流程機制來識別正面的觸發因素，無論是新的線索、內容，或者你可以回答的未解決的問題。技術基礎（achamms Setup）保持不變，只有觸發警報的條件從「發生錯誤」改變為「檢測到有趣的事件」。
@patriciaLee 和其他人已經涵蓋了核心部分（錯誤工作流程、執行檢視、Prometheus/Grafana，以及執行健康狀態與業務結果之間的區別）。我想補充另一層在生產環境中曾給我帶來困擾的東西：無聲失敗。
錯誤工作流程和指標只有在某些東西確實執行並拋出錯誤時才有幫助。它們無法捕捉觸發器停止觸發、webhook 訂閱悄悄過期（Gmail 監看是一個經典例子），或 cron 工作從未執行的情況。什麼都沒有執行，所以沒有任何東西被觀察到。根據我的經驗，這些往往是最令人痛苦的失敗，因為你是從客戶那裡而不是從監控中發現它們的。
我採用的方法是看門狗機制：一個排定的工作流程向心跳服務發送 ping（Healthchecks.io、Better Stack 或自主託管的 Uptime Kuma）。如果心跳停止到達，那就是告警。它透過偵測「它完全停止執行」而不僅僅是「它執行了但失敗了」來補充錯誤工作流程。
我也很欣賞 Shawn 關於業務結果的觀點。對於重要的工作流程，我會追蹤記錄已處理、重試次數、預期最小量和所有權等內容。一個成功處理零筆記錄的工作流程在技術上可能是健康的，但在操作上毫無用處，所以這些指標也應該有告警。
對我來說有效的分層模型是：
- 錯誤工作流程 → 豐富的背景資訊（工作流程、節點、執行 URL、錯誤詳細資訊）
- Prometheus/Grafana → 彙整指標和趨勢
- 業務指標 → 已處理的記錄、重試次數、預期的結果
- 心跳/看門狗機制 → 無聲失敗
- 正常運作時間監控 → 執行個體/容器健康狀態
大多數人實現前兩層。心跳和業務成果層是往往能讓你在日後避免不愉快意外的層。
Shawn 的分類方式是我會使用的：執行健康狀態 vs 業務成果。
對於客戶端工作流程，我會在警報中添加一份小的執行收據：預期時間窗口、接觸的記錄、使用的帳戶/憑證、嘗試的下游操作、最終記錄/訊息 ID，以及誰負責下一步。綠色執行狀態的用處不如證明實際變更的內容。
這個討論串已經有很好的涵蓋重要的拆分部分，執行健康狀況與結果是否實際發生，加上永遠不會觸發的執行的心跳想法，所以我只會添加仍然漏過所有這些的一個故障。即使有記錄計數檢查和備用開關到位，讓人們陷阱的情況是執行完成、處理其通常的行數、未拋出任何內容，但仍然是錯誤的，因為認證悄悄過期或來源變得陳舊，API 回傳了有效但空白或佔位符回應。計數看起來正常，狀態是綠色，沒有任何東西出錯，所以上面的層級都不會標記它。
標準錯誤觸發器對此視而不見的原因是沒有錯誤。令牌沒有大聲失敗，它以乾淨的 200 回傳，內部沒有有用的東西，工作流程愉快地將其對應轉發。記錄計數警報也會錯過它，因為計數可能是正常的，而內容是陳舊或空白的。
不費力氣就能捕獲它的是檢查內容，不只是存在。在任何對認證敏感的呼叫之後，對僅在呼叫真正奏效時才會出現的欄位進行斷言，而不是只檢查回應是否為非空白，並添加新鮮度檢查，最新記錄是否真的是最近的還是我看著昨天的數據被回傳給我。特別是在認證角度，將來自通常繁忙來源的意外空結果視為失敗條件而不是安靜的成功會有所幫助。
將整個討論串聯繫在一起的心態：綠色執行和正常的行計數仍然不是數據真實的證明，只是有東西回傳了。值得添加的檢查是結果是否是新鮮和正確的，而不只是存在。你們都對陳舊但綠色的情況做了什麼，或者它還沒有咬到你？
這個討論串把核心層面涵蓋得很好：帶有上下文的錯誤工作流、Prometheus/Grafana、用於偵測無聲故障的心跳監測，以及某人提出的綠燈但資料陳舊的情況。有一個差距我想補充，尤其是如果你沒有單獨運行 n8n 的話：
到目前為止提到的一切都是 n8n 原生的。錯誤工作流、N8N_METRICS、執行檢視。如果 n8n 是你唯一的自動化平台，這是正確的做法。但很多團隊並不是純 n8n。他們有 Make 場景、幾個 Zapier zaps、一個 cron 工作、可能還有一兩個指令碼，都在做真實的生產工作。每一個都有自己的儀表板，所以「一切是否健康」意味著要檢查三、四個不同的地方，而人們在這裡描述的心跳模式必須為每個工具單獨重建。
對我有效的模式：把「它有沒有執行、有沒有成功、有沒有失敗」當作一個簡單的事件，從自動化所在的任何地方發送。一個來自 n8n 的成功和錯誤路徑的 HTTP 呼叫，來自 Make webhook 或 Zapier webhook 或指令碼中 try/except 的做法也一樣，全部都落在一個不在乎是哪個工具發送的地方。和上面一樣的心跳概念，只是不受限於一個平台。
免責聲明，因為我應該直說：在遇到這個同樣的「四個儀表板、沒有單一檢視」問題後，我構建了一個正是為此設計的工具（FlowPulse）。不是想在一個好討論串中間硬生生推銷，只是標記它在那裡，以防跨平台的部分對任何人有幫助。如果你更傾向 DIY 版本，我也很樂意討論。