Slik reduserer du falske varsler i oppetidsovervåkingen: bekreft hver feil med en ny sjekk før du varsler, sett tidsavbrudd som passer til hvordan nettstedet vanligvis oppfører seg, sjekk etter forventet statuskode og innhold på en URL som virkelig gjenspeiler tjenesten, send varslene fra hver monitor bare til folk som kan gjøre noe med dem, legg planlagt arbeid i et vedlikeholdsvindu og varsle om det på forhånd, og gå gjennom de mest støyende monitorene hver måned. De fleste falske varsler kommer fra en håndfull monitorer der én av disse innstillingene er feil, så det går som regel raskt å rette dem.
Denne guiden forklarer hvorfor falske varsler er farlige, hvor de kommer fra og hva du bør endre, innstilling for innstilling.
Hvorfor falske varsler er verre enn de ser ut
Ett falskt varsel er en liten irritasjon. En jevn strøm av dem er varslingstretthet: folk demper kanalen, filtrerer e-postene inn i en mappe eller kaster et blikk på mobilen og sovner igjen. Overvåkingen kjører fortsatt, men ingen lytter. Det første ekte nedbruddet etter det blir oppdaget på den gamle måten, av en kunde.
Det finnes også en mer skjult kostnad. Hvert falskt varsel drar noen bort fra arbeidet for å sjekke et nettsted som fungerer helt fint. I løpet av en måned blir det timer med tapt konsentrasjon og et team som stoler mindre på verktøyene sine. Målet er ikke færre varsler for sin egen skyld. Det er varsler som er verdt å lese hver eneste gang.
Hvor falske varsler kommer fra
Nettverksblipp mellom én sjekklokasjon og serveren din: en tapt pakke, en treg rute, et kort DNS-hikke.
For stramme tidsavbrudd for en side som av og til er treg, men fungerer.
Feil forventning: en sjekk som vil ha status 200 fra en URL som videresender, eller som ser etter tekst som ble endret i et redesign.
Feil URL: en side bak rate limiting, bot-beskyttelse eller innlogging, eller en staging-server som er slått av om natten.
Planlagt arbeid: deployer og vedlikehold som tar ned et nettsted med vilje.
Dårlig ruting: et varsel som er teknisk korrekt, men sendes til noen som ikke kan gjøre noe med det. For den personen er det bare støy.
Bekreft hver feil med en ny sjekk
Dette er det aller mest effektive grepet. Når en sjekk feiler, sjekker du på nytt før du gjør noe annet. En tapt pakke eller et kort hikke går gjennom den andre sjekken; et ekte nedbrudd feiler igjen. Bare en bekreftet feil åpner en hendelse. Det fjerner de fleste blippene uten å forsinke ekte varsler med mer enn noen sekunder.
Tjenester som sjekker fra flere lokasjoner, kan kjøre den andre sjekken fra et annet sted, og det forteller deg også noe nyttig når lokasjonene er uenige over lengre tid. Hvis nettstedet feiler fra ett kontinent og fungerer fra et annet, ligger problemet trolig i rutingen eller i en CDN-node, ikke i serveren din. Uptimecheck sjekker fra Stockholm, London og New York, og bekrefter hver feil fra en annen lokasjon før en hendelse åpnes, så ett enkelt blipp ikke varsler noen; siden om oppetidsovervåking forklarer flyten. For det grunnleggende om hvordan sjekker blir til varsler, se hva oppetidsovervåking er.
Sett tidsavbrudd som passer virkeligheten
Et tidsavbrudd er hvor lenge en sjekk venter før den erklærer nettstedet nede. Er det for stramt, blir normale variasjoner til nedbrudd. Er det for romslig, regnes et nettsted som bruker 40 sekunder på å svare, som oppe.
Se på historikken over responstid i noen uker. Noter det normale spennet og de tregeste normale svarene.
Sett tidsavbruddet godt over det tregeste normale svaret, men under punktet der de besøkende gir opp.
Behandle treghet som et eget signal. En side som har gått fra 300 ms til 4 sekunder, trenger oppmerksomhet, men i arbeidstiden, ikke som et nedbruddsvarsel om natten.
Hvis en side jevnlig ligger nær tidsavbruddet, er det ikke monitoren som er problemet. Det er siden.
Forvent riktig statuskode og riktig innhold
Mange falske varsler kommer fra sjekker som forventer feil ting:
Videresendinger. Å overvåke http://northwind.shop når nettstedet videresender til https://www.northwind.shop/, legger til et ekstra hopp som kan feile for seg selv. Overvåk den endelige URL-en direkte, og gi videresendingen en egen monitor hvis du vil kontrollere den.
Skjøre innholdssjekker. Å validere en markedsføringsoverskrift slutter å fungere ved neste tekstendring. Velg noe stabilt som bare vises når siden fungerer, for eksempel firmanavnet i bunnteksten, et element i produktrutenettet eller «status»:»ok» fra et health-endepunkt.
For bredt. Å godta alle 2xx- og 3xx-koder skjuler ekte feil. Å godta bare 200 fra et endepunkt som helt legitimt returnerer 204, skaper falske. Match det endepunktet faktisk returnerer.
Innholdsvalidering reduserer både falske og tapte varsler på samme tid: en feilside fra en proxy som returnerer 200, feiler sjekken, mens en kosmetisk endring ikke gjør det.
Overvåk riktig URL
Noen URL-er er av natur dårlige å overvåke. Sider bak bot-beskyttelse eller en brannmur for webapplikasjoner kan av og til blokkere overvåkingstrafikk, noe som ser ut som nedetid. Sider med streng rate limiting kan returnere 429 etter en rekke sjekker. Innloggingsbeskyttede sider returnerer en videresending til innloggingsskjemaet. Og forsiden er ofte så hardt cachet at den holder seg oppe mens alt bak den er nede.
Et eget health-endepunkt unngår alt dette. Det er ikke cachet, er billig å levere, returnerer en forutsigbar body og feiler bare når en avhengighet feiler. Se slik bygger du et health check-endepunkt. Må du overvåke en side bak beskyttelse, slipper du overvåkingstjenesten gjennom og sender en gjenkjennelig user agent-header, så trafikken er lett å identifisere.
Rut varsler per monitor
Et varsel er bare nyttig for noen som kan handle på det. Sender du alle monitorer til alle, blir ekte varsler til støy for de fleste som mottar dem. Rut heller etter konsekvens og ansvar:
Monitor (eksempel)KanalHvemKasse og betalings-callbackPush-varsel og teamchatDen som har vaktHealth-endepunkt for det offentlige API-etTeamchat og webhookPlattformteametMarkedsføringsnettsted og bloggE-postWebteamet, i arbeidstidenStaging og interne verktøyEgen chatkanalDen som eier dem
I Uptimecheck velger du varslingskanaler per monitor. Varsler går til e-post, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks og push-varsler på mobilen, på alle planer. Se varsler og notifikasjoner. Med vaktplaner når push-varsler den som har vakt akkurat nå, og eskalering kan holde en kanal tilbake i 5 til 60 minutter og bare varsle hvis ingen har bekreftet hendelsen. Byråer kan gruppere monitorer per kundeprosjekt og velge kanalene for hver monitor, slik at varslene for hver kunde når teamet som har ansvaret for den.
Håndter planlagt vedlikehold
Planlagt nedetid skal aldri varsle noen. Før en migrering eller en lang deploy legger du monitorene som blir berørt, i et vedlikeholdsvindu. Har ikke verktøyet ditt det, setter du dem på pause eller flytter varslene deres til en stille kanal så lenge arbeidet pågår, og gjør det å starte overvåkingen igjen til et punkt i sjekklisten for deploy.
I Uptimecheck kan vedlikeholdsvinduer være engangs eller gjentakende. I et vindu er det ingen varsler, ingen hendelser og ingen tapt oppetid, og vinduet vises på statussiden din og kan sendes på e-post til abonnenter.
Si fra til kundene også. En melding på statussiden før arbeidet, med tidsrommet og hva som blir berørt, betyr at ingen blir overrasket, og at supporten ikke får henvendelser om noe dere har planlagt. Deployer som gir noen sekunder med feil hver gang, er et eget problem: løs dem med rullerende deployer eller deployer uten nedetid, i stedet for å ignorere varslene.
Bruk meldinger om gjenoppretting
En melding om gjenoppretting er varselet som sier at det er over, med den samlede nedetiden. Den reduserer ikke antallet varsler, men den reduserer arbeidet hvert av dem fører med seg. Uten den må noen fortsette å sjekke om et kort nedbrudd er over. Med den blir et blipp på to minutter om natten ett varsel og én friskmelding som kan vente til morgenen. Uptimecheck sender en melding om gjenoppretting etter hver hendelse.
Gå gjennom de mest støyende monitorene
En gang i måneden lister du opp monitorene som varslet mest, og spør om hver av dem:
Var hvert varsel ekte? Hvis ikke, hvilken innstilling forårsaket det: lokasjon, tidsavbrudd, forventning eller URL?
Gjorde noen noe? Hvis ingen noen gang gjør det, endrer du rutingen eller fjerner monitoren.
Er selve nettstedet ustabilt? Hyppige, korte, ekte nedbrudd er ikke falske varsler; de peker på en overbelastet server eller en svak avhengighet, og varslingsterskler for servere kan hjelpe deg å finne årsaken.
Trengs monitoren fortsatt? Nedlagte nettsteder og gamle staging-servere er en vanlig kilde til støy.
Ukentlige og månedlige e-postrapporter som oppsummerer oppetid og hendelser, gjør denne gjennomgangen rask.
Sjekkliste mot falske varsler
Bekreft hver feil med en ny sjekk før du varsler.
Sett tidsavbrudd ut fra den faktiske historikken over responstid.
Overvåk endelige URL-er, ikke videresendinger, og valider stabilt innhold.
Velg health-endepunkter fremfor cachede eller beskyttede sider.
Send varslene fra hver monitor til de som kan gjøre noe med dem.
Legg planlagt arbeid i et vedlikeholdsvindu, og varsle om det på forhånd.
Gå gjennom de mest støyende monitorene hver måned.
Oppsummering
Falske varsler er et konfigurasjonsproblem, og de fleste kan rettes på en ettermiddag. Bekreft hver feil med en ny sjekk, sjekk riktig URL for riktig ting, send varsler bare dit noen kan handle på dem, og fortsett å gå gjennom oppsettet. Belønningen er et team som leser hvert varsel, fordi hvert varsel betyr noe.
Uptimecheck sjekker hver feil på nytt før det varsler, og lar deg rute varsler per monitor. Start en gratis prøveperiode på 14 dager, uten kredittkort.