Health check -päätepiste on URL-osoite, yleensä /health, joka kertoo valvontapalvelulle tai kuormantasaajalle, pystyykö sovelluksesi palvelemaan pyyntöjä. Se ajaa muutaman nopean tarkistuksen asioille, joista sovellus on riippuvainen, kuten tietokannalle, välimuistille ja vapaalle levytilalle, ja vastaa HTTP 200 ja {”status”:”ok”}, kun kaikki toimii, tai HTTP 503 ja epäonnistuneen tarkistuksen nimi, kun jokin ei toimi. Pidä se nopeana, kevyenä, välimuistin ulkopuolella ja vapaana salaisuuksista, ja osoita siihen käytettävyyden valvonta, joka tarkistaa vastauksen sisällön eikä pelkkää tilakoodia.
Tämä opas käy läpi livenessin ja readinessin eron, mitä kannattaa tarkistaa, vastauksen muodon, toimivat esimerkit PHP:lle ja Laravelille, Nodelle ja Expressille sekä Pythonille ja Flaskille, ja sen, miten päätepistettä valvotaan, kun se on olemassa.
Miksi etusivu ei ole health check
Useimmat tiimit aloittavat valvomalla etusivua. Se on järkevä ensimmäinen askel, mutta etusivu tarjoillaan usein CDN:stä tai sivuvälimuistista, joten se vastaa 200 silloinkin, kun tietokanta on alhaalla eikä kukaan pääse kirjautumaan tai maksamaan. Erillinen päätepiste ohittaa välimuistin ja testaa riippuvuudet suoraan. Se antaa myös yhden ennustettavan URL-osoitteen, jonka pieni ja vakaa vastaus on helppo tarkistaa.
Liveness ja readiness
Konttialustat, kuten Kubernetes, jakavat terveyden kahteen kysymykseen, ja jako on hyödyllinen kaikkialla:
Liveness: onko prosessi elossa eikä jumissa? Jos ei, käynnistä se uudelleen. Liveness-tarkistuksen ei pidä testata tietokantaa tai muita palveluita. Jos tietokanta kaatuu ja jokainen sovellusinstanssi epäonnistuu liveness-tarkistuksessaan, alusta käynnistää ne kaikki uudelleen, mikä ei korjaa tietokantaa ja hidastaa palautumista.
Readiness: pystyykö tämä instanssi palvelemaan oikeita pyyntöjä juuri nyt? Jos ei, lopeta liikenteen ohjaaminen sille. Riippuvuuksien tarkistukset kuuluvat tänne.
Yleinen ratkaisu on /livez tai /up livenessille, joka palauttaa 200 niin kauan kuin sovellus käynnistyy, ja /health tai /readyz readinessille. Ulkoisessa käytettävyyden valvonnassa readiness-päätepiste on se kiinnostava, koska se vastaa kysymykseen, joka asiakkaillesi on tärkeä: toimiiko sovellus?
Mitä tarkistaa
Tarkista ne riippuvuudet, joita ilman tavallinen pyyntö epäonnistuisi, äläkä mitään muuta:
Tietokanta: aja SELECT 1 samassa yhteysaltaassa, jota sovellus käyttää. Se todistaa, että palvelin on tavoitettavissa ja ottaa kyselyitä vastaan.
Välimuisti tai istuntovarasto: kirjoita ja lue lyhytikäinen avain Redisissä tai Memcachedissa. Jos istunnot ovat siellä, kirjautuminen on siitä riippuvainen.
Levy: tarkista vapaa tila taltiolla, jolle sovellus kirjoittaa latauksia, lokeja tai istuntoja. Epäonnistu, kun se laskee alle marginaalin, esimerkiksi 10 prosentin.
Jono: tarkista, että jonon taustajärjestelmä vastaa, ja halutessasi, ettei vanhin odottava työ ole valitsemaasi rajaa vanhempi. Kasvava jono tarkoittaa, että workerit ovat pysähtyneet.
Ole varovainen kolmansien osapuolten rajapintojen kanssa. Jos päätepisteesi kutsuu maksupalvelua jokaisella tarkistuksella ja palvelu on hidas, health check epäonnistuu, vaikka oma sovelluksesi on kunnossa, ja kuormantasaaja voi poistaa kaikki instanssit kierrosta. Valvo kolmansia osapuolia sen sijaan niiden omilla valvonnoilla, niin hälytys kertoo, kenen ongelmasta on kyse. Uptimecheckin kolmansien osapuolten valvonta seuraa 31 palvelun tilasivuja, kuten Klarnan, Swishin, Shopifyn, Cloudflaren ja OpenAI:n, tai mitä tahansa Statuspage-alustalla olevaa sivua.
Pidä se nopeana ja kevyenä
Health check ajetaan joka minuutti jokaisesta valvontapalvelusta ja kuormantasaajasta ympäri vuorokauden. Siitä ei saa koskaan tulla sitä, mikä ylikuormittaa sovelluksen.
Anna jokaiselle riippuvuustarkistukselle oma lyhyt aikakatkaisu, esimerkiksi sekunti tai kaksi, jotta yksi jumittava palvelu ei jumita koko päätepistettä.
Aja tarkistukset rinnakkain, jos kielesi tekee sen helpoksi.
Käytä triviaaleja kyselyitä. Älä koskaan laske ison taulun rivejä tai aja raporttia.
Jos päätepistettä kutsuu moni tarkistaja, pidä tulos muistissa muutaman sekunnin ajan.
Lähetä Cache-Control: no-store ja jätä polku sivuvälimuistien ja CDN:ien ulkopuolelle, jotta et koskaan näe välimuistista tulevaa ”ok”-vastausta.
Ohita istunnot, evästeet ja todennusmiddlewaret, joita päätepiste ei tarvitse.
Älä vuoda salaisuuksia
Julkinen health-päätepiste näkyy kaikille, jotka arvaavat osoitteen /health. Palauta kunkin tarkistuksen nimi ja tila, ei mitään muuta. Älä sisällytä poikkeusten viestejä, yhteysmerkkijonoja, isäntänimiä, sisäisiä IP-osoitteita, ohjelmistoversioita tai ympäristömuuttujia. Kirjaa yksityiskohtainen virhe sen sijaan palvelimen lokiin. Jos haluat laajemman diagnostiikkanäkymän, laita se erilliseen polkuun todennuksen taakse tai rajaa se sisäverkkoosi.
Vastauksen muoto ja tilakoodit
Pidä JSON pienenä ja vakaana:
{
”status”: ”ok”,
”checks”: {
”database”: ”ok”,
”cache”: ”ok”,
”disk”: ”ok”,
”queue”: ”ok”
}
}
Kun tarkistus epäonnistuu, aseta sen arvoksi ”fail”, aseta ylätason tilaksi ”fail” ja vaihda HTTP-tilakoodi:
200 OK, kun jokainen pakollinen tarkistus menee läpi.
503 Service Unavailable, kun pakollinen tarkistus epäonnistuu. Kuormantasaajat ja valvontapalvelut odottavat juuri tätä koodia tilanteessa ”ei pysty tilapäisesti palvelemaan”.
Halutessasi 200 ja ”status”:”degraded”, kun valinnainen riippuvuus on alhaalla mutta ydin toimii yhä. Päätä etukäteen, mitkä tarkistukset ovat pakollisia.
Älä palauta 200:aa ja runkoa, jossa on ”status”:”fail”. Monet työkalut lukevat vain tilakoodin. Katso HTTP-tilakoodit valvonnassa, miten kutakin koodia yleensä käsitellään.
Esimerkki: PHP ja Laravel
Uusimmissa Laravel-versioissa on valmiina yksinkertainen /up-reitti, joka varmistaa sovelluksen käynnistyvän, ja se toimii hyvin liveness-tarkistuksena. Lisää readinessia varten reitti, joka tarkistaa riippuvuudet:
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’);
});
Rekisteröi se istuntoja käynnistävien middleware-ryhmien ulkopuolelle ja aseta tietokannalle lyhyt yhteyden aikakatkaisu asetuksissa.
Esimerkki: Node ja 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 });
});
Tarkistukset ajetaan rinnakkain, kukin kahden sekunnin rajalla, joten päätepiste vastaa noin kahdessa sekunnissa silloinkin, kun jokin riippuvuus jumittaa.
Esimerkki: Python ja 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”}
Lisää Redis-tarkistus samalla tavalla, jos käytät sitä istuntoihin tai tehtäväjonoon.
Testaa epäonnistumisen polku
Health check, joka ei ole koskaan epäonnistunut, ei ole koskaan tullut testatuksi. Pysäytä staging-ympäristössä tietokanta tai osoita sovellus väärään välimuisti-isäntään ja varmista, että päätepiste palauttaa 503:n aikakatkaisusi sisällä ja nimeää oikean tarkistuksen. Varmista sitten, ettei vastauksessa ole virhetekstiä. Se vie kymmenen minuuttia ja kertoo, että päätepiste on rehellinen silloin, kun sillä on merkitystä.
Päätepisteen valvonta
Päätepiste, jota kukaan ei tarkista ulkopuolelta, on vasta puolet työstä. Osoita siihen HTTP-valvonta verkkosi ulkopuolelta, niin se huomaa myös DNS-, TLS-, palomuuri- ja kuormantasaajaongelmat:
Valvo osoitetta https://lumenanalytics.io/health GET-pyynnöllä joka minuutti.
Odota tilaa 200 ja tarkista, että runko sisältää ”status”:”ok”. Silloin välityspalvelimen virhesivu, joka sattuu palauttamaan 200, epäonnistuu silti tarkistuksessa.
Lähetä oma user agent -otsake, jotta valvontaliikenteen voi helposti suodattaa pois analytiikasta ja lokeista.
Seuraa vasteaikahistoriaa. Health check, joka hiipii 40 ms:stä 900 ms:iin, on varhainen varoitus kuormittuneesta tietokannasta.
Ohjaa hälytys palvelusta vastaaville ihmisille.
Uptimecheckin API-valvonta tukee omia metodeja ja otsakkeita (myös basic authia tai bearer-tokenia) ja tarkistaa odotetun tilan, avainsanat ja JSON-kentät, joten tämä asetus vie minuutin. Pidä sen rinnalla tavallinen käytettävyyden valvonta etusivulla ja tärkeimmällä konversiosivulla. API-valvonnan tarkistuslista käy läpi muut valvomisen arvoiset päätepisteet.
Jonoworkerit ja ajastetut tehtävät toimivat usein web-prosessin ulkopuolella, joten health-päätepiste ei näe, ovatko ne pysähtyneet. Anna niille sen sijaan heartbeatit: worker pingaa URL-osoitetta muutaman minuutin välein, ja puuttuva ping laukaisee hälytyksen.
Health check -päätepisteen tarkistuslista
Erota liveness (prosessi elossa) readinessista (riippuvuudet toimivat).
Tarkista tietokanta, välimuisti, levy ja jono, joita sovellus tarvitsee pyynnön palvelemiseen.
Anna jokaiselle tarkistukselle lyhyt aikakatkaisu ja pidä kyselyt triviaaleina.
Palauta 200, kun kaikki on kunnossa, ja 503, kun pakollinen tarkistus epäonnistuu.
Palauta vain tarkistusten nimet ja tilat. Ei virheitä, versioita tai isäntänimiä.
Poista välimuisti käytöstä polulta.
Valvo sitä joka minuutti ulkopuolelta ja tarkista vastaus.
Uptimecheck valvoo health-päätepisteitä, rajapintoja, palvelimia ja ajastettuja töitä yhdellä tilillä. Aloita 14 päivän ilmainen kokeilu, luottokorttia ei tarvita.