Einleitung
Das Zustandsmonitoring eines Supportteams muss dieselbe kleine Prüfung auf zwei Arten ausführen können: nachdem ein Benutzer sie anfordert und regelmäßig ohne Benutzeranfrage. Sie implementieren beide Varianten, unterscheiden zwischen Bestätigung und Abschluss, testen die Lebensdauer von Ereignissen lokal und beobachten eine echte geplante Cloud-Ausführung.
Diese unabhängige VM startet in /home/labex/project/task-monitor mit Node.js 22.22.0, dem lokalen Wrangler 4.131.1, Miniflare 4.20260730.0 für isolierte Bewertungen und einem synthetischen internen Health-Service-Fixture. Sie verwenden dabei erneut die zuvor erlernten Fähigkeiten zu Service-Bindings und Geräteautorisierung, jedoch keine vorherige VM und keine vorherige Ressource. Verwenden Sie Ihr eigenes Lernkonto. Eine Domain, ein Speicherprodukt oder ein kostenpflichtiges Upgrade ist nicht erforderlich. Anfragen und geplante Aufrufe werden auf die normale Kontonutzung angerechnet.
Lassen Sie ein Terminal geöffnet. Der kurze Zeitplan von einer Minute dient nur für kurzlebige Tests. Beenden Sie das Lab, indem Sie Log-Streams stoppen, beide Workers mit bestehender Autorisierung löschen, ihre Abwesenheit bestätigen und sich abmelden. Hintergrundarbeit ist hier begrenzt und nicht dauerhaft. Verwenden Sie sie nicht als Zusage für eine zuverlässige Zustellung über eine Warteschlange.
Vor dem Abschluss der Hintergrundarbeit zurückkehren
In diesem Schritt bestätigt ein öffentlicher Endpunkt eine kleine Health-Check-Anfrage, während ein bereitgestellter interner Service die asynchrone Arbeit ausführt. Dies ist eine unabhängige VM. Der Service ist ein neues Fixture und keine Ressource aus einem früheren Lab.
cd /home/labex/project/task-monitor
node --version
npx wrangler --version
cat health/index.js
Das Fixture wartet 250 Millisekunden und gibt synthetisches JSON zurück. Es sendet keine externen Anfragen und speichert keine Daten. Erzeugen Sie einen eindeutigen Basisnamen und konfigurieren Sie anschließend den öffentlichen Worker sowie dessen internen HEALTH-Service. Dabei handelt es sich um die standardmäßigen Service-Bindings, die Sie bereits verwendet haben.
WORKER_NAME="labex-tasks-$(openssl rand -hex 6)"
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"workers_dev": true,
"preview_urls": false,
"services": [
{
"binding": "HEALTH",
"service": "$WORKER_NAME-health"
}
],
"triggers": {
"crons": []
}
}
CONFIG
cat > health/wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME-health",
"main": "index.js",
"compatibility_date": "2026-07-30",
"workers_dev": false,
"preview_urls": false
}
CONFIG
cat > src/index.js <<'JS'
async function checkHealth(env, details) {
const url = new URL('https://health.internal/health');
url.searchParams.set('probe', details.probe);
const response = await env.HEALTH.fetch(url, {signal: AbortSignal.timeout(3000)});
if (!response.ok) throw new Error('health_service_unavailable');
const data = await response.json();
if (data.status !== 'ok' || data.service !== 'labex-health-fixture' || data.probe !== details.probe) {
throw new Error('unexpected_health_response');
}
console.log(JSON.stringify({event: 'health_check', ...details, status: data.status, service: data.service}));
}
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
if (url.pathname === '/health' && request.method === 'GET') {
return Response.json({status: 'ok'}, {headers: {'Cache-Control': 'no-store'}});
}
if (url.pathname !== '/checks') return Response.json({error: 'not_found'}, {status: 404});
if (request.method !== 'POST') {
return Response.json({error: 'method_not_allowed'}, {status: 405, headers: {Allow: 'POST'}});
}
const probe = url.searchParams.get('probe') || '';
if (!/^[a-z0-9-]{1,48}$/.test(probe)) {
return Response.json({error: 'invalid_probe'}, {status: 400});
}
ctx.waitUntil(checkHealth(env, {source: 'request', probe}).catch(() => {
console.error(JSON.stringify({event: 'health_check_failed', source: 'request', probe}));
}));
return Response.json({accepted: true, probe}, {status: 202, headers: {'Cache-Control': 'no-store'}});
}
};
JS
checkHealth überprüft die tatsächliche Antwort der Abhängigkeit und gibt ein kleines strukturiertes Ergebnis aus. Das Abbruchsignal nach drei Sekunden begrenzt die Anfrage. Der öffentliche Handler übergibt sein Promise an ctx.waitUntil und gibt sofort HTTP 202 zurück. 202 bestätigt diesen kurzlebigen Versuch, verspricht jedoch keine dauerhafte Zustellung. Der catch-Block protokolliert einen Fehler, ohne rohe Ausnahmen, Anfragen oder Zugangsdaten auszugeben. Verwenden Sie ausschließlich die hier gezeigten synthetischen Probe-Werte.
npx wrangler dev -c wrangler.jsonc -c health/wrangler.jsonc --ip 0.0.0.0 --port 8080 > dev.log 2>&1 &
Warten Sie auf die Eingabeaufforderung und prüfen Sie anschließend das Log. Fahren Sie fort, sobald der öffentliche Entwicklungsserver auf Port 8080 bereit ist. Wenn der Start noch läuft, warten Sie kurz und lesen Sie das Log erneut.
cat dev.log
curl -i http://127.0.0.1:8080/health
curl -i -X POST "http://127.0.0.1:8080/checks?probe=manual-one"
cat dev.log
Die direkt ausgeführte Health-Route gibt 200 und den Status ok zurück. Die POST-Anfrage gibt 202 mit accepted: true und dem Probe-Wert manual-one zurück. Nachdem die Abhängigkeit abgeschlossen ist, enthält das Log event: health_check, source: request, denselben Probe-Wert und den Status ok. Wenn Sie das Log zu früh lesen, lesen Sie es nach einem kurzen Moment erneut. Dass die Antwort vor einem späteren Log-Eintrag eintrifft, ist eine Beobachtung und kein präziser Performance-Benchmark.
Verwenden Sie die Verifizierung, während der Server läuft. Eine isolierte Laufzeitumgebung hält ihr eigenes Health-Fixture hinter einem kontrollierten Gate bereit. Sie verlangt, dass die direkte Antwort eintrifft, bevor dieses Gate geöffnet wird, und erwartet anschließend abgeschlossene Hintergrundarbeit. Außerdem prüft sie die öffentliche Health-Route sowie abgelehnte Methoden- und Probe-Fälle. Dieser Test ruft Cloudflare nicht auf.
Den geplanten Handler lokal aufrufen
In diesem Schritt verwenden Sie die Health-Check-Operation erneut in einem durch einen Cron-Trigger gestarteten Handler. Überprüfen und stoppen Sie den tatsächlichen Entwicklungsprozess, bevor Sie den Code ändern. Ersetzen Sie die Jobnummer, falls sie von der Beispielnummer abweicht.
jobs
kill %1
cat > src/index.js <<'JS'
async function checkHealth(env, details) {
const url = new URL('https://health.internal/health');
url.searchParams.set('probe', details.probe);
const response = await env.HEALTH.fetch(url, {signal: AbortSignal.timeout(3000)});
if (!response.ok) throw new Error('health_service_unavailable');
const data = await response.json();
if (data.status !== 'ok' || data.service !== 'labex-health-fixture' || data.probe !== details.probe) {
throw new Error('unexpected_health_response');
}
console.log(JSON.stringify({event: 'health_check', ...details, status: data.status, service: data.service}));
}
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
if (url.pathname === '/health' && request.method === 'GET') {
return Response.json({status: 'ok'}, {headers: {'Cache-Control': 'no-store'}});
}
if (url.pathname !== '/checks') return Response.json({error: 'not_found'}, {status: 404});
if (request.method !== 'POST') {
return Response.json({error: 'method_not_allowed'}, {status: 405, headers: {Allow: 'POST'}});
}
const probe = url.searchParams.get('probe') || '';
if (!/^[a-z0-9-]{1,48}$/.test(probe)) {
return Response.json({error: 'invalid_probe'}, {status: 400});
}
ctx.waitUntil(checkHealth(env, {source: 'request', probe}).catch(() => {
console.error(JSON.stringify({event: 'health_check_failed', source: 'request', probe}));
}));
return Response.json({accepted: true, probe}, {status: 202, headers: {'Cache-Control': 'no-store'}});
},
async scheduled(controller, env) {
await checkHealth(env, {
source: 'scheduled',
probe: `cron-${controller.scheduledTime}`,
cron: controller.cron,
scheduledTime: controller.scheduledTime
});
}
};
JS
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"workers_dev": true,
"preview_urls": false,
"services": [
{
"binding": "HEALTH",
"service": "$WORKER_NAME-health"
}
],
"triggers": {
"crons": [
"* * * * *"
]
}
}
CONFIG
Der Ausdruck mit fünf Feldern * * * * * bedeutet jede Minute in UTC. Dieser absichtlich häufige Zeitplan ist nur für ein kurzes, kurzlebiges Experiment gedacht. scheduled wartet auf den Abschluss der Health-Operation, sodass das Ergebnis des Aufrufs den Abschluss widerspiegelt. Der Handler gibt keine HTTP-Antwort zurück. Das Log enthält den tatsächlichen Cron-Ausdruck und den geplanten Zeitpunkt des Triggers.
npx wrangler dev -c wrangler.jsonc -c health/wrangler.jsonc --ip 0.0.0.0 --port 8080 > dev.log 2>&1 &
Warten Sie auf die Eingabeaufforderung und prüfen Sie anschließend das Log. Fahren Sie fort, sobald der öffentliche Entwicklungsserver auf Port 8080 bereit ist. Wenn der Start noch läuft, warten Sie kurz und lesen Sie das Log erneut.
cat dev.log
curl -i "http://127.0.0.1:8080/cdn-cgi/local/scheduled?cron=*+*+*+*+*&time=1700000000000&format=json"
cat dev.log
Der lokale Trigger sollte outcome ok zurückgeben. Das Anwendungslog sollte source scheduled, den Cron-Ausdruck * * * * * und scheduledTime 1700000000000 enthalten. Dieser alte Zeitstempel ist eine absichtlich synthetische Testeingabe und kein Nachweis für eine aktuelle Cloud-Ausführung. Verwenden Sie die Verifizierung, um einen anderen kontrollierten Zeitpunkt auszuführen und zu bestätigen, dass der Health-Service aufgerufen wurde.
Bei HTTP-Aufrufen kann waitUntil die Arbeit bis zu 30 Sekunden nach dem Senden der Antwort oder nach dem Trennen des Clients fortsetzen. Dieses Zeitfenster wird von den Hintergrund-Promises der Anfrage gemeinsam genutzt. Es handelt sich nicht um eine dauerhafte Warteschlange und ist keine Garantie für Wiederholungen. Die kleine, auf drei Sekunden begrenzte Operation dieses Labs passt zu diesem Zweck. Arbeit, die eine zuverlässige Zustellung oder Wiederholungen benötigt, gehört in ein geeignetes Queue- oder Workflow-Design außerhalb dieses Labs. Weitere Informationen finden Sie in der Dokumentation zur context API und zum scheduled handler, die unterschiedliche Lebensdauern von Aufrufen beschreibt.
Hintergrundarbeit von Anfragen bereitstellen und beobachten
In diesem Schritt stellen Sie beide neuen Worker in Ihrem eigenen Lernkonto bereit. Stoppen Sie den lokalen Prozess und autorisieren Sie diese neue VM mit dem vertrauten Geräteablauf.
jobs
kill %1
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Öffnen Sie den angezeigten Geräte-Link in Ihrem angemeldeten Browser, geben Sie den zugehörigen Code ein, prüfen Sie die angeforderten Berechtigungen und wählen Sie das Lernkonto aus. Warten Sie auf die Erfolgsmeldung im Terminal.
npx wrangler whoami --json
Bestätigen Sie den Kontonamen, auch wenn nur ein Konto aufgeführt ist. Ersetzen Sie YOUR_ACCOUNT_ID in beiden folgenden Konfigurationen durch die tatsächliche ID. Behalten Sie dieselben generierten Worker-Namen und den Zeitplan von einer Minute bei. Für den öffentlichen Worker werden außerdem Workers Logs aktiviert. Dadurch sind seine Aufruf- und Anwendungslogs im Dashboard unter Observability verfügbar. Dies ist unabhängig von der aktiven wrangler tail-Verbindung. Dieses kurzlebige Lab gibt ausschließlich synthetische Health-Check-Daten aus. Protokollieren Sie niemals Zugangsdaten. Weitere Informationen finden Sie in der Dokumentation zu Workers Logs.
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-07-30",
"workers_dev": true,
"preview_urls": false,
"services": [
{
"binding": "HEALTH",
"service": "$WORKER_NAME-health"
}
],
"triggers": {
"crons": [
"* * * * *"
]
},
"observability": {
"enabled": true
},
"account_id": "YOUR_ACCOUNT_ID"
}
CONFIG
cat > health/wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME-health",
"main": "index.js",
"compatibility_date": "2026-07-30",
"workers_dev": false,
"preview_urls": false,
"account_id": "YOUR_ACCOUNT_ID"
}
CONFIG
npx wrangler deploy -c health/wrangler.jsonc
npx wrangler deploy
Der interne Health-Service wird zuerst bereitgestellt, damit das Binding des öffentlichen Workers ihn auflösen kann. Bestätigen Sie, dass die Ausgabe der öffentlichen Bereitstellung den Zeitplan * * * * * enthält. Kopieren Sie anschließend die tatsächliche workers.dev-Adresse in die folgende Variable.
APP_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$APP_URL/health"
npx wrangler tail --format pretty > events.log 2> tail-errors.log &
Warten Sie einige Sekunden, damit die Tail-Verbindung initialisiert werden kann, und senden Sie anschließend eine synthetische Prüfung.
sleep 5
curl -i -X POST "$APP_URL/checks?probe=remote-one"
cat events.log
Suchen Sie das POST-Ereignis und den zugehörigen Health-Check-Log-Eintrag mit source request und probe remote-one. Wenn noch kein Ereignis sichtbar ist, prüfen Sie tail-errors.log, warten Sie kurz, senden Sie die Anfrage erneut und lesen Sie events.log wieder ein. Eine Logdatei aus einem früheren Lab ist kein Nachweis für diese Bereitstellung.
Öffnen Sie im Dashboard Compute → Workers & Pages für dieses Konto. Bestätigen Sie beide exakten Namen, die Adresse des öffentlichen Workers und dessen HEALTH-Binding zum passenden internen Service. Verwenden Sie die Verifizierung: Sie prüft die authentifizierte Eigentümerschaft sowie die Metadaten von Endpunkt und Binding. Danach öffnet sie eine eigene kurze Live-Tail-Sitzung und sendet einen neuen Probe-Wert, um den Abschluss der Hintergrundarbeit zu bestätigen. Der Prüfer akzeptiert events.log nicht als Nachweis. Lassen Sie Ihren Lern-Tail-Prozess für den nächsten Schritt weiterlaufen.
Eine echte Cron-Ausführung beobachten
In diesem Schritt unterscheiden Sie die Bereitstellungskonfiguration von der tatsächlichen Ausführung. Öffnen Sie den öffentlichen Worker im Dashboard und prüfen Sie Settings → Trigger events → Cron triggers. Bestätigen Sie, dass der Zeitplan als Every minute angezeigt wird. Next time ist eine Vorhersage und keine abgeschlossene Ausführung. Ein konfigurierter Zeitplan allein beweist nicht, dass der Handler ausgeführt wurde.
Das folgende Beispiel zeigt das kürzeste unterstützte Intervall: * * * * *, also einmal pro Minute. Vergleichen Sie den Worker-Namen mit Ihrer eigenen Konfiguration. Name und angezeigte Zeit sind Beispiele. Sie müssen im Dashboard keinen weiteren Trigger hinzufügen, wenn Wrangler ihn bereits konfiguriert hat.
Lassen Sie die bestehende Lern-Tail-Verbindung weiterlaufen. Warten Sie auf ein echtes geplantes Ereignis und prüfen Sie dieselbe Logdatei:
sleep 60
cat events.log
Suchen Sie in der lesbaren Tail-Ausgabe nach einem erfolgreichen geplanten Aufruf, der durch den Cron-Ausdruck und seine Ausführungszeit gekennzeichnet ist. Der zugehörige Health-Check-Log-Eintrag muss source scheduled, cron * * * * *, status ok, service labex-health-fixture und scheduledTime enthalten. Der Probe-Wert besteht aus cron-, gefolgt von diesem scheduledTime. Die unabhängige Verifizierung prüft die strukturierten Ereignismetadaten von Cloudflare separat gegen dieses Anwendungslog. Ein POST-Ereignis, ein lokaler synthetischer Zeitstempel oder ein leeres Log belegt dieses Ergebnis nicht.
Um diese Ausgabe mit dem Browser zu verknüpfen, öffnen Sie für denselben Worker die Seite Observability → Events. Verwenden Sie beim Warten Live oder aktualisieren Sie die gespeicherte Ereignisabfrage mit einem Zeitraum, der Ihre Bereitstellung umfasst. Aufrufzeilen für diesen Handler zeigen * * * * *. Erweitern Sie eine Zeile, wählen Sie View invocation und erweitern Sie die zugehörige Zeile des Anwendungslogs, um die Health-Check-Felder zu prüfen. Bei einem strukturierten Anwendungslog kann die Zelle Message leer sein. Erweitern Sie die Zeile, statt dies als fehlende Daten zu behandeln. Sie können die Live-Anzeige beim Lesen pausieren.
In diesem echten Beispiel ist source gleich scheduled, status gleich ok und service gleich labex-health-fixture. Der Probe-Wert cron-... entspricht dem scheduledTime des Anwendungslogs in Millisekunden. Das Dashboard zeigt den sichtbaren Zeitstempel in seiner angezeigten Zeitzone an (hier GMT+8), während der Cron-Zeitplan UTC verwendet. Ihr Name, Ihre Aufruf-ID und Ihre Zeit werden abweichen. Lesen Sie diese Felder gemeinsam mit dem Ergebnis des Aufrufs. Der Screenshot allein ist kein Nachweis für einen Abschluss.
Änderungen an Cron können bis zu 15 Minuten benötigen, um wirksam zu werden. Wiederholen Sie den Warte- und Prüfzyklus von einer Minute und lassen Sie höchstens 17 Minuten seit der erfolgreichen Bereitstellung verstreichen. Prüfen Sie tail-errors.log, wenn der Stream leer ist oder beendet wurde. Wenn innerhalb dieses Zeitraums kein passendes Ereignis erscheint, halten Sie an und untersuchen Sie Konfiguration, Autorisierung und Triggerstatus. Melden Sie keinen Erfolg. Dies ist eine begrenzte Lernbeobachtung und keine Garantie für eine exakt vorhersehbare Ausführungslatenz. Die Dokumentation zu Cron Triggers erläutert die Verteilung und die UTC-Zeitplanung. Gespeicherte Workers Logs können ebenfalls etwas Zeit benötigen. Aktualisieren Sie die Abfrage nach einer angemessenen Zeit für die Aufnahme der Daten. Der separate Verlauf Past Cron Events kann bei einem neuen Worker bis zu 30 Minuten benötigen, bevor Ereignisse angezeigt werden. Ein leerer Verlauf beweist keinen Fehler. Verwenden Sie innerhalb der Begrenzung dieses Labs die Echtzeitbeobachtung oben.
Verwenden Sie die Verifizierung, nachdem Sie eine Ausführung beobachtet haben. Sie prüft den bereitgestellten Zeitplan und überwacht bis zu 70 Sekunden lang einen separaten Live-Stream auf ein echtes geplantes Ereignis mit dem Health-Ergebnis. Damit wird eine vollständige Minutenbegrenzung nach dem Start der Verbindung abgedeckt. Ein Ergebnis ohne Ereignis ist nicht schlüssig. Prüfen Sie den Verbindungs- und Verteilungsstatus und wiederholen Sie den Versuch innerhalb derselben Beobachtungsgrenze. Der Prüfer erzeugt kein geplantes Ereignis künstlich. Stoppen Sie Ihren Lern-Tail-Prozess erst, wenn die Verifizierung erfolgreich ist. Verwenden Sie die tatsächliche Jobnummer.
jobs
kill %1
Beenden Sie den kurzlebigen Zeitplan umgehend, indem Sie mit dem nächsten Schritt fortfahren. Lassen Sie keinen Lernprozess mit Ausführung jede Minute unbeaufsichtigt laufen.
Beide Worker für den geplanten Test löschen
In diesem Schritt entfernen Sie den öffentlichen Worker und dessen Trigger und anschließend das interne Health-Fixture, während Sie noch autorisiert sind. Bestätigen Sie, dass beide Konfigurationen die exakten Namen dieses Labs und das vorgesehene Konto enthalten.
cat wrangler.jsonc
cat health/wrangler.jsonc
npx wrangler delete
npx wrangler delete -c health/wrangler.jsonc
Drücken Sie bei jeder Eingabeaufforderung mit einem passenden Namen die einzelne Taste y. Lassen Sie nicht zugehörige Projekte, das Konto und die Subdomain unverändert. Der festgelegte Wrangler kann nach dem Löschen eines Workers die bekannte Diagnose zur Authentifizierung der veralteten KV-Bereinigung ausgeben. Weder diese Meldung noch eine fehlgeschlagene Netzwerkanfrage beweist, dass das Löschen fehlgeschlagen ist. Erweitern Sie die Berechtigungen nicht wegen dieser Diagnose.
Aktualisieren Sie das Dashboard und verwenden Sie die Verifizierung. Eine erfolgreiche authentifizierte Worker-Bestandsaufnahme muss zeigen, dass beide Namen nicht vorhanden sind. Damit wird das Entfernen der bereitgestellten Ressourcen bestätigt, nicht jedoch die sofortige globale Verteilung jeder Scheduler-Änderung. Das Abmelden oder bloße Schließen der VM würde diese Bereinigung nicht ausführen.
Die Lab-VM trennen
In diesem Schritt bestätigen Sie, dass der Tail-Prozess beendet und die Ressourcen entfernt sind, bevor Sie diese VM trennen.
jobs
npx wrangler logout
npx wrangler whoami --json
Verlangen Sie ausdrücklich loggedIn: false. Der strukturierte unauthentifizierte Befehl kann mit einem Fehlercode beendet werden. Ein Netzwerkfehler ist nicht dasselbe Ergebnis. Verwenden Sie die Verifizierung und beenden Sie die VM. Ihre Browser-Anmeldung kann für spätere unabhängige Labs bestehen bleiben.
Zusammenfassung
Sie haben waitUntil verwendet, damit eine begrenzte Health-Prüfung nach einer direkten Bestätigung abgeschlossen werden kann, und diese Operation anschließend in einem geplanten Handler wiederverwendet. Kontrollierte lokale Tests trennten die Antwort von der verzögerten Arbeit. Ein echtes Cloud-Ereignis bestätigte nach der Bereitstellung die geplante Ausführung. Konfiguration, manueller Aufruf und Live-Ausführung lieferten unterschiedliche Arten von Nachweisen.
Sie haben Eigentümerschaft und Service-Bindings geprüft, synthetische Probe-Werte mit strukturierten Logs verknüpft, die Grenzen der Aufruflebensdauer beachtet und die kurzlebige geplante Anwendung vor dem Trennen entfernt. Eine zuverlässige Zustellung über lange Zeiträume erfordert eine andere Architektur als dieses Muster kurzlebiger Hintergrundarbeit.
