En webbplats kan vara ”uppe” och ändå trasig: servern svarar med HTTP 200, men sidan visar ett databasfel, en tom produktlista eller webbhotellets standardsida. En kontroll som bara tittar på statuskoden godkänner alla de fallen. Nyckelordsövervakning täpper till luckan genom att också kontrollera innehållet: text som måste finnas på sidan, till exempel ”Lägg i varukorgen”, eller text som inte får finnas där, till exempel ”Fatal error”. Håller inte kontrollen räknas sidan som nere och du får ett larm.
Så kan en sajt vara uppe men trasig
Statuskoden sätts av det som svarar på förfrågan, och det är inte alltid den del av stacken som gick sönder. Allt det här händer med en 200, eller med en kod som din övervakning godkänner:
En felsida från applikationen. Vissa ramverk, teman och egna felsidor visar fel med en 200 i stället för en 5xx-kod.
En tom sida. Ett fatalt PHP-fel med felvisning avstängd kan ge ett tomt svar, och en cache kan spara och servera en tom sida.
Data som saknas. Butiken laddas, men produkt-API:t bakom den har fallerat, så varje kategori säger ”Inga produkter hittades”.
Fel sajt. Efter ett byte av webbhotell eller DNS hamnar domänen på en standardsida som ”Welcome to nginx!” eller en parkeringssida.
En kvarglömd underhållssida. Ett underhållsplugin som svarar 200 i stället för 503 ser ut som en fungerande sajt för en statuskontroll.
En vandaliserad eller manipulerad sida. En angripare byter ut innehåll eller lägger in spamlänkar, och servern svarar ändå som vanligt.
Google kallar en sida som säger ”hittades inte” eller inte visar något alls men svarar 200 för en soft 404, och sådana sidor kan försvinna ur sökresultaten. Användarna ser bara en trasig sajt.
Så fungerar nyckelordsövervakning
Vid varje kontroll hämtar övervakningen sidan, läser den HTML som servern skickar tillbaka och söker efter din text i den. Det finns två lägen:
Måste innehålla: kontrollen fallerar när texten saknas. Använd det för något som bevisar att sidan fungerar, till exempel en knapptext eller ett produktnamn.
Får inte innehålla: kontrollen fallerar när texten dyker upp. Använd det för kända felmeddelanden.
Två detaljer spelar roll. Kontrollen läser HTML-källan, inte sidan du ser i webbläsaren, så text som JavaScript lägger till i efterhand finns inte där. Och matchningen är oftast exakt, inklusive versaler och gemener. Ordlistans post om nyckelordsövervakning har den korta definitionen.
Så väljer du ett bra nyckelord
Ett bra ”måste innehålla”-nyckelord syns bara när sidan fungerar och är detsamma från dag till dag. Det utesluter priser, datum, lagersaldon, räknare och allt som ingår i ett A/B-test. Välj hellre text som applikationen genererar från sin data eller sina mallar, så att den försvinner när applikationen fallerar, än text i ett statiskt sidhuvud som en cache fortfarande kan servera.
SidaMåste innehållaVarför det fungerarProduktsidaLägg i varukorgenVisas bara när produkten och varukorgen fungerarKategorisidaEtt produktnamn som alltid finns i lagerSaknas när produktdatan inte laddasInloggningssidaGlömt ditt lösenord?Hör till det riktiga inloggningsformuläret, inte till en felsidaBlogg- eller nyhetssidaEn rad från sidfoten som CMS:et genererarFörsvinner när CMS:et inte når sin databasHealth endpoint”status”:”ok”Skrivs av applikationen efter att den har kontrollerat sina beroenden
För ett API eller en health check endpoint är en JSON-kontroll, till exempel att $.status är lika med ok, mer exakt än ett nyckelord, eftersom den inte beror på mellanslag eller fältens ordning.
”Får inte innehålla”-kontroller för felmeddelanden
En negativ kontroll fångar fel som du kan namnge i förväg. Användbara strängar, beroende på din stack:
Error establishing a database connection på WordPress. Core skickar det med en 500, men en egen db-error.php-sida gör det kanske inte.
Fatal error eller Parse error på PHP-sajter som visar fel.
Welcome to nginx! eller ditt webbhotells standardrubrik, för att fånga en domän som pekar mot fel server.
Spamord som inte har något på din sajt att göra, som en enkel snubbeltråd för inplanterat innehåll.
Se upp med sidor där strängen kan förekomma av helt legitima skäl. Ett blogginlägg om databasfel, eller en hjälpartikel som citerar ett felmeddelande, skulle fallera på en ”får inte innehålla”-kontroll varje gång. Om du är osäker är en positiv kontroll på text som bevisar att sidan fungerar det säkrare valet, eftersom den fångar fel du inte hade tänkt på.
Testa nyckelordet innan du litar på det
Kontrollera vad servern faktiskt skickar, inte vad webbläsaren visar. Från en terminal:
curl -s –compressed https://example.com/product/blue-mug | grep -c ”Add to cart”
Blir resultatet 0 hittar övervakningen inte texten heller. De vanliga orsakerna:
JavaScript genererar texten. Visa sidans källkod (inte inspektören) för att se den HTML som servern skickar, och välj text som finns i den.
HTML-entiteter. ”Terms & Conditions” på skärmen är ofta Terms & Conditions i källkoden, och typografiska citattecken kan också vara kodade. Välj text utan specialtecken, eller kopiera den från källkoden.
Versaler och mellanslag. En knapp som visas med versaler via CSS är fortfarande ”Lägg i varukorgen” i HTML-koden. Radbrytningar inuti texten bryter också en exakt matchning.
Övervakningen ser en annan sida. Sajter som väljer språk eller valuta efter plats, eller visar en botkontroll för okända klienter, kan skicka annan HTML till övervakningen än den du får vid skrivbordet.
När ett nyckelord inte räcker
Innehållet bygger på JavaScript. Single page-appar skickar lite HTML. Kontrollera dem med ett flöde i en riktig webbläsare, som kör JavaScript innan det letar efter texten.
Felet ligger några steg in. Produktsidan fungerar, men att lägga i varukorgen gör det inte. En syntetisk kontroll i flera steg går igenom hela flödet och kontrollerar varje steg.
Sidan är mycket stor. Övervakningstjänster läser oftast bara början av ett svar. Leta efter text nära toppen, eller kontrollera en mindre endpoint.
Sidan är långsam, inte trasig. Det är en fråga om svarstid; sätt en gräns för långsamma svar i stället.
Checklistan över vad du bör övervaka på din webbplats tipsar om vilka sidor som förtjänar en innehållskontroll, och så minskar du falsklarm tar upp resten av finjusteringen.
Nyckelordskontroller i Uptimecheck
Varje HTTP(S)-monitor i Uptimechecks upptidsövervakning kan ha en nyckelordskontroll utöver de förväntade statuskoderna:
Innehåller eller innehåller inte: ett nyckelord per monitor, exakt matchning inklusive versaler och gemener, i svarets första 2 MB. Behöver du både en positiv och en negativ kontroll på samma sida? Lägg till en andra monitor.
JSON- och header-kontroller: upp till 10 per monitor, till exempel att $.status är lika med ok eller att en Content-Type-header innehåller json, för API:er och health endpoints.
Testförfrågan: se svaret och om kontrollerna går igenom innan du sparar monitorn.
Bekräftat och förklarat: en misslyckad kontroll upprepas innan en incident öppnas, och incidenten berättar vad som var fel, till exempel att den förväntade texten inte fanns på sidan eller att sidan kom tillbaka tom, tillsammans med början av svaret.
JavaScript och användarflöden: flöden kontrollerar text i varje steg, och flöden i en riktig webbläsare ser text som JavaScript genererar, med en skärmdump av steget som fallerade.
Kontrollerna körs så ofta som varje minut från Stockholm, London och New York, så en sajt som byter språk efter plats visar Uptimecheck den version den serverar till Sverige, Storbritannien eller USA; välj ett nyckelord som är detsamma i alla versioner, eller skicka de headers som väljer språk. För att komma igång, se så lägger du till din första monitor, och om en monitor rapporterar nere medan sajten fungerar för dig, varför en monitor kan vara nere när sajten fungerar.
Låt ”uppe” betyda att sajten fungerar. Testa Uptimecheck gratis i 14 dagar, inget betalkort krävs.