你本週寫的輸出檢查將在一個月內被靜音

描述問題/錯誤/問題

錯誤訊息是什麼(如有)?

請分享你的工作流

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

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

關於你的 n8n 設置的資訊

  • n8n 版本:
  • 資料庫(預設:SQLite):
  • n8n EXECUTIONS_PROCESS 設置(預設:own、main):
  • 執行 n8n 的方式(Docker、npm、n8n cloud、桌面應用):
  • 作業系統:

@moneywithjjcom 你好!歡迎你的到來!

真正的問題在於由於僵化的資料檢查造成的警報疲勞,這些檢查沒有考慮到資料實際上如何隨時間變化。
當你讓 n8n 工作流程運行數個月時,簡單的檢查會因為三個原因而失效
. 對所有缺失的資料一視同仁

. 沒有檢查回顧窗口

最後變成背景雜訊

簡而言之,問題在於建立「啞」檢查,它們不了解上下文或歷史資料的限制,最終會將一個有用的工具變成被忽視的雜訊

@moneywithjjcom 請分享你的螢幕,這樣我可以更好地幫助你

我無法誠實地回答你的真正問題——我們的檢查是結構層面的,而非內容層面的(它有沒有運行、有沒有失敗、有沒有繼續回應),而且我們刻意從不讀取執行酬載,所以我沒有第四個月關於數值列表腐爛的故事。接下來的內容是同樣的問題降低一層,而我們確實必須改變一些東西。

你所說的腐爛的粗糙版本上週發生在我們身上。無法到達的檢查因一次失敗的輪詢而觸發:一個超時的請求、一封電子郵件、實例整個時間都很好。檢查正確、警報正確,但在第二次之後你就停止閱讀它們——你的銀行對帳單操作員完全相同,只是謂語更愚蠢。修復不是更好的超時,而是停止將一個觀察視為一個狀態:現在一個中斷是兩次連續失敗,每次失敗後間隔退縮。數字 2 不是洞察;認識到單一讀數不是證據才是。

「一個檢查必須能夠拒絕回答」 是這篇文章中最敏銳的一句話,它泛化到內容之外。我們在兩個地方需要它:

  • 首次接觸。 第一次遍歷新連接的實例會讀取我們不在場的歷史記錄。對此發出警報會產生一個關於已經發生且已經處理的失敗的洪水,這是被靜音的最快路線——在第一天。所以第一次通過記錄並保持沉默。與你的規則相同:一個你未觀察到的窗口不是任何事情的證據。
  • 節奏。 你的中間情況,真實但不是每次運行,有一個結構上的孿生:月度工作流看起來對任何每天檢查的東西都停滯了。明顯的修復是讓操作員為每個工作流聲明預期間隔,這是會腐爛的版本——列表完全像他的數值列表一樣變得陳舊,而且當有人添加工作流並不告訴你時,它無聲地變得陳舊。從工作流自己的計劃觸發器推導間隔是我們找到的唯一在被忽視時倖存下來的版本。

添加到你的分類法中的一件事,而不是與之爭論。你的三個狀態都假設檢查已運行。有第四個隱藏在它們下面——檢查根本沒有執行——而且在 n8n 內部它是不可見的,因為一個存在於實例中的檢查在實例停止時停止,它的沉默看起來正好像一切正常。你的操作員靜音的警報至少仍然產生了一行他選擇忽略的內容。這個不產生任何東西,而沒有東西就是成功的樣子。

這不是一個內容問題,它不與你所描述的東西競爭,但無論你為內容構建什麼,都需要在它外面有一樣東西斷言內容檢查本身仍然運行了。

(揭示,因為它在帳戶名稱中:我們構建結構的一半。你所描述的內容的一半是更難的,而且我不認為它存在一個通用版本。)