En health check-endpoint är en URL, oftast /health, som talar om för en monitor eller lastbalanserare om din applikation kan hantera förfrågningar. Den kör några snabba kontroller mot det som appen är beroende av, som databasen, cachen och ledigt diskutrymme, och svarar med HTTP 200 och {”status”:”ok”} när allt fungerar, eller HTTP 503 och namnet på den kontroll som fallerar när något inte gör det. Håll den snabb, billig, ocachad och fri från hemligheter, och peka sedan en upptidsmonitor mot den som validerar svaret, inte bara statuskoden.
Den här guiden går igenom skillnaden mellan liveness och readiness, vad du ska kontrollera, svarsformatet, fungerande exempel för PHP med Laravel, Node med Express och Python med Flask, och hur du övervakar endpointen när den väl finns.
Varför startsidan inte är en health check
De flesta team börjar med att övervaka startsidan. Det är ett rimligt första steg, men startsidan serveras ofta från ett CDN eller en sidcache, så den fortsätter att svara 200 medan databasen ligger nere och ingen kan logga in eller slutföra ett köp. En dedikerad endpoint går förbi cachen och testar beroendena direkt. Den ger dig också en förutsägbar URL med ett litet, stabilt svar som är lätt att validera.
Liveness och readiness
Containerplattformar som Kubernetes delar upp hälsa i två frågor, och den uppdelningen är användbar överallt:
Liveness: lever processen och har den inte hängt sig? Om inte, starta om den. En liveness-kontroll ska inte testa databasen eller andra tjänster. Om databasen går ned och varje appinstans misslyckas med sin liveness-kontroll startar plattformen om alla, vilket inte lagar databasen och gör återhämtningen långsammare.
Readiness: kan den här instansen hantera riktiga förfrågningar just nu? Om inte, sluta skicka trafik till den. Det är här kontrollerna av beroenden hör hemma.
Ett vanligt upplägg är /livez eller /up för liveness, som svarar 200 så länge appen startar, och /health eller /readyz för readiness. För extern upptidsövervakning är det readiness-endpointen som är intressant, eftersom den besvarar den fråga dina kunder bryr sig om: fungerar appen?
Vad du ska kontrollera
Kontrollera de beroenden som en vanlig förfrågan inte klarar sig utan, och inget mer:
Databas: kör SELECT 1 på samma anslutningspool som appen använder. Det visar att servern går att nå och tar emot frågor.
Cache eller sessionslagring: skriv och läs en kortlivad nyckel i Redis eller Memcached. Om sessionerna ligger där är inloggningen beroende av den.
Disk: kontrollera ledigt utrymme på volymen som appen skriver till, för uppladdningar, loggar eller sessioner. Låt kontrollen fallera när det sjunker under en marginal, till exempel 10 procent.
Kö: kontrollera att köns backend svarar, och eventuellt att det äldsta väntande jobbet inte är äldre än en gräns du väljer. En växande kö betyder att workers har stannat.
Var försiktig med tredjeparts-API:er. Om din endpoint anropar en betalleverantör vid varje kontroll och leverantören är långsam fallerar din health check trots att din egen app fungerar, och en lastbalanserare kan ta varenda instans ur rotation. Övervaka i stället tredjepartstjänster med egna monitorer, så att ett larm visar vems problemet är. Uptimechecks tredjepartsövervakning följer statussidorna för 31 tjänster som Klarna, Swish, Shopify, Cloudflare och OpenAI, eller valfri sida som drivs av Statuspage.
Håll den snabb och billig
En health check körs varje minut från varje monitor och lastbalanserare, dygnet runt. Den får aldrig bli det som överbelastar appen.
Ge varje kontroll av ett beroende en egen kort timeout, till exempel en eller två sekunder, så att en tjänst som hänger sig inte får hela endpointen att hänga.
Kör kontrollerna parallellt där ditt språk gör det enkelt.
Använd triviala frågor. Räkna aldrig rader i en stor tabell och kör aldrig en rapport.
Om många kontrollanter anropar endpointen kan du cacha resultatet i minnet några sekunder.
Skicka Cache-Control: no-store och undanta sökvägen från sidcachar och CDN:er, så att du aldrig får ett cachat ”ok”.
Hoppa över sessioner, cookies och autentiserings-middleware som endpointen inte behöver.
Läck inga hemligheter
En publik health-endpoint syns för alla som gissar /health. Returnera namn och status för varje kontroll och inget annat. Ta inte med felmeddelanden från undantag, anslutningssträngar, värdnamn, interna IP-adresser, programversioner eller miljövariabler. Logga det detaljerade felet på servern i stället. Om du vill ha en mer detaljerad diagnostikvy kan du lägga den på en separat sökväg bakom autentisering eller begränsa den till ditt interna nätverk.
Svarets format och statuskoder
Håll JSON-svaret litet och stabilt:
{
”status”: ”ok”,
”checks”: {
”database”: ”ok”,
”cache”: ”ok”,
”disk”: ”ok”,
”queue”: ”ok”
}
}
När en kontroll fallerar sätter du dess värde till ”fail”, sätter statusen på toppnivå till ”fail” och ändrar HTTP-statuskoden:
200 OK när alla obligatoriska kontroller godkänns.
503 Service Unavailable när en obligatorisk kontroll fallerar. Det är koden som lastbalanserare och monitorer förväntar sig för ”kan tillfälligt inte hantera förfrågningar”.
Eventuellt 200 med ”status”:”degraded” för ett valfritt beroende som ligger nere medan kärnan fortfarande fungerar. Bestäm i förväg vilka kontroller som är obligatoriska.
Undvik att svara 200 med ”status”:”fail” i svaret. Många verktyg läser bara statuskoden. Läs HTTP-statuskoder för övervakning för hur varje kod brukar hanteras.
Exempel: PHP och Laravel
Nyare versioner av Laravel levereras med en enkel /up-route som bekräftar att appen startar, vilket fungerar bra som liveness-kontroll. För readiness lägger du till en route som kontrollerar beroendena:
use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Route;
Route::get(’/health’, function () {
$checks = [];
try {
DB::select(’SELECT 1’);
$checks[’database’] = ’ok’;
} catch (\Throwable $e) {
report($e);
$checks[’database’] = ’fail’;
}
try {
Cache::put(’health-check’, ’ok’, 10);
$checks[’cache’] = Cache::get(’health-check’) === ’ok’ ? ’ok’ : ’fail’;
} catch (\Throwable $e) {
report($e);
$checks[’cache’] = ’fail’;
}
$path = storage_path();
$checks[’disk’] = disk_free_space($path) / disk_total_space($path) > 0.10 ? ’ok’ : ’fail’;
$healthy = ! in_array(’fail’, $checks, true);
return response()
->json([’status’ => $healthy ? ’ok’ : ’fail’, ’checks’ => $checks], $healthy ? 200 : 503)
->header(’Cache-Control’, ’no-store’);
});
Registrera den utanför middleware-grupper som startar sessioner, och sätt en kort anslutnings-timeout för databasen i din konfiguration.
Exempel: Node och Express
const withTimeout = (promise, ms) =>
Promise.race([
promise,
new Promise((_, reject) => setTimeout(() => reject(new Error(’timeout’)), ms)),
]);
const check = (fn) => withTimeout(fn(), 2000).then(() => ’ok’, () => ’fail’);
app.get(’/health’, async (req, res) => {
const [database, cache] = await Promise.all([
check(() => pool.query(’SELECT 1’)),
check(() => redis.ping()),
]);
const checks = { database, cache };
const healthy = Object.values(checks).every((v) => v === ’ok’);
res
.set(’Cache-Control’, ’no-store’)
.status(healthy ? 200 : 503)
.json({ status: healthy ? ’ok’ : ’fail’, checks });
});
Kontrollerna körs parallellt, var och en med en gräns på två sekunder, så endpointen svarar inom ungefär två sekunder även när ett beroende hänger sig.
Exempel: Python och Flask
import shutil
from flask import jsonify
from sqlalchemy import text
@app.get(”/health”)
def health():
checks = {}
try:
db.session.execute(text(”SELECT 1”))
checks[”database”] = ”ok”
except Exception:
app.logger.exception(”health: database”)
checks[”database”] = ”fail”
usage = shutil.disk_usage(”/”)
checks[”disk”] = ”ok” if usage.free / usage.total > 0.10 else ”fail”
healthy = all(value == ”ok” for value in checks.values())
body = {”status”: ”ok” if healthy else ”fail”, ”checks”: checks}
return jsonify(body), 200 if healthy else 503, {”Cache-Control”: ”no-store”}
Lägg till en Redis-kontroll på samma sätt om du använder Redis för sessioner eller en jobbkö.
Testa felvägen
En health check som aldrig har fallerat har aldrig testats. Stoppa databasen i staging, eller peka appen mot fel cachevärd, och bekräfta att endpointen svarar 503 inom din timeout och pekar ut rätt kontroll. Bekräfta sedan att svaret inte innehåller någon feltext. Det tar tio minuter och visar att endpointen säger sanningen när det gäller.
Övervaka endpointen
En endpoint som ingen kontrollerar utifrån är bara halva jobbet. Peka en HTTP-monitor mot den från utsidan av ditt nätverk, så att den även fångar problem med DNS, TLS, brandväggar och lastbalanserare:
Övervaka https://lumenanalytics.io/health med GET varje minut.
Förvänta dig status 200 och validera att svaret innehåller ”status”:”ok”. En felsida från en proxy som råkar svara 200 fallerar då ändå kontrollen.
Skicka en egen user agent-header, så att övervakningstrafiken är lätt att filtrera bort ur analysverktyg och loggar.
Håll koll på historiken för svarstider. En health check som kryper från 40 ms till 900 ms är en tidig varning om en databas som kämpar.
Skicka larmet till dem som äger tjänsten.
API-övervakning i Uptimecheck stöder egna metoder och headers (inklusive basic auth eller en bearer-token) och validerar förväntad status, nyckelord och JSON-fält, så det här tar en minut att sätta upp. Ha kvar en vanlig upptidsmonitor på startsidan och den viktigaste konverteringssidan vid sidan om. Checklistan för API-övervakning går igenom de andra endpoints som är värda att bevaka.
Kö-workers och schemalagda jobb körs ofta utanför webbprocessen, så en health-endpoint kan inte se om de har stannat. Ge dem heartbeats i stället: workern pingar en URL med några minuters mellanrum, och ett uteblivet ping utlöser larmet.
Checklista för health check-endpoints
Skilj liveness (processen lever) från readiness (beroendena fungerar).
Kontrollera databasen, cachen, disken och kön som appen behöver för att hantera en förfrågan.
Ge varje kontroll en kort timeout och håll frågorna triviala.
Svara 200 när allt är friskt och 503 när en obligatorisk kontroll fallerar.
Returnera bara kontrollernas namn och status. Inga fel, versioner eller värdnamn.
Stäng av cachning för sökvägen.
Övervaka den varje minut utifrån, med validering av svaret.
Uptimecheck övervakar health-endpoints, API:er, servrar och schemalagda jobb i ett och samma konto. Starta en kostnadsfri provperiod på 14 dagar, inget kreditkort krävs.