Et website kan være “oppe” og alligevel virke forkert: Serveren svarer med HTTP 200, men siden viser en databasefejl, en tom produktliste eller en hostingudbyders standardside. Et tjek, der kun ser på statuskoden, godkender dem alle. Keyword-overvågning lukker hullet ved også at tjekke indholdet: tekst, der skal stå på siden, som “Add to cart”, eller tekst, der ikke må stå der, som “Fatal error”. Holder tjekket ikke, tæller siden som nede, og du får en alarm.
Sådan kan et website være oppe, men i stykker
Statuskoden sættes af det, der besvarer forespørgslen, og det er ikke altid den del af stakken, der fejlede. Alt dette sker med en 200 eller med en kode, som din overvågning accepterer:
En fejlside fra applikationen. Nogle frameworks, temaer og egne fejlsider viser fejl med en 200 i stedet for en 5xx-kode.
En tom side. En fatal PHP-fejl med fejlvisning slået fra kan give et tomt svar, eller en cache kan gemme og servere en tom side.
Manglende data. Butikken indlæses, men produkt-API’et bag den fejlede, så alle kategorier siger “Ingen produkter fundet”.
Det forkerte website. Efter et skift af hosting eller DNS lander domænet på en standardside som “Welcome to nginx!” eller en parkeringsside.
En vedligeholdelsesside, der aldrig blev slået fra. Et plugin til vedligeholdelsestilstand, der svarer 200 i stedet for 503, ligner et fungerende website for et statustjek.
En hacket eller manipuleret side. En angriber udskifter indhold eller tilføjer spamlinks, og serveren svarer stadig helt normalt.
Google kalder en side, der siger “ikke fundet” eller ikke viser noget, mens den svarer 200, for en soft 404, og den slags sider kan blive fjernet fra søgeresultaterne. Brugerne ser bare et website, der ikke virker.
Sådan fungerer keyword-overvågning
Ved hvert tjek henter overvågningen siden, læser den HTML, serveren returnerer, og søger efter din tekst. Der er to tilstande:
Skal indeholde: Tjekket fejler, når teksten mangler. Brug det som bevis på, at siden virker, fx en knaptekst eller et produktnavn.
Må ikke indeholde: Tjekket fejler, når teksten dukker op. Brug det til kendte fejlmeddelelser.
To detaljer er vigtige. Tjekket læser HTML-kildekoden, ikke den side, du ser i browseren, så tekst, som JavaScript tilføjer bagefter, er der ikke. Og matchet er som regel eksakt, også hvad angår store og små bogstaver. Ordlisteopslaget om keyword-overvågning har den korte definition.
Sådan vælger du et godt keyword
Et godt “skal indeholde”-keyword står kun på siden, når den virker, og er det samme fra dag til dag. Det udelukker priser, datoer, lagerstatus, tællere og alt, der indgår i en A/B-test. Vælg hellere tekst, som applikationen genererer ud fra sine data eller skabeloner, så den forsvinder, når applikationen fejler, frem for tekst i en statisk header, som en cache stadig kan servere.
SideSkal indeholdeHvorfor det virkerProduktsideAdd to cartVises kun, når produktet og kurven virkerKategorisideEt produktnavn, der altid er på lagerMangler, når produktdata ikke kan indlæsesLogin-sideForgot your password?Del af den rigtige loginformular, ikke en fejlsideBlog- eller nyhedssideEn linje fra footeren, som CMS’et generererForsvinder, når CMS’et ikke kan nå sin databaseHealth-endpoint”status”:”ok”Skrives af applikationen, efter den har tjekket sine afhængigheder
For et API eller et health check-endpoint er et JSON-tjek som $.status lig med ok mere præcist end et keyword, fordi det ikke afhænger af mellemrum eller feltrækkefølge.
“Må ikke indeholde”-tjek for fejlmeddelelser
Et negativt tjek fanger fejl, du kan navngive på forhånd. Nyttige tekster, afhængigt af din stak:
Error establishing a database connection på WordPress. Core sender den med en 500, men en egen db-error.php-side gør det måske ikke.
Fatal error eller Parse error på PHP-sites, der viser fejl.
Welcome to nginx! eller sidetitlen på din hostingudbyders standardside, så du fanger et domæne, der peger på den forkerte server.
Spamord, som intet har at gøre på dit website, som en simpel snubletråd for indsprøjtet indhold.
Pas på sider, hvor teksten helt legitimt kan forekomme. Et blogindlæg om databasefejl eller en hjælpeartikel, der citerer en fejlmeddelelse, ville få et “må ikke indeholde”-tjek til at fejle hver gang. Er du i tvivl, er et positivt tjek på tekst, der beviser, at siden virker, det sikreste valg, fordi det også fanger fejl, du ikke havde forudset.
Test dit keyword, før du stoler på det
Tjek, hvad serveren faktisk sender, ikke hvad browseren viser. Fra en terminal:
curl -s –compressed https://example.com/product/blue-mug | grep -c “Add to cart”
Giver det 0, finder overvågningen det heller ikke. De typiske årsager:
JavaScript genererer teksten. Se sidens kildekode (ikke inspektøren) for at se den HTML, serveren returnerer, og vælg tekst, der står i den.
HTML-entiteter. “Terms & Conditions” på skærmen er ofte Terms & Conditions i kildekoden, og typografiske anførselstegn kan også være kodet. Vælg tekst uden specialtegn, eller kopiér den fra kildekoden.
Store bogstaver og mellemrum. En knap, der vises med store bogstaver via CSS, hedder stadig “Add to cart” i HTML’en. Linjeskift inde i teksten ødelægger også et eksakt match.
Overvågningen ser en anden side. Websites, der vælger sprog eller valuta ud fra placering, eller som viser en bot-udfordring til ukendte klienter, kan sende anden HTML til en overvågning, end du får ved dit skrivebord.
Når et keyword ikke er nok
Indholdet afhænger af JavaScript. Single-page apps sender kun lidt HTML. Tjek dem med et flow i en rigtig browser, som kører JavaScript, før den leder efter teksten.
Fejlen ligger et par trin inde. Produktsiden virker, men det gør det ikke at lægge varen i kurven. Et syntetisk tjek i flere trin gennemgår forløbet og tjekker hvert trin.
Siden er meget stor. Overvågning læser som regel kun den første del af et svar. Tjek efter tekst tæt på toppen, eller tjek et mindre endpoint.
Siden er langsom, ikke i stykker. Det er et spørgsmål om svartid; sæt i stedet en grænse for langsomme svar.
Tjeklisten over, hvad du bør overvåge på dit website, foreslår, hvilke sider der fortjener et indholdstjek, og sådan reducerer du falske alarmer dækker resten af finjusteringen.
Keyword-tjek i Uptimecheck
Alle HTTP(S)-overvågninger i Uptimechecks oppetidsovervågning kan have et keyword-tjek ud over de forventede statuskoder:
Indeholder eller indeholder ikke: Ét keyword pr. overvågning, matchet eksakt, også store og små bogstaver, i de første 2 MB af svaret. Har du brug for både et positivt og et negativt tjek på samme side? Tilføj en ekstra overvågning.
JSON- og header-tjek: Op til 10 pr. overvågning, fx $.status lig med ok eller en Content-Type-header, der indeholder json, til API’er og health-endpoints.
Testforespørgsel: Se svaret, og om tjekkene består, før du gemmer overvågningen.
Bekræftet og forklaret: Et fejlet tjek gentages, før en hændelse åbnes, og hændelsen fortæller, hvad der var galt, fx at den forventede tekst ikke stod på siden, eller at siden kom tom tilbage, sammen med starten af svaret.
JavaScript og brugerforløb: Flows tjekker tekst ved hvert trin, og flows i en rigtig browser ser tekst, som JavaScript genererer, med et skærmbillede af det trin, der fejlede.
Tjek kører så ofte som hvert minut fra Stockholm, London og New York, så et website, der skifter sprog efter placering, viser Uptimecheck den version, det serverer til Sverige, Storbritannien eller USA; vælg et keyword, der er det samme i alle versioner, eller send de headers, der vælger sprog. Se sådan tilføjer du din første overvågning for at komme i gang, og hvis en overvågning melder nede, mens websitet virker for dig, så læs hvorfor en overvågning kan være nede, når websitet virker.
Lad “oppe” betyde, at det virker. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.