Sådan reducerer du falske alarmer i oppetidsovervågning: Bekræft hver fejl med et ekstra tjek, før der sendes en alarm, sæt timeouts, der passer til, hvordan dit website normalt opfører sig, tjek for en forventet statuskode og et forventet indhold på en URL, der virkelig afspejler tjenesten, send kun hver monitors alarmer til folk, der kan handle på dem, læg planlagt arbejde i et vedligeholdelsesvindue og annoncér det, og gennemgå de mest støjende monitorer hver måned. De fleste falske alarmer kommer fra en håndfuld monitorer, hvor en af disse indstillinger er forkert, så det går som regel hurtigt at rette.
Denne guide forklarer, hvorfor falske alarmer er farlige, hvor de kommer fra, og hvad du skal ændre, indstilling for indstilling.
Derfor er falske alarmer værre, end de ser ud
Én falsk alarm er en lille irritation. En jævn strøm af dem er alarmtræthed: Folk slår kanalen på lydløs, sorterer e-mails i en mappe eller kaster et blik på telefonen og sover videre. Overvågningen kører stadig, men ingen lytter. Det første rigtige nedbrud efter det tidspunkt bliver opdaget på den gammeldags måde, af en kunde.
Der er også en mere stille pris. Hver falsk alarm river nogen ud af deres arbejde for at tjekke et website, der er helt i orden. Over en måned løber det op i timevis af tabt fokus og et team, der stoler mindre på sine værktøjer. Målet er ikke færre alarmer for deres egen skyld. Det er alarmer, der er værd at læse hver eneste gang.
Hvor falske alarmer kommer fra
Kortvarige netværksudfald mellem én tjeklokation og din server: en tabt pakke, en langsom rute, et kort DNS-hikke.
For stramme timeouts på en side, der nogle gange er langsom, men virker.
Den forkerte forventning: et tjek, der vil have status 200 fra en URL, der viderestiller, eller som leder efter en tekst, der blev ændret ved et redesign.
Den forkerte URL: en side bag rate limiting, botbeskyttelse eller et login, eller en staging-server, der slukkes om natten.
Planlagt arbejde: deploys og vedligeholdelse, der tager et website ned med vilje.
Dårlig routing: en alarm, der teknisk set er korrekt, men sendes til en, der intet kan gøre ved den. For den person er det støj.
Bekræft hver fejl med et ekstra tjek
Den enkeltstående mest effektive løsning. Når et tjek fejler, så tjek igen, før du gør noget andet. En tabt pakke eller et kort hikke består det andet tjek; et rigtigt nedbrud fejler igen. Kun en bekræftet fejl åbner en hændelse. Det fjerner de fleste små udfald uden at forsinke rigtige alarmer med mere end nogle få sekunder.
Tjenester, der tjekker fra flere lokationer, kan køre det andet tjek fra et andet sted, hvilket også fortæller dig noget nyttigt, når lokationerne er uenige i længere tid. Hvis dit website fejler fra ét kontinent og virker fra et andet, ligger problemet sandsynligvis i routingen eller ved en CDN-edge snarere end på din server. Uptimecheck tjekker fra Stockholm, London og New York og bekræfter hver fejl fra en anden lokation, før en hændelse åbnes, så et enkelt lille udfald ikke kalder nogen ud; siden om oppetidsovervågning forklarer forløbet. Det grundlæggende om, hvordan tjek bliver til alarmer, kan du læse i hvad oppetidsovervågning er.
Sæt timeouts, der passer til virkeligheden
En timeout er den tid, et tjek venter, før det erklærer websitet nede. Sætter du den for stramt, bliver normale udsving til et nedbrud. Sætter du den for løst, tæller et website, der er 40 sekunder om at svare, som oppe.
Se på historikken over svartider for et par uger. Notér det normale interval og de langsomste normale svar.
Sæt timeouten et godt stykke over det langsomste normale svar, men under det punkt, hvor besøgende giver op.
Behandl langsomhed som et signal for sig. En side, der er gået fra 300 ms til 4 sekunder, kræver opmærksomhed, men i arbejdstiden, ikke som en nedbrudsalarm om natten.
Hvis en side jævnligt ligger tæt på timeouten, er det ikke monitoren, der er problemet. Det er siden.
Forvent den rigtige statuskode og det rigtige indhold
Mange falske alarmer kommer fra tjek, der forventer det forkerte:
Viderestillinger. Overvåger du http://northwind.shop, når websitet viderestiller til https://www.northwind.shop/, tilføjer du et ekstra hop, der kan fejle for sig selv. Overvåg den endelige URL direkte, og giv viderestillingen sin egen monitor, hvis du vil tjekke den.
Skrøbelige indholdstjek. Et tjek af en marketingoverskrift går i stykker ved næste tekstændring. Vælg noget stabilt, der kun vises, når siden virker, f.eks. firmanavnet i footeren, et element i produktgitteret eller “status”:”ok” fra et health-endpoint.
For bredt. At acceptere enhver 2xx- eller 3xx-kode skjuler rigtige fejl. At acceptere kun 200 fra et endpoint, der helt legitimt returnerer 204, skaber falske. Match det, endpointet faktisk returnerer.
Validering af indhold reducerer både falske og oversete alarmer på én gang: En fejlside fra en proxy, der returnerer 200, fejler tjekket, og en kosmetisk ændring gør ikke.
Overvåg den rigtige URL
Nogle URL’er er af natur dårlige mål for overvågning. Sider bag botbeskyttelse eller en web application firewall kan en gang imellem blokere overvågningstrafik, hvilket ligner nedetid. Sider med kraftig rate limiting kan returnere 429 efter en række tjek. Login-beskyttede sider returnerer en viderestilling til loginformularen. Og forsiden er ofte cachet så kraftigt, at den bliver ved med at være oppe, mens alt bag den er nede.
Et dedikeret health-endpoint undgår alt dette. Det er ikke cachet, er billigt at levere, returnerer en forudsigelig body og fejler kun, når en afhængighed fejler. Se sådan bygger du et health check-endpoint. Hvis du skal overvåge en side bag beskyttelse, så lad overvågningstjenesten slippe igennem, og send en genkendelig user agent-header, så trafikken er nem at identificere.
Styr alarmer pr. monitor
En alarm er kun nyttig for en, der kan handle på den. Når hver monitor sendes til alle, bliver rigtige alarmer til støj for de fleste af modtagerne. Styr i stedet efter konsekvens og ejerskab:
Monitor (eksempel)KanalHvemKasse og betalings-callbackPush-notifikation og teamchatDen, der har vagtenOffentligt API-health-endpointTeamchat og webhookPlatformteametMarketingsite og blogE-mailWebteamet, i arbejdstidenStaging og interne værktøjerSeparat chatkanalDen, der ejer dem
I Uptimecheck vælger du alarmkanalerne pr. monitor. Alarmer går til e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks og push-notifikationer på telefonen, på alle planer. Se alarmer og notifikationer. Med vagtplaner når push-alarmer den, der har vagten lige nu, og eskalering kan holde en kanal tilbage i 5 til 60 minutter og kun sende en alarm, hvis ingen har kvitteret for hændelsen. Bureauer kan gruppere monitorer pr. kundeprojekt og vælge kanalerne for hver monitor, så hver kundes alarmer når det team, der tager sig af dem.
Håndtér planlagt vedligeholdelse
Planlagt nedetid bør aldrig kalde nogen ud. Før en migrering eller et langt deploy skal du lægge de monitorer, der bliver berørt, i et vedligeholdelsesvindue. Har dit værktøj ikke det, så sæt dem på pause, eller flyt deres alarmer til en stille kanal i perioden, og gør genoptagelse af overvågningen til et punkt på din deploy-tjekliste.
I Uptimecheck kan vedligeholdelsesvinduer være enkeltstående eller tilbagevendende. I et vindue er der ingen alarmer, ingen hændelser og ingen tabt oppetid, og vinduet vises på din statusside og kan sendes på e-mail til abonnenter.
Fortæl det også til kunderne. En note på din statusside inden arbejdet, med tidsrummet og hvad der bliver berørt, betyder, at ingen bliver overrasket, og at supporten ikke får henvendelser om noget, du har planlagt. Deploys, der giver et par sekunders fejl hver gang, er et separat problem: Løs dem med rullende deploys eller deploys uden nedetid i stedet for at ignorere alarmerne.
Brug beskeder om genoprettelse
En besked om genoprettelse er den alarm, der siger, at det er overstået, med den samlede nedetid. Den reducerer ikke antallet af alarmer, men den reducerer det arbejde, hver af dem giver. Uden den skal nogen blive ved med at tjekke, om et kort nedbrud er overstået. Med den er et lille udfald på to minutter om natten én alarm og én afblæsning, der kan vente til morgenen. Uptimecheck sender en besked om genoprettelse efter hver hændelse.
Gennemgå dine mest støjende monitorer
Lav en gang om måneden en liste over de monitorer, der har sendt flest alarmer, og stil disse spørgsmål til hver af dem:
Var hver alarm ægte? Hvis ikke, hvilken indstilling skyldtes den: lokation, timeout, forventning eller URL?
Gjorde nogen noget? Hvis ingen nogensinde gør det, så ændr routingen, eller fjern monitoren.
Er selve websitet ustabilt? Hyppige korte, ægte nedbrud er ikke falske alarmer; de peger på en overbelastet server eller en svag afhængighed, og alarmgrænser for servere kan hjælpe dig med at finde årsagen.
Er der stadig brug for monitoren? Nedlagte websites og gamle staging-servere er en almindelig kilde til støj.
Ugentlige og månedlige e-mailrapporter, der opsummerer oppetid og hændelser, gør denne gennemgang hurtig.
Tjekliste mod falske alarmer
Bekræft hver fejl med et ekstra tjek, før der sendes en alarm.
Sæt timeouts ud fra den reelle historik over svartider.
Overvåg endelige URL’er, ikke viderestillinger, og validér stabilt indhold.
Foretræk health-endpoints frem for cachede eller beskyttede sider.
Send hver monitor til de folk, der kan handle på den.
Læg planlagt arbejde i et vedligeholdelsesvindue, og annoncér det.
Gennemgå de mest støjende monitorer hver måned.
Opsummering
Falske alarmer er et konfigurationsproblem, og de fleste af dem kan løses på en eftermiddag. Bekræft hver fejl med et ekstra tjek, tjek den rigtige URL for det rigtige, send kun alarmer derhen, hvor der kan handles på dem, og bliv ved med at gennemgå. Belønningen er et team, der læser hver alarm, fordi hver alarm betyder noget.
Uptimecheck tjekker hver fejl igen, før der sendes en alarm, og lader dig styre alarmer pr. monitor. Start en gratis prøveperiode på 14 dage, uden kreditkort.