那些發送發票、路由潛在客戶或向客戶發送訊息的。他們可以在沒有任何錯誤的情況下停止，而儀表板看起來仍然很好。
上次發生時，誰最先發現它——是你還是客戶？
在我的情況下，我試著不讓客戶成為第一個發現的人 
我在 n8n 中使用中央錯誤處理工作流程，該流程會捕捉失敗的工作流程、分類嚴重程度，並發送包含工作流程和執行詳情的警報。
不過，無聲失敗才是更有趣的問題。
工作流程可以成功執行，但實際的業務結果卻永遠不會發生。
監控這些情況需要採用與單純捕捉執行錯誤不同的方法。
你的客户是单独支付那个警报费用，还是作为构建价格的一部分？
沒有人注意到，這就是我得到的答案。我沒有客戶，所以根本沒有人會注意到，而我發現的這兩個都是在做其他事情時意外發現的。我刪除了一個排程任務，部署後，那個被刪除的任務仍然留在執行中的排程裡，這就是我發現排程已經兩週沒有更新的方式。另一個我是因為截了一張螢幕截圖給某人看時才發現的，我看到一個工具列顯示空白，本應該顯示被拒絕的呼叫。這兩個都沒有被我刻意寫的檢查程序捕捉到。當這是客戶的工作流程時，你有告訴他們它已經停止了，還是默默地修復它什麼都沒說？
我目前將基本的錯誤處理視為建置的一部分。
如果我交付生產工作流，如果沒有適當的錯誤處理和警報，我就不認為它是完整的。
不過，持續的監控和支援是另一回事。
我會將其視為定期託管/支援套件的一部分，而不是初始建置費用。
對於客户端工作流程中的無聲錯誤，你目前用什麼方式捕捉它們，這對你有什麼成本嗎？
在我的情況下也沒人注意到，我只是因為自己去查才發現的。
幾週前我在自己的執行個體上指向了一個唯讀監控器，發現一個工作流程中有28次連續失敗，跨越約24小時，在我查看它三天前就發生了。它們一直正確地標記為錯誤，坐在我自己的執行清單中。n8n完成了它的工作。問題根本不在n8n，而是我們遷移了這些工作流程調用的應用程式，從EC2遷到Vercel，檢查清單上有DNS這一項，但沒有「呼叫它的那個東西」。
@Aghassi關於你的問題，因為這是令人不適的部分：我告訴了他們。不是立即說，我先修復了它，然後說發生了什麼以及它已經壞了多久。我無法回答的是「下次我們如何會知道」，那才是真正讓我失去信任的部分，而不是中斷本身。
@StefanGwiggner你描述的分割也是我最終採用的方式，在建置內部進行錯誤處理，在循環線中進行監控。我發現真正困難的部分是，監控用的循環線必須基於沒有任何事情發生而更新。當它正常工作時，沒有事件可以指向，所以用戶端是在為缺失付費。我發現的唯一答案是定期發送一些東西，說明檢查了什麼以及發現了什麼，即使誠實的答案是什麼都沒有——否則沉默看起來就像服務已停止，而不是問題已停止。
你指向你的實例的唯讀監控器，那是你付費購買的工具，還是你自己開發的？
那實際上是我還在進行中的部分。
我的中央錯誤工作流程可以處理技術執行失敗，但真正的無聲失敗則不同，因為 n8n 可能報告執行成功，但預期的業務結果卻從未發生。
對於這些情況，我認為監控必須與預期結果相關聯，而不僅僅是工作流程狀態。
例如：
發票是否實際建立
潛在客戶是否到達 CRM
客戶訊息是否確實已發送
…
我還沒有一個通用解決方案，因為健康檢查很大程度上取決於工作流程應該完成什麼。
你的客戶中有人今天為該月度託管/支援方案向你付款嗎？大約每月多少錢？
每個工作流程的部分是真實的，檢查必須知道該工作流程應該完成什麼。可以概括的是檢查的形狀，有兩種值得分開的。
第一種捕捉缺失：發票是否被建立，潛在客戶是否到達CRM。你按照時間表查詢目標系統，獨立於執行日誌，並比較著陸的內容與來源提供的內容。這是Aghassi描述的雙邊版本，它阻止了平靜的一天看起來像一個破損的。
第二種捕捉第一種遺漏的情況：發票被建立了，正確數量的行被移動了，其中的值是錯誤的。一個映射漂移了，一個模型被交換了，一個上游欄位改變了含義但不改變形狀。為此，為每個關鍵工作流程選擇一或兩個案例，你提前知道正確的輸出，一份可以手工重新計算的測試發票，一個已知的查詢，並按照時間表通過實時生產工作流程運行完全相同的案例，與真實流量分開。你不是在檢查它是否運行或移動了多少，你是在檢查答案是否仍然與你事先寫下的相符。
第二個也有助於解決Loordhu提出的更新問題。一份月度備註說你的測試發票30次中有30次正確返回，帶著一個本來可能是錯誤的數字，所以它讀起來像是一個運行的檢查，而不是沉默。
還沒有。
我目前正在從為自己、朋友和家人做的項目過渡到與外部客戶合作，所以我還沒有由付費客戶支持的真正月度支持價格。
我才剛開始一個月。
我計劃的模式是一次性實施費用加上定期託管-監控-支持套餐。
不過在我用真正的客戶驗證之前，我寧願不要先報出一個數字 
這個線程中每個人都依賴的用來捕捉明顯故障的層本身可能會無聲地失敗。我查看了 n8n 源代碼以確切了解如何失敗，然後在自己的實例上觀察了每種情況的發生，所以下面的數字來自我自己的執行列表，而不是理論。
三種機制，編輯器中沒有任何地方顯示。
錯誤工作流可以在不活躍的情況下設置為指向它的每個工作流的錯誤工作流。n8n 會保留該設置，下拉菜單仍然顯示名稱，當發生故障時，它會向服務器日誌寫入一行：Calling Error Workflow for "X". Workflow "Y" is not active and cannot be executed。這一行就是整個通知。如果錯誤工作流活躍但其中沒有錯誤觸發節點，情況相同：一行日誌，沒有警報。
崩潰執行是最糟糕的情況，@Daniel_Goh 目前有一個關於這個問題的線程。當進程在執行中期死亡時，沒有運行數據也沒有拋出錯誤，所以在故障時沒有任何觸發。執行在下次啟動時被標記為崩潰，然後錯誤工作流運行。不是在失敗時。而是在下次啟動時。如果容器停止運行六小時，警報就延遲了六小時，如果它從未正確恢復，則根本沒有警報。
關於 @StefanGwiggner 提出的生產工作流沒有適當的錯誤處理就不完整的觀點，我現在會反過來說：錯誤處理是我信任最少的部分，因為它是堆棧中唯一的部分，其故障模式是設計上的沉默。任何監視 n8n 實例的東西都必須在其外部，並通過 API 將其讀回。在實例內部運行的監視器坐在它應該報告的東西的衝擊半徑內。當我作為測試關閉自己的錯誤工作流時，本機跟蹤就是那一行日誌。外部監視器在五分鐘內標記了它。
@Loordhu_Jeyakumar 關於續訂問題，@Adam13y 的答案是正確的，我可以用數字證明它，因為這正是我的報告方式。在過去五天中，它針對我的實例記錄了 1,409 次心跳檢查並打開了六個警報。其中兩個是計劃外的：週日我的實例沉默了兩次，每次都是從錯過的心跳捕捉到的，兩個警報在心跳恢復時自動關閉，一個在 4 分鐘後，一個在 29 分鐘後。原因證明是我自己的筆記本電腦進入睡眠狀態，這主要是關於不應該在哪裡運行 n8n 的教訓。但那是客戶可以續訂的月度額度。不是「這個月沒有事件」，而是 1,409 次檢查，兩次中斷，都被捕捉到，都關閉，這裡是時間戳。
直接回答你的問題，Vladislav：我自己構建的，而不是購買的。當我查看時發現的東西需要在每個你想監視的工作流內安裝一個節點，這會讓監視器回到衝擊半徑內，這意味著你忘記檢測的工作流正好是你什麼都聽不到的。
@StefanGwiggner 對你正在組合的經常性包提出一個反問，因為答案決定了監視層必須是什麼樣子：你計劃自己託管客戶端的實例，還是監視客戶端擁有的實例？監視自己的車隊和監視別人的車隊最終是不同的問題，我很想知道你正在為哪一方構建。
感謝，那個仍然顯示在下拉列表中的非作用中錯誤工作流程確實很討厭。除了你之外，還有其他人在運行你的監視器並為其付費嗎？
沒有。目前只有我，它已經監控我自己的實例大約一週了。這是我出現在像這樣的討論串中的真實原因，我想在進一步開發之前，先了解是否有人願意為此付費，以及他們願意為什麼付費。
出於好奇，你在這個討論串中詢問了每個人的付費情況。你也在這個領域開發什麼東西嗎？
@Vladislav_Vladislav 我自己建造的。它很小：它從實例外部讀取 n8n API，唯讀，並監視失敗的執行、應該發生但沒有發生的執行，以及實例本身變得安靜的情況。要回答你在問 Benzy 之前可能會問我的問題：沒有，目前沒有其他人在運行它，也沒有人為它付費。就是他描述的那個地方。如果你為客戶運行實例並想看看它對其中一個說了什麼，我很樂意把它指向它，DM 我。
@Adam13y @Benzy 關於續訂問題，已知答案的情況是我沒有的部分。我今天發送的一切都是誠實缺失的類型。我自 9 月 12 日以來的實際數字：針對我自己實例的 28,308 次健康檢查，5 次失敗，1 次錯誤警報，同一個子節點故障在 9 月 11 至 18 日之間發生了 36 次，這是真實的，也是我需要修復的。這些數字可能是錯誤的，但沒有一個說單一發票被正確發送。
針對我自己的設置的一件事，符合 Benzy 關於監視器位置的觀點：9 月 25 日它發出了 50 秒的「實例關閉」警報，在同一分鐘內它無法到達自己的郵件提供商。所以較可能的情況是我的監視器失去了網絡，而不是 n8n 宕機。在爆炸範圍之外是對的，但在外面意味著你繼承了自己的第二個爆炸範圍，報告必須說明哪一方眨眼了。
@Benzy 抱歉回覆晚了,我離線了幾天。
目前我傾向於自己託管和管理客戶端實例。每個客戶端可能有一個生產實例,監控、備份和錯誤處理都包含在循環服務中。
對於已經有自己的 n8n 設置的客戶端,我仍然會提供監控,但就像你說的那樣,這會成為一個不同的問題。如果我們託管它,我們幾乎可以監控整個堆棧。在他們自己的基礎架構上,我們顯然取決於他們給予我們的訪問權限。
你的「爆炸半徑之外的監控者」觀點真的給了我很深的印象。我已經在使用內部錯誤處理,但這次討論讓我確信,只依賴於此可能還不夠。
我仍在搞清楚循環套餐到底會是什麼樣子,所以這個帖子對我來說確實非常有用。
謝謝你的提問!
有道理，自己託管它們是比較容易監控的一方。你計劃一開始要啟動多少個客戶端實例？如果在你組裝套件時有幫助的話，我可以免費將我的監控工具指向其中一個，你就能看到它會告訴你什麼。
@Benzy 是的，我也在檢查同樣的事情。我在這裡貼了一個「徵才」貼文，提供每月 $150 的 3 個工作流程每日監控服務。它獲得了 65 次瀏覽但沒有買家，而且我在這個討論串中詢問的任何人都說不出已經付費進行監控的客戶。所以我暫時擱置了。
@Loordhu_Jeyakumar 感謝你的提議，但我不為客戶運行實例，所以沒有東西可以指向。如果你們其中任何一個找到了付費的人，我真的很想聽聽他們到底在為什麼付費。
感謝你分享這些數字，很有用。如果我找到的話就會這樣做。