A hiba nem kivétel, hanem tervezendő állapot
Amíg a szerkesztőben tesztelünk, minden hibát azonnal látunk. Egy éles workflow viszont a háttérben fut, triggerre vagy ütemezésre, és ha elakad, arról magától senki nem szerez tudomást. Az n8n ezért ad külön eszközt a hibák elkapására. Ha létrehozunk egy új workflow-t, amelynek első node-ja egy Error Trigger, és ezt a workflow-t a fő workflow beállításaiban az Error workflow ponthoz rendeljük, akkor a fő workflow meghibásodásakor automatikusan lefut ez a külön error workflow. Így küldhetünk értesítést, írhatunk naplóba vagy indíthatunk kompenzáló lépést.
Node szinten is dönthetünk a hiba sorsáról
Nem minden hiba érdemli meg, hogy az egész workflow leálljon. Egy node beállításaiban megadhatjuk, mi történjen, ha éppen az a lépés hibázik. A Continue a hiba ellenére tovább lép a következő node-ra az utolsó érvényes adattal, a Continue using error output pedig a hibainformációt is átadja a következő node-nak, hogy az kezelhesse. Ha viszont mi magunk akarunk egy adott feltételnél szándékosan hibát dobni saját üzenettel, arra a Stop And Error node való.
- ContinueA node a hiba ellenére továbbenged a következő node-ra, az utolsó érvényes adatot használva. A folyamat nem áll meg egyetlen elakadás miatt.
- Continue using error outputA workflow folytatódik, és a hibainformáció külön kimeneten megy tovább a következő node-nak, amely eldöntheti, mit kezd vele.
- Stop And ErrorKülön node, amellyel egyedi hibaüzenetet jeleníthetünk meg, és bizonyos feltétel mellett szándékosan meghibásíthatjuk a végrehajtást.
Continue
- Tovább az utolsó érvényes adattal
- A hiba részletei nem mennek tovább
- Akkor jó, ha egy elem kihagyható
Continue using error output
- A workflow ugyanúgy folytatódik
- A hibainformáció is átadódik
- A következő node kezelheti a hibát
Az újrapróbálás beépített lehetőség
Sok hiba átmeneti, egy lassú API vagy egy pillanatnyi hálózati zavar. Ha egy workflow végrehajtása meghibásodik, a futás újrapróbálható. Az újrapróbált végrehajtásnál jelen lesz az execution.retryOf property, amely csak akkor létezik, ha a futás egy korábbi meghibásodott végrehajtás újrapróbálása. Ez teszi megkülönböztethetővé az eredeti és az újrapróbált futásokat, amikor a naplókat elemezzük.
A végrehajtások naplója és státusza
A workflow Executions fülén minden futás megjelenik, és státusz szerint szűrhető. Négy státusz létezik, a Failed, a Running, a Success és a Waiting. A lista nem csak visszanézésre jó, innen közvetlenül újrapróbálható egy meghibásodott futás. Ez a nézet a napi üzemeltetés kiindulópontja, itt látjuk, mennyi futás megy hibára, és melyik lépésen akadt el.
Az instance állapotát is figyeljük
Self-hosted esetben a workflow-k mellett magát az n8n instance-t is monitorozni kell. Három végpont hívható az állapot ellenőrzésére, a /healthz, a /healthz/readiness és a /metrics. A production monitorozáshoz a JSON formátumú logolás ajánlott, amely soronként egy JSON objektumot ír ki, benne az üzenettel, a szinttel, az időbélyeggel és minden metaadattal. Ez a strukturált napló géppel is feldolgozható, így egy külső monitorozó rendszer könnyen riaszthat, ha romlik a helyzet.
Ennyi állapot-végpont hívható self-hosted n8n-nél, a /healthz, a /healthz/readiness és a /metrics, mellettük JSON formátumú, soronként egy objektumot kiíró logolás ajánlott a production monitorozáshoz.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →