Monitoring 6 min läsning

Heartbeat-övervakning eller upptidskontroller: när du ska använda vilken

Upptidskontroller frågar din tjänst om den är uppe; heartbeats väntar på att ditt jobb ska säga att det har körts. Så fungerar de, vad de missar och hur du kombinerar dem.

En upptidskontroll hämtar: en övervakningstjänst skickar en förfrågan till din webbplats eller ditt API enligt ett schema och larmar när svaret är fel eller uteblir. En heartbeat skickar: ditt jobb eller din tjänst skickar en förfrågan till övervakningstjänsten varje gång det körs, och larmet går när förfrågan inte kommer fram. Använd upptidskontroller för allt som människor når över nätverket, och heartbeats för arbete som körs enligt schema eller saknar publik adress. De flesta miljöer behöver båda.

De två är lätta att blanda ihop eftersom båda slutar i ”larma när något är fel”. Men de ser olika fel, och använder du den ena där du behöver den andra får du en blind fläck som visar sig först när något går sönder.

Så fungerar en upptidskontroll

Övervakningstjänsten är klienten. Varje minut, eller med det intervall du väljer, anropar den en URL, pingar en värd eller öppnar en port och bedömer svaret: statuskoden, svarstiden, ett nyckelord på sidan, certifikatet. Om kontrollen misslyckas och en andra kontroll bekräftar det får du ett larm. Det här är en form av syntetisk övervakning: en robot gör det en besökare skulle göra.

Den fångar: en webbplats eller ett API som ligger nere, är långsamt, svarar med fel, visar fel innehåll eller har slutat fungera på grund av ett utgånget certifikat eller en DNS-ändring. Allt som en besökare skulle stöta på.

Den missar: allt som inte svarar på förfrågningar. En backup som inte kördes, en köarbetare som hängde sig, en import som misslyckades kl. 02.00. Webbplatsen är uppe, så varje kontroll går igenom.

Så fungerar en heartbeat

Ditt jobb är klienten. Du talar om för övervakningstjänsten när jobbet ska köras, och jobbet anropar en unik ping-URL när det är klart. Om pingen är försenad med mer än en marginal du väljer får du ett larm. Idén är ett dödmansgrepp: tystnaden är signalen. Därför kallas heartbeat-övervakning också push-övervakning eller dödmansgreppsövervakning.

0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token

Den fångar: jobb som inte startade, kraschade innan de var klara, kördes enligt fel schema eller, med en startping, tog alldeles för lång tid. Med en slutkod i pingen fångar den också jobb som kördes men misslyckades.

Den missar: om någon kan nå din tjänst. Ett jobb på en server kan pinga glatt medan webbplatsen på samma server svarar 502 till varje besökare.

Sida vid sida

UpptidskontrollHeartbeatVem skickar förfråganÖvervakningstjänstenDitt jobb eller din tjänstLarmar närSvaret är fel, långsamt eller uteblirPingen är sen eller rapporterar ett felKräver publik adressJaNej, bara utgående HTTPSKonfigurationEn URL, värd eller portEtt schema, en marginal och en förfrågan i jobbetSerDet som besökare och API-klienter uppleverOm bakgrundsarbetet kördes och hur det slutadeBlind förArbete som inte svarar på förfrågningarOm någon kan nå tjänsten

När du ska använda en upptidskontroll

Din startsida och sidorna som drar in pengar: kassan, registreringen, inloggningen.

Publika API:er och webhook-mottagare, med kontroller av statuskoden och den JSON som kommer tillbaka.

En endpoint för hälsokontroll som testar databasen och andra beroenden vid varje anrop.

Tjänster på andra portar, till exempel en e-postserver, med en portkontroll.

Tumregeln: om en person eller ett annat system anropar det, kontrollera det utifrån på samma sätt som de gör.

När du ska använda en heartbeat

Cron-jobb: backuper av databaser och filer, nattliga importer och exporter, rapportgenerering, faktureringskörningar.

Schemalagda uppgifter i andra former: en schemalagd aktivitet i Windows, ett Kubernetes CronJob, ett schemalagt GitHub Actions-arbetsflöde, en serverless-funktion med timer.

Skript för certifikatförnyelse och datasynk mellan system.

Allt bakom en brandvägg eller NAT som inte går att nå utifrån men som kan göra en utgående HTTPS-förfrågan.

Långlivade workers

En köarbetare eller daemon körs inte enligt schema, men den kan ändå skicka en heartbeat. Pinga från huvudloopen med några minuters mellanrum och ge monitorn ett intervall i stället för ett cron-uttryck. Om loopen hänger sig, processen dödas eller servern startas om utan att den startas igen, upphör pingarna och du får veta det. Pinga från loopen som gör jobbet, inte från en separat tråd, annars fortsätter en fastnad worker att rapportera att allt är bra.

När du behöver båda

De flesta riktiga tjänster har en entré och ett bakre kontor. Övervaka var och en med det verktyg som ser den:

En e-handel: upptidskontroller på startsidan och i kassan, och heartbeats på den nattliga orderexporten och databasbackupen.

En SaaS-produkt: en upptidskontroll på API:ets hälsoendpoint, och heartbeats på köarbetaren och jobbet som skickar fakturor.

En intern tjänst: ingen publik adress, alltså en heartbeat från själva tjänsten, plus upptidskontroller på de publika sidor som är beroende av dess data.

Ett alternativ är att visa jobbstatus via hälsoendpointen, till exempel genom att låta kontrollen misslyckas när den senaste backupen är äldre än 25 timmar. Det fungerar, men det kopplar ihop webbplatsens upptid med dina backuper, så att en försenad backup syns som nertid för webbplatsen i dina rapporter. En separat heartbeat håller isär de två signalerna, och de personer som får respektive larm.

Få tiderna rätt

Intervall för upptidskontroller: varje minut för sidor som drar in pengar, eftersom intervallet är den längsta tid du kan vara ovetande om ett avbrott. Mindre kritiska sidor klarar sig med ett längre intervall.

Marginal för heartbeats: längre än den normala variationen i när jobbet blir klart. En backup som startar kl. 03.00, tar 5 till 20 minuter och pingar när den är klar behöver minst 20 minuters marginal; 30 ger utrymme för en långsam natt.

Maximal körtid: med en startping kan du larma när en körning tar mycket längre tid än vanligt. Ett jobb som hängt sig skickar aldrig sin slutping heller, men det här larmet kommer så fort gränsen passeras.

Tidszon: ett cron-schema körs i serverns tidszon, ofta UTC. Ge monitorn samma tidszon, annars gör sommartiden att den väntar sig jobbet en timme för tidigt eller för sent två gånger om året. Verktyget för cron-uttryck visar när ett schema faktiskt körs.

Vanliga misstag

Att bara pinga i början. Ett jobb som startar och kraschar checkar ändå in. Pinga i slutet, eller skicka båda.

Att pinga även när jobbet misslyckas. backup.sh; curl … pingar oavsett vad som hände. Använd &&, eller skicka slutkoden så att ett fel rapporteras som ett fel.

En ping som kan få jobbet att hänga sig. Ge curl en timeout och nya försök (-m 10 –retry 3), så att ett långsamt nätverk varken blockerar jobbet eller tappar pingen.

Att använda en heartbeat för en publik webbplats. En server som pingar ut bevisar bara att den når internet, inte att besökarna når den.

Att övervaka cron-daemonen i stället för jobbet. Daemonen kan fungera fint medan ett jobb misslyckas varje natt. Varje jobb som spelar roll får en egen heartbeat.

Mer om heartbeat-sidan i så övervakar du cron-jobb och så förhindrar du missade cron-uppgifter.

Båda på ett ställe med Uptimecheck

Uptimecheck kör båda typerna av monitorer i samma konto, med samma larmkanaler och samma incidenthistorik.

Upptidsövervakning: HTTP(S)-, ping- och portkontroller så ofta som varje minut från Stockholm, London och New York, där varje fel bekräftas från en andra plats innan ett larm går. HTTP-kontroller kan testa statuskoden, ett nyckelord, JSON-fält och headers.

Övervakning av cron-jobb: ett crontab-uttryck i din tidszon, sommartid inräknad, eller ett enkelt intervall; en marginal från 1 minut till 6 timmar; /start-pingar med en maximal körtid från 1 minut till 24 timmar; /fail eller slutkoden för att rapportera hur en körning slutade; och jobbets utdata, som skickas med pingen, visas i larmet.

Gränser: Start har 15 upptidsmonitorer och 10 cron-jobb, Professional 100 och 50, Business 250 och 150. Se priser.

För att komma igång, se så övervakar du ett cron-jobb med en heartbeat och exemplen på pingar från cron-jobb för Laravel, Kubernetes, GitHub Actions, systemd och Windows. För diskar och minne på servern under, lägg till serverövervakning.

Håll koll på både entrén och det bakre kontoret. Prova Uptimecheck gratis i 14 dagar, inget kreditkort krävs.

Frågor

Vad är skillnaden mellan heartbeat-övervakning och upptidsövervakning?

Upptidsövervakning skickar förfrågningar till din tjänst och kontrollerar svaren. Heartbeat-övervakning väntar på att ditt jobb ska skicka en förfrågan varje gång det körs, och larmar när den inte kommer i tid.

Vad är ett dödmansgrepp inom övervakning?

Ett annat namn på en heartbeat-monitor: den reagerar när en regelbunden signal upphör. Ditt jobb pingar vid varje körning, och tystnad efter marginalen utlöser larmet.

Kan jag övervaka ett cron-jobb med en upptidskontroll?

Inte direkt, eftersom ett cron-jobb inte svarar på förfrågningar. Du kan visa dess senaste körtid på en hälsoendpoint, men en heartbeat är enklare och håller jobbfel utanför webbplatsens upptidssiffror.

Fungerar heartbeats bakom en brandvägg?

Ja. Jobbet gör bara en utgående HTTPS-förfrågan, så det fungerar från servrar utan publik adress, så länge utgående trafik till ping-URL:en är tillåten.

Läs vidare

Guides 5 min läsning

403 Forbidden: vad felet betyder och hur du åtgärdar det

En 403 betyder att servern förstod förfrågan och vägrade. De vanliga orsakerna, vad besökare kan prova, hur sajtägare hittar regeln som blockerar och varför monitorer får 403 när webbläsare inte gör det.

Läs

Driftstopp är historia.

Sätt upp din första övervakning på under en minut, eller ta en titt i livedemon först.

14 dagar gratis · Sedan gratis för 5 övervakningar · Inget kreditkort