Monitoraggio dell'agente per il lavoro programmato: costruire una busta di lavoro attesa

Il monitoraggio dell'agente per il lavoro programmato dovrebbe iniziare con una domanda: ha iniziato, finito e prodotto il risultato promesso questo evento specifico programmato all'interno della finestra consentita? Una uscita di processo verde, un battito cardiaco recente e una traccia completa non possono rispondere a questa domanda da soli. Il default pratico è un envelope espected run . Per ogni evento, registrare l'orario previsto, il ritardo di avvio consentito, il tempo massimo di esecuzione e la scadenza per la verifica del prodotto consegnato. Tieni separati questi timestamp. Un lavoro può essere in attesa legittima, in ritardo per iniziare, ancora lavorando, in ritardo, duplicato o finito senza risultato. Collassare questi stati in running e failed crea allarmi rumorosi e nasconde un falso successo. Questa guida costruisce quella busta come un contratto neutro nel tempo di esecuzione. Il dispositivo di nove casi incluso è sintetico, non è una prova di produzione, ma è eseguibile e espone le decisioni che un sistema di monitoraggio deve prendere. Ancorare il record all'evento programmato Non dedurre il tempo atteso dalla prima riga di registro. Ottenere l'orario previsto per l'evento del programmatore e conservarlo come scheduled at . Kubernetes 1.32 e successivamente aggiunge batch.kubernetes.io/cronjob scheduled timestamp a Jobs creato. Google Cloud Scheduler invia X CloudScheduler ScheduleTime , che rimane costante durante i tentativi di ripetizione. Questi valori sopravvivono ad un inizio tardivo e rendono i retest attribuibili allo stesso evento. Utilizzare una chiave di slot stabile: Allora tenete questi campi: outcome ref dovrebbe identificare le prove, non contenere il consegnabile sensibile. Potrebbe essere un hash, una versione di oggetto, un ID di test o una chiave di riga del database. Un file generato semplicemente esistente potrebbe non essere sufficiente; la verifica dovrebbe corrispondere alla vera promessa, come il brief today esiste, ha cinque elementi citati e viene memorizzato alla destinazione prevista. Il contratto di pianificazione è importante perché l'esecuzione non è necessariamente esattamente una volta. Kubernetes documenta che un CronJob può a volte creare due lavori o nessun lavoro e consiglia carichi di lavoro idempotenti. Cloud Scheduler descrive almeno una consegna e richiede anche obiettivi idempotenti. Il monitoraggio deve quindi trattare le riprese duplicate come uno stato di prima classe, non come una anomalia impossibile. Calcolare tre scadenze, non un tempo fuori Definire l'involucro con tre limiti indipendenti: I valori dovrebbero provenire da distribuzioni di tempo di esecuzione osservate e da requisiti aziendali, non da una predefinita universale. Un compito programmato alle 09:00 può essere perfettamente sano quando inizia alle 09:40. Lo stesso ritardo di 40 secondi potrebbe violare una promessa di spedizione di meno di un minuto. Amazon EventBridge Scheduler, ad esempio, documenta la precisione di invocazione di 60 secondi; trattare il secondo 01 come late avrebbe interpretato male il contratto del programmatore. I tre limiti rispondono a domande diverse: Stato Le prove Risposta dell'operatore waiting for start Non esiste alcuna corsa, ma start deadline non è passato Aspetta. missed start Non esiste alcuna corsa dopo start deadline Controllo della programmazione e della disponibilità running Una corsa è attiva prima di finish deadline Lascia stare. overrun La corsa attiva ha superato finish deadline Controllare i progressi prima di interrompere outcome pending Il processo è terminato; la finestra di verifica rimane aperta Aspetta il verificatore outcome missing Il termine di verifica passato senza prove Investigare il falso successo duplicate start Più di una corsa richiede la stessa chiave slot Contiene effetti indesiderati; ispezionare la causa healthy Il risultato promesso è stato verificato. Chiudere l'evento suspended Una pausa esplicita di manutenzione o di approvazione copre il slot Supprimere il fallimento; conservare le prove di audit Questo ordine previene due errori comuni. In primo luogo, l'assenza non è un fallimento fino al termine applicabile. In secondo luogo, il completamento del processo non è il completamento del compito. Una corsa che esce alle 09:06 può rimanere outcome pending fino al completamento del caricamento, del test o della verifica della destinazione. Diventa outcome missing solo dopo che la finestra di grazia separata scade. Un'invasione non significa nemmeno il permesso di uccidere un agente. Controllare se il progresso utile è ancora in movimento, se sta aspettando un sistema esterno e se l'interruzione è reversibile. L'involucro indica dove l'attenzione è giustificata; non decide il recupero. Riproduci il classificatore con nove casi imbarazzanti L'artefatto di esecuzione valuta gli apparecchi di nuova linea con un classificatore deterministico. Fate partire con: Il dispositivo utilizza una grazia di partenza di due minuti, un tempo di esecuzione massimo di dieci minuti e una grazia di risultato di due minuti. Il risultato è: Il classificatore di base è deliberatamente piccolo: Questo esperimento dimostra il valore dei confini espliciti, ma non dimostra che le soglie scelte si adattino a un carico di lavoro reale. Suppone anche che un programmatore mappi l'evento in modo pulito a un slot. Il fan out guidato da eventi, il lavoro storico riprodotto manualmente e le attività con più consegne richieste hanno bisogno di un modello di identità ampliato. Manipolazioni duplicate, sovrapposizioni, fusi orari e pause esplicite I retri e le sovrapposizioni sono correlati ma non identici. Un nuovo tentativo può ripetere lo stesso intervallo dopo un guasto del trasporto. Una sovrapposizione può iniziare il prossimo slot mentre quello precedente è ancora attivo. Ritenere sia slot key che run id , quindi applicare il comportamento di simultaneità dichiarato dal programmatore. Kubernetes espone le politiche di simultaneità di Allow , Forbid e Replace . Secondo Forbid , un evento saltato mentre il precedente lavoro è attivo è considerato come mancato. Sotto Replace , il nuovo evento sostituisce il vecchio lavoro. Il tuo stato di monitoraggio dovrebbe preservare quel motivo, altrimenti un sostituzione intenzionale sembra un incidente. Per le attività di effetto laterale, deduplicare la chiave slot al punto di destinazione e sul monitor. Una seconda esecuzione successiva può comunque inviare una seconda fattura, sovrascrivere un rapporto più recente o pubblicare lo stesso messaggio due volte. Il monitor può rivelare il rischio, ma l'idempotenza appartiene al contratto di carico di lavoro e di destinazione. I fusi orari hanno bisogno di una regola altrettanto esplicita. Conservare i timestamp dell'evento in UTC mantenendo l'identificatore della zona oraria IANA e l'espressione originale. Le transizioni che risparmiano la luce del giorno sono specifiche per i pianificatori. EventBridge Scheduler documenta che un orario locale inesistente durante la primavera prima viene saltato e un orario locale ripetuto durante la caduta retro corre una volta. Non sintetizzare un evento missed che il programmatore non ha mai promesso. Infine, le pause devono essere modellate e non nascoste disattivando gli allarmi. Registrare chi ha fatto una pausa nel programma, perché, l'ora di inizio e di scadenza e se si prevede un ritrovamento. Kubernetes osserva che gli eventi di CronJob sospesi sono considerati come mancati e possono essere eseguiti immediatamente dopo la sospensione quando non è fissata una scadenza di inizio. Un monitor che dimentica la pausa può inondare l'operatore proprio quando finisce la manutenzione. Trasforma la busta in una regola di funzionamento tranquilla Inizia con un agente critico, non tutte le tracce: 1. Leggi il timestamp di evento nativo del programmatore, il fuso orario, la politica di riprova e la politica di concurrenza. 2. Assegna una chiave di slot prima dell'inizio del lavoro e conservala durante i ripeti tentativi. 3. Scegliere start grace , max runtime e outcome grace dai requisiti effettivi e dalle durate osservate. 4. Definire un verificatore deterministico dei risultati. 5. Riproduci la storia recente attraverso i nove stati prima di abilitare le notifiche. 6. Pagina solo quando una promessa rilevante per l'utente è al di fuori della sua busta; mantenere waiting for start , running e outcome pending visibili ma silenziosi. Rivisitare le soglie dopo che il programma, il modello, lo strumento o la destinazione sono cambiati. Un modello più grande può aumentare il tempo di esecuzione senza modificare la correttezza. Un'API esterna più lenta può allungare la verifica dei risultati. La deriva della soglia è il debito di configurazione, non la prova che un agente è diventato inaffidabile. Il presente contratto stabilisce anche un limite di dati utile. Hai bisogno di timestamp, identificatori stabili, stato, e un riferimento alle prove di verifica. Non hai bisogno di richieste automatiche, risposte, carichi utili di utensili grezzi o tracce complete. Raccoglierli solo quando una diagnosi lo richiede e la tua politica di privacy lo consente. Sidewisp è destinato a trasformare i segnali come orari mancati, stalle, guasti degli strumenti e risultati mancanti in una visione prioritaria della salute con prove esplicite e confini di approvazione. Il motore di monitoraggio della produzione e gli adattatori del tempo di esecuzione non sono generalmente spediti oggi. Sidewisp è attualmente in anteprima privata. Se questo contratto previsto corrisponde a un fallimento che si opera, l'iscrizione in anteprima privata è il prossimo passo restrittonon una affermazione che Sidewisp monitorizza già i vostri agenti in diretta. Fonti primarie Documentazione Kubernetes CronJob timestamp pianificati, scadenze di inizio, politica di concurrenza, sospensione, creazione approssimativa e idempotenza. Google Cloud Scheduler alla consegna almeno una volta, comportamento di riprova, idempotency, e l'intestabile intestazione di tempo pianificato. Amazon EventBridge Scheduler tipi di orari precisione di invocazione, fusi orari e comportamento di risparmio di luce diurna.