Agentenaufsicht für geplante Arbeiten: Erstellen Sie einen Umschlag für die erwartete Laufzeit

Die Überwachung der geplanten Arbeiten durch Agenten sollte mit einer Frage beginnen: beginnt, beendet und erzeugt dieses spezifische geplannte Ereignis das versprochene Ergebnis innerhalb seines zulässigen Fensters? Ein grüner Prozess Ausgang, ein kürzlich erfolgter Herzschlag und eine vollständige Spur können diese Frage nicht alleine beantworten. Die praktische Standardform ist ein erwartet getriebener Umschlag . Für jeden Vorfall erfassen Sie die vorgesehene Zeitplanung, eine zulässige Startverzögerung, eine maximale Laufzeit und eine Frist für die Überprüfung des Lieferwertes. Halten Sie diese Zeitstempel getrennt. Ein Job kann rechtmäßig warten, spät anfangen, noch arbeiten, verspätet, dupliziert oder ohne Ergebnis beendet werden. Die Zusammenbruch dieser Zustände in running und failed erzeugt laute Warnungen und verbirgt falschen Erfolg. Dieser Leitfaden erstellt diesen Umschlag als Runtime neutralen Vertrag. Die in den neun Fällen enthaltenen Vorrichtungen sind synthetisch, nicht als Produktionsnachweise, aber sie sind ausführbar und zeigen die Entscheidungen, die ein Überwachungssystem treffen muss. Verankern Sie die Aufzeichnung an den geplanten Vorfall Die erwartete Zeit darf nicht aus der ersten Zeile des Logs abgeleitet werden. Erhalten Sie die vorgesehene Zeit des Planers und behalten Sie sie als scheduled at . Kubernetes 1.32 und später batch.kubernetes.io/cronjob scheduled timestamp zu den geschaffenen Jobs hinzufügt. Google Cloud Scheduler sendet X CloudScheduler ScheduleTime , der während erneuter Versuche konstant bleibt. Diese Werte überleben einen späten Start und machen erneute Versuche auf das gleiche Ereignis zurückzuführen. Verwenden Sie einen stabilen Schlüssel: Dann behalten Sie diese Felder: outcome ref sollte Beweise identifizieren und nicht das empfindliche Lieferwert enthalten. Es könnte ein Hash sein, eine Objektversion, eine Test ID oder einen Datenbank Reienschlüssel. Eine generierte Datei, die lediglich existiert, kann nicht ausreichen; die Überprüfung sollte dem wahren Versprechen entsprechen, z. B. todays Brief existiert, hat fünf zitierte Elemente und wird am erwarteten Bestimmungsort gespeichert. Der Vertragsplaner ist wichtig, weil die Ausführung nicht unbedingt genau einmal stattfindet. Kubernetes dokumentiert, dass ein CronJob manchmal zwei Jobs oder keinen Job erstellen kann und empfiehlt idempotent Workloads. Cloud Scheduler beschreibt mindestens einmal die Lieferung und erfordert ebenfalls idempotente Ziele. Die Überwachung muss daher doppelte Anfänge als erstklassige Lage behandeln und nicht als unmögliche Anomalie. Berechnen Sie drei Fristen, nicht eine Auszeit Definition des Umschlags mit drei unabhängigen Grenzen: Die Werte sollten aus beobachteten Laufzeitverteilungen und Geschäftsanforderungen stammen und nicht aus einer universellen Vorabgabe. Eine Aufgabe, die um 09:00 Uhr geplant ist, ist möglicherweise vollkommen gesund, wenn sie um 09:00:40 Uhr beginnt. Die gleiche Verzögerung von 40 Sekunden kann ein Versprechen von weniger als einer Minute verletzen. Amazon EventBridge Scheduler beispielsweise dokumentiert eine 60 Sekunden Invokationspräzision; wenn der zweite 01 als late betrachtet würde, würde der Vertrag des Schedulers falsch interpretiert werden. Die drei Grenzen beantworten verschiedene Fragen: Staat Beweise Reaktion des Betreibers waiting for start Es gibt keinen Lauf, aber start deadline ist nicht vorbei. Warten Sie . missed start Es gibt keinen Lauf nach start deadline Überprüfung des Zeitplans und der Reichweite running Ein Lauf ist vor finish deadline aktiv Lassen Sie es in Ruhe . overrun Der aktive Lauf hat finish deadline überschritten. Überprüfen Sie die Fortschritte, bevor Sie unterbrechen outcome pending Prozess abgeschlossen; Überprüfungsfenster bleibt offen Warten Sie auf den Verifikator . outcome missing Überschrittener Überprüfungsfrist ohne Beweise Falschen Erfolg zu untersuchen duplicate start Mehr als ein Lauf beansprucht den gleichen Schlüssel Nebenwirkungen enthalten; Inspektionieren Sie die Ursache erneuten Versuchen healthy Das versprochene Ergebnis wurde verifiziert. Schließen Sie das Ereignis suspended Eine ausdrückliche Wartungs oder Genehmigungspause deckt die Lücke ab Unterdrückung von Ausfällen; Aufbewahrung von Prüfungsnachweisen Diese Ordnung verhindert zwei häufige Fehler. Zunächst ist Abwesenheit erst nach Ablauf der geltenden Frist nicht fehlerhaft. Zweitens ist die Abwicklung des Prozesses nicht die Abwicklung der Aufgabe. Ein Lauf, der um 09:06 Uhr abläuft, kann outcome pending bleiben, bis sein Upload, Test oder die Bestimmungsprüfung abgeschlossen sind. Es wird outcome missing erst nach Ablauf dieses separaten Gnadenfensters. Ein Überfall ist auch keine Erlaubnis, einen Agenten zu töten. Überprüfen Sie, ob nützliche Fortschritte noch vorhanden sind, ob sie auf einem externen System warten und ob die Unterbrechung umkehrbar ist. Der Umschlag zeigt an, wo die Aufmerksamkeit gerechtfertigt ist; er trifft nicht die Rückforderungsentscheidung. Wiederholen Sie den Klassifikator mit neun unangenehmen Fällen Das Run Artefact bewertet mit einem deterministischen Klassifikator neue Linie gegrenzte Anlagen. Führen Sie es mit: Das Gerät verwendet eine Startzeit von zwei Minuten, eine maximale Laufzeit von zehn Minuten und eine Ausgangszeit von zwei Minuten. Das Ergebnis ist: Der Kernklassifizierer ist absichtlich klein: Dieses Experiment zeigt den Wert ausdrücklicher Grenzen, beweist aber nicht, dass die gewählten Schwellenwerte einer realen Arbeitsbelastung entsprechen. Es geht auch davon aus, dass ein Scheduler die Ereigniskarten sauber zu einem Slot macht. Veranstaltungsorientierte Fan out, manuell wiederholte historische Arbeiten und Aufgaben mit mehreren erforderlichen Ergebnissen benötigen ein erweitertes Identitätsmodell. Handling Duplikate, Überschneidungen, Zeitzonen und Pausen explizit Wiederversuche und Überschneidungen sind verwandt, aber nicht identisch. Ein erneuter Versuch kann nach einem Transportfehler den gleichen Schnitt wiederholen. Eine Überschneidung kann den nächsten Slot beginnen, während der vorherige noch aktiv ist. Behalten Sie sowohl slot key als auch run id , und wenden Sie dann das von dem Planer angegebene Gleichzeitungsverhalten an. Kubernetes stellt die Konkurenzpolitik von Allow , Forbid und Replace dar. Unter Forbid gilt ein übersprungenes Ereignis, während der vorherige Job aktiv ist, als verpasst. Unter Replace verdrängt das neue Ereignis den alten Job. Ihr Überwachungsstaat sollte diesen Grund bewahren, sonst sieht ein vorsätzlicher Ersatz wie ein Absturz aus. Bei Nebeneffektabgaben werden die Schlüssel auf der Schaltfläche des Ziels sowie auf dem Monitor gedupliziert. Ein zweiter Erfolgreicher Run kann immer noch eine zweite Rechnung senden, einen neueren Bericht überschreiben oder dieselbe Nachricht zweimal veröffentlichen. Die Überwachung kann das Risiko aufdecken, aber die Unfähigkeit gehört zum Arbeits und Bestimmungsvertrag. Zeitzonen brauchen eine ebenso explizite Regel. Speichern Sie die Zeitstempel für Ereignisse in UTC und behalten Sie den Zeitplans IANA Zeitzone Identifikator und den ursprünglichen Ausdruck. Die Übergangsvorgänge, die das Tageslicht sparen, sind scheduler spezifisch. EventBridge Scheduler dokumentiert, dass eine nicht vorhandene lokale Zeit während des Frühlingsvorgangs übersprungen wird und eine wiederholte lokale Zeit während des Fall Backs einmal läuft. Synthetisieren Sie keine vermissten Vorkommnisse, die der Planer nie versprochen hat. Schließlich müssen Pausen modelliert und nicht durch Deaktivierung von Alarmen verborgen werden. Aufzeichnen Sie, wer den Zeitplan unterbrochen hat, warum, wann er beginnt und wann er abläuft und ob eine Nachholung erwartet wird. Kubernetes stellt fest, dass ausgeschaltete CronJob Ereignisse als verpasst gelten und unmittelbar nach der Aussetzung laufen können, wenn kein Startdatum festgelegt ist. Ein Monitor, der die Pause vergisst, kann den Betreiber genau dann überschwemmen, wenn die Wartung beendet ist. Verwandeln Sie den Umschlag in eine ruhige Betriebsregel Beginnen Sie mit einem kritischen Agenten, nicht jeder Spur: 1. Lesen Sie den Zeitstempel, die Zeitzone, die Wiederversuchsrichtlinie und die Gleichzeitungsrichtlinie des Zeitplaners. 2. Berechnen Sie einen Schlüssel vor dem Start der Arbeit und bewahren Sie ihn durch erneute Versuche. 3. Wählen Sie start grace , max runtime und outcome grace aus den tatsächlichen Anforderungen und beobachteten Laufzeiten aus. 4. Definition eines deterministischen Ergebnisverifikators. 5. Wiederholen Sie die jüngste Geschichte durch die neun Staaten, bevor Sie Benachrichtigungen aktivieren. 6. Seite nur, wenn ein für den Benutzer relevantes Versprechen außerhalb seines Umschlags ist; halten Sie waiting for start , running und outcome pending sichtbar, aber ruhig. Überprüfen Sie die Schwellenwerte nach Änderungen des Zeitplans, des Modells, des Werkzeugs oder des Ziels. Ein größeres Modell kann die Laufzeit erhöhen, ohne die Richtigkeit zu ändern. Eine langsamere externe API kann die Ergebnisüberprüfung verlängern. Das Schwellenrücktritt ist eine Konfigurationsschuld, nicht ein Beweis dafür, dass ein Agent unzuverlässig wurde. Dieser Vertrag legt auch eine nützliche Datengrenze fest. Sie benötigen Zeitstempel, stabile Identifikatoren, Zustand und einen Verweis auf Verifizierungsbeweise. Sie benötigen nicht automatisch Anfragen, Antworten, Rohwerkzeuge oder vollständige Spuren. Sammeln Sie diese nur, wenn eine Diagnose sie erfordert und Ihre Datenschutzrichtlinie dies erlaubt. Sidewisp soll Signale wie verpasste Zeitpläne, Stände, Ausfälle bei Werkzeugen und fehlenden Ergebnissen in eine priorisierte Gesundheitsansicht mit expliziten Beweisen und Genehmigungsgrenzen verwandeln. Der Produktionsüberwachungsmotor und die Laufzeit Adapter werden heute im Allgemeinen nicht ausgeliefert. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Wenn dieser erwartete Laufvertrag einem Fehler entspricht, den Sie betreiben, ist die private Vorschau Anmeldung der eingeschränkte nächste Schrittnicht ein Anspruch darauf, dass Sidewisp bereits Ihre Live Agenten überwacht. Hauptquellen Kubernetes CronJob Dokumentation geplante Zeitstempel, Startfristen, Gleichzeitungspolitik, Aussetzung, ungefähre Erstellung und Unabhängigkeit. Überblick über den Google Cloud Scheduler bei mindestens einer Lieferung, Wiederversuchverhalten, Störung und der stabile Zeitheader. Amazon EventBridge Zeitplanartypen Anrufpräzision, Zeitzonen und Tageslicht Sparverhalten.