För att minska falsklarm i upptidsövervakningen: bekräfta varje fel med en andra kontroll innan larmet går, sätt timeouts som matchar hur webbplatsen normalt beter sig, kontrollera att du får förväntad statuskod och förväntat innehåll från en URL som verkligen speglar tjänsten, skicka varje monitors larm bara till dem som kan agera på dem, lägg planerat arbete i ett underhållsfönster och meddela det i förväg, och gå igenom de mest larmande monitorerna varje månad. De flesta falsklarm kommer från en handfull monitorer där en av de här inställningarna är fel, så de brukar gå snabbt att åtgärda.
Den här guiden förklarar varför falsklarm är farliga, var de kommer ifrån och vad du ska ändra, inställning för inställning.
Varför falsklarm är värre än de verkar
Ett enstaka falsklarm är ett litet irritationsmoment. En jämn ström av dem leder till larmtrötthet: folk tystar kanalen, filtrerar mejlen till en mapp eller kastar en blick på mobilen och somnar om. Övervakningen rullar fortfarande, men ingen lyssnar. Det första riktiga avbrottet efter det upptäcks på det gamla sättet, av en kund.
Det finns också en tystare kostnad. Varje falsklarm drar ut någon ur sitt arbete för att kontrollera en webbplats som fungerar. Under en månad blir det timmar av tappat fokus och ett team som litar mindre på sina verktyg. Målet är inte färre larm för sakens skull. Det är larm som är värda att läsa, varenda gång.
Var falsklarm kommer ifrån
Tillfälliga nätverksstörningar mellan en kontrollplats och din server: ett tappat paket, en långsam väg, en kort DNS-hicka.
För snäva timeouts för en sida som ibland är långsam men fungerar.
Fel förväntan: en kontroll som vill ha status 200 från en URL som omdirigerar, eller som letar efter en text som ändrades vid en omdesign.
Fel URL: en sida bakom rate limiting, bot-skydd eller inloggning, eller en stagingserver som stängs av på natten.
Planerat arbete: driftsättningar och underhåll som tar ner en webbplats med flit.
Dålig routing: ett larm som tekniskt sett är korrekt men skickas till någon som inte kan göra något åt det. För den personen är det brus.
Bekräfta varje fel med en andra kontroll
Den enskilt mest effektiva åtgärden. När en kontroll misslyckas, kontrollera igen innan något annat händer. Ett tappat paket eller en kort hicka klarar den andra kontrollen; ett riktigt avbrott misslyckas igen. Bara ett bekräftat fel öppnar en incident. Det tar bort de flesta tillfälliga störningar utan att fördröja riktiga larm med mer än några sekunder.
Tjänster som kontrollerar från flera platser kan köra den andra kontrollen från en annan plats, vilket också säger något användbart när platserna är oense under en längre tid. Om din webbplats misslyckas från en kontinent och fungerar från en annan ligger problemet troligen i routingen eller i en CDN-nod snarare än i din server. Uptimecheck kontrollerar från Stockholm, London och New York och bekräftar varje fel från en andra plats innan en incident öppnas, så att en enstaka störning inte väcker någon; sidan om upptidsövervakning förklarar flödet. Grunderna i hur kontroller blir larm hittar du i vad upptidsövervakning är.
Sätt timeouts som matchar verkligheten
En timeout är den tid en kontroll väntar innan den bedömer att webbplatsen ligger nere. Sätter du den för snävt blir normal variation ett avbrott. Sätter du den för generöst räknas en webbplats som tar 40 sekunder på sig att svara som uppe.
Titta på historiken över svarstider under några veckor. Notera det normala intervallet och de långsammaste normala svaren.
Sätt timeouten med god marginal över det långsammaste normala svaret, men under den punkt där besökarna ger upp.
Behandla långsamhet som en egen signal. En sida som har gått från 300 ms till 4 sekunder behöver åtgärdas, men under arbetstid, inte som ett avbrottslarm mitt i natten.
Om en sida ofta ligger nära timeouten är det inte monitorn som är problemet. Det är sidan.
Förvänta dig rätt statuskod och rätt innehåll
Många falsklarm kommer från kontroller som förväntar sig fel sak:
Omdirigeringar. Att övervaka http://northwind.shop när webbplatsen omdirigerar till https://www.northwind.shop/ lägger till ett steg som kan fallera på egen hand. Övervaka den slutliga URL:en direkt, och om du vill verifiera omdirigeringen, ge den en egen monitor.
Sköra innehållskontroller. Att validera en marknadsföringsrubrik slutar fungera vid nästa textändring. Välj något stabilt som bara syns när sidan fungerar, till exempel företagsnamnet i sidfoten, ett element i produktrutnätet eller ”status”:”ok” från en health endpoint.
För brett. Att godta vilken 2xx- eller 3xx-kod som helst döljer riktiga fel. Att bara godta 200 från en endpoint som med rätta svarar 204 skapar falska. Matcha det som endpointen faktiskt returnerar.
Innehållsvalidering minskar både falsklarm och missade larm på samma gång: en felsida från en proxy som svarar 200 underkänns, och en kosmetisk ändring gör det inte.
Övervaka rätt URL
Vissa URL:er är till sin natur dåliga att övervaka. Sidor bakom bot-skydd eller en brandvägg för webbapplikationer (WAF) kan då och då blockera övervakningstrafik, vilket ser ut som nertid. Sidor med hård rate limiting kan svara 429 efter en serie kontroller. Lösenordsskyddade sidor svarar med en omdirigering till inloggningsformuläret. Och startsidan är ofta så hårt cachad att den är uppe medan allt bakom den ligger nere.
En dedikerad health endpoint undviker allt det här. Den är inte cachad, billig att leverera, svarar med en förutsägbar body och misslyckas bara när ett beroende misslyckas. Se hur du bygger en health check endpoint. Om du behöver övervaka en skyddad sida, släpp igenom övervakningstjänsten och skicka en igenkännbar user agent-header så att trafiken är lätt att identifiera.
Styr larmen per monitor
Ett larm är bara användbart för någon som kan agera på det. Att skicka varje monitor till alla gör riktiga larm till brus för de flesta som får dem. Styr i stället efter påverkan och ansvar:
Monitor (exempel)KanalVemKassa och betalningscallbackPushnotis och teamchattDen som har jourHealth endpoint för det publika API:etTeamchatt och webhookPlattformsteametMarknadssajt och bloggE-postWebbteamet, under arbetstidStaging och interna verktygSeparat chattkanalDen som äger dem
I Uptimecheck väljer du larmkanaler per monitor. Larmen går till e-post, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks och pushnotiser i mobilen, på alla planer. Se larm och notiser. Med jourscheman når pushlarmen den som har jour just nu, och eskalering kan hålla tillbaka en kanal i 5 till 60 minuter och larma bara om ingen har bekräftat incidenten. Byråer kan gruppera monitorer per kundprojekt och välja kanaler för varje monitor, så att varje kunds larm når teamet som tar hand om kunden.
Hantera planerat underhåll
Planerad nertid ska aldrig väcka någon. Inför en migrering eller en lång driftsättning, lägg de monitorer som påverkas i ett underhållsfönster. Saknar ditt verktyg det, pausa dem eller flytta deras larm till en tyst kanal under tiden, och gör återstarten av övervakningen till en punkt på checklistan för driftsättningen.
I Uptimecheck kan underhållsfönster vara engångs eller återkommande. Under ett fönster blir det inga larm, inga incidenter och ingen förlorad upptid, och fönstret visas på din statussida och kan mejlas till prenumeranterna.
Berätta för kunderna också. En notis på din statussida före arbetet, med tidsfönstret och vad som påverkas, gör att ingen blir överraskad och att supporten slipper ärenden om något ni har planerat. Driftsättningar som ger några sekunders fel varje gång är ett separat problem: lös dem med rullande driftsättningar eller driftsättningar utan nertid i stället för att ignorera larmen.
Använd meddelanden om återställning
Ett meddelande om återställning är larmet som säger att det är över, med den totala nertiden. Det minskar inte antalet larm, men det minskar arbetet som varje larm orsakar. Utan det måste någon fortsätta kontrollera om ett kort avbrott har gått över. Med det blir en blipp på två minuter mitt i natten ett larm och en friklarering som kan vänta till morgonen. Uptimecheck skickar ett meddelande om återställning efter varje incident.
Gå igenom dina mest larmande monitorer
En gång i månaden, lista de monitorer som larmade mest och ställ de här frågorna om var och en:
Var varje larm äkta? Om inte, vilken inställning orsakade det: plats, timeout, förväntan eller URL?
Agerade någon? Om ingen någonsin gör det, ändra routingen eller ta bort monitorn.
Är själva webbplatsen instabil? Täta, korta, verkliga avbrott är inte falsklarm; de pekar på en överbelastad server eller ett svagt beroende, och larmtrösklar för servrar kan hjälpa dig att hitta orsaken.
Behövs monitorn fortfarande? Nedlagda webbplatser och gamla stagingservrar är en vanlig källa till brus.
Rapporter per e-post varje vecka och månad som sammanfattar upptid och incidenter gör genomgången snabb.
Checklista mot falsklarm
Bekräfta varje fel med en andra kontroll innan larmet går.
Sätt timeouts utifrån verklig historik över svarstider.
Övervaka slutliga URL:er, inte omdirigeringar, och validera stabilt innehåll.
Välj health endpoints framför cachade eller skyddade sidor.
Skicka varje monitors larm till dem som kan agera på dem.
Lägg planerat arbete i ett underhållsfönster och meddela det i förväg.
Gå igenom de mest larmande monitorerna varje månad.
Sammanfattning
Falsklarm är ett konfigurationsproblem, och de flesta går att åtgärda på en eftermiddag. Bekräfta varje fel med en andra kontroll, kontrollera rätt URL för rätt sak, skicka larm bara dit där någon kan agera och fortsätt att se över upplägget. Belöningen är ett team som läser varje larm, eftersom varje larm spelar roll.
Uptimecheck kontrollerar varje fel en gång till innan det larmar och låter dig styra larmen per monitor. Starta en kostnadsfri provperiod på 14 dagar, inget kreditkort krävs.