Health checks: onderscheid een open poort van een gezonde applicatie

De load balancer markeert de backend “gezond”: poort 443 reageert. Ondertussen weigert PostgreSQL verbindingen: elk API-verzoek retourneert 503. Gebruikers zien een storing; de hostbewaking wordt groen weergegeven. Het team verspilt twintig minuten met zoeken naar 'netwerk', ook al heeft de statuscheck de basis nooit getest.

Dit scenario herhaalt zich elke week op ogenschijnlijk goed geconfigureerde stacks: geldig TLS-certificaat, actief webproces, passerende TCP-test. Het probleem ligt niet bij de host, maar bij de vraag die door de probe wordt gesteld.

Een applicatie-gezondheidscontrole beantwoordt een specifieke vraag: kan deze instantie nu een representatief verzoek verwerken? Niet: luistert iemand op een poort? Het onderscheid verandert alles wanneer een kritieke afhankelijkheid wegvalt zonder dat de webserver stopt.

TCP, lichtgewicht HTTP en diepgaande verificatie

Teams aarzelen vaak tussen drie niveaus van onderzoek. Iedereen heeft zijn plek, maar alleen het derde niveau beschermt de eindgebruiker.

/health/live dient liveness (Kubernetes): geen database — dit vermijdt een lus van herstarts wanneer Postgres niet beschikbaar is, maar de applicatie zelf nog steeds actief is. /health/ready dient voor readiness: omvat alleen kritieke afhankelijkheden — basis, cache, wachtrij indien essentieel.

Een controle die slaagt als de basis dood is, stuurt het verkeer naar een sinkhole. Dit is het meest frustrerende geval: alles is groen aan de infrastructuurkant, alles is rood aan de klantkant.

Ontwerp snelle en betrouwbare controles

Een goed gezondheidseindpunt respecteert vier regels. Ten eerste een time-out van minder dan één of twee seconden, uitgelijnd tussen de load balancer en de kubelet: een langzame controle blokkeert de verwijdering van verkeer wanneer u dit het meest nodig heeft.

Dan geen bijwerkingen: geen creatie van testorders in productie, geen verzending van e-mails, geen schrijven naar de database. De sonde leest de status; ze wijzigt het niet.

Ten derde een stabiel antwoord in JSON: { "status": "ok", "checks": { "db": "ok" } } — parseerbaar door monitoring en leesbaar door een mens bij een incident.

Tenslotte een cache van twee tot vijf seconden in het geheugen als de tests agressief zijn. Vermijd het hergebruiken van een zware pagina (WordPress-administratie, compleet dashboard) als probe: je verspilt processor bij elke poll.

Hostingdistributeur, Kubernetes en gedeeld

OVHcloud, Hetzner en Scaleway bieden splitters met configureerbare HTTP-test. Stel de controle in op /health/ready, een redelijk interval (vijf tot tien seconden) en opeenvolgende drempels voor mislukken en slagen om permanente failovers te voorkomen.

Breng op Kubernetes de testpaden op één lijn met de externe coördinator: inconsistente dubbele controles veroorzaken permanente wisselingen tussen gezond en ongezond.

Bij het delen zonder aangepaste test kunt u een externe URL (UptimeRobot, enz.) met waarschuwing bewaken. Het is een complement en geen vervanging voor een interne test die afhankelijkheden test.

Beveiliging en informatielekken

Een openbare /health-lijst met versies, omgeving en clusternaam is een uitnodiging. Tarieflimiet, intern netwerk, IP-witte lijst. In gevoelige infrastructuur, mTLS-authenticatie tussen coördinator en applicatie.

Een aanvaller die /health onderzoekt, ontdekt soms de status van uw database, de versie van uw raamwerk of de interne topologie; allemaal nuttige informatie voor het richten van een aanval.

De top: groen voor monitoring, rood voor de klant

De sonde moet zich houden aan de minimale gebruikersreis – niet aan de transportlaag.

Beslis en ga vooruit zonder blinde vlek

Implementeer afzonderlijke live en kant-en-klare eindpunten, elk met een duidelijke verantwoordelijkheid: de eerste beslist of het proces opnieuw moet worden opgestart, de tweede of de instantie verkeer kan ontvangen. Neem alleen kritieke afhankelijkheden op in Ready – niet de hele bedrijfsstack. Beveilig het eindpunt op het interne netwerk of op de witte lijst van IP-adressen. Lijn de load balancer en Kubernetes uit op dezelfde paden en drempels. Valideren in pre-productie: snijd de basis → het verkeer moet worden verwijderd zonder een massale herstart van de pods. Vergelijk de aanbiedingen van dispatchers via de overzicht en de vergelijker.

Veelgestelde vragen

Waarom is een TCP-controle op poort 80 zelden genoeg?

Een TCP-controle verifieert alleen dat een socket open is, niet dat de applicatie correct reageert, noch dat de database bereikbaar is. De poort kan open zijn terwijl PHP-FPM vol is, de applicatie 500 fouten retourneert of PostgreSQL verbindingen weigert. Bij een incident verspilt u kostbare tijd aan het diagnosticeren van “netwerk”, ook al is het probleem applicatiegerelateerd.

Wat moet een /health/ready eindpunt bevatten?

Lichtgewicht controles van kritieke afhankelijkheden: databaseping, Redis PING, wachtrij indien nodig – zonder alle bedrijfslogica te starten. De time-out moet kort blijven (één tot twee seconden). In geval van een storing wordt de instantie uit het verkeer verwijderd; het wordt niet noodzakelijkerwijs opnieuw opgestart, waardoor een database-incident wordt vermeden.

Publieke of interne gezondheidscontrole?

Geef de voorkeur aan een intern eindpunt: privénetwerk, IP-witte lijst of wederzijdse authenticatie. Een niet-geauthenticeerde publieke /gezondheid kan een zoektocht worden naar een aanvaller of een informatielek (softwareversie, databasestatus). Als een openbaar eindpunt onvermijdelijk is, beperk dan de blootgestelde informatie en pas een strikte snelheidslimiet toe.

Hoe voorkom je dat de statuscheck de app overbelast?

Cache het resultaat een paar seconden in het geheugen, beperk parallelle controles en gebruik een speciaal eindpunt zonder uitgebreide logbestanden. Bij gedeeld vermenigvuldigt een coördinator die elke seconde onderzoekt de belasting: configureer een interval van vijf tot tien seconden en een lichtgewicht eindpunt.

Gezond betekent “klaar om te serveren” – niet “poort reageert op telnet”.