HVORFOR CPU-belastning ikke (vanligvis) bør være et kritisk varsel.

et spørsmål som ofte oppstår i overvåking er hvordan du definerer varselnivåer og eskaleringer, og hvilket nivå du skal sette ulike varsler På-Kritisk, Feil eller Advarsel.

Forutsatt At Du Har Feil Og Kritiske varsler satt til å varsle team etter personsøker/telefon, Og Kritiske varsler med kortere eskaleringstid, er Det noen enkle retningslinjer:

Kritiske varsler bør være for hendelser som har umiddelbar effekt på kundepåvirkning. For eksempel går En virtuell ip-produksjon på en overvåket belastningsfordeling ned, da den ikke har noen tilgjengelige tjenester for å rute trafikken til. Nettstedet er nede, så siden alle.

Feilvarsler bør være for hendelser som krever umiddelbar oppmerksomhet, og som, hvis uløste, øker sannsynligheten for at en produksjon som påvirker hendelsen vil skje. For å fortsette med load balancer-eksemplet, bør en feil utløses hvis Den Virtuelle IP-EN bare har en fungerende backend-server for å rute trafikk til – det er nå ingen redundans, så en feil kan ta nettstedet offline.

Advarsler, som vi vanligvis anbefaler sendes kun via e-post, er for alle andre typer hendelser. Tapet av en enkelt backend-server fra En Virtuell IP når det er 20 andre servere som fungerer, garanterer ikke at noen blir våknet om natten.

når du bestemmer hvilket nivå du vil tildele varsler, bør du vurdere enhetens primære funksjon. For Eksempel, i Tilfelle Av En NetApp storage array, er funksjonen til enheten å betjene lese OG skrive IO-forespørsler. Så den primære tingen for å overvåke NetApps bør være tilgjengeligheten og ytelsen (latens) av disse lese-og skriveforespørslene. Hvis et volum betjener forespørsler med høy ventetid – for eksempel 70 ms per skriveforespørsel-bør det være Et feilnivåvarsel (i noen bedrifter kan det være hensiktsmessig å konfigurere Som Et Kritisk nivåvarsel, men vanligvis bør Et Kritisk ytelsesvarsel bare utløses hvis sluttprogrammets ytelse forringes uakseptabelt.) Men HVIS CPU-belastningen på NetApp er 99% i en periode, selv om det høres alarmerende ut, vil jeg foreslå at det bare behandles som Et Advarselsnivåvarsel. Hvis latens ikke påvirkes, hvorfor vekke folk om natten? Send et e-postvarsel slik at problemet kan undersøkes, men hvis funksjonen til enheten ikke er svekket, må du ikke overreagere. (Hvis du ønsker det, kan du definere varslings eskaleringer slik at slike forhold resultere i sider hvis ukorrigert eller besvares i mer enn 5 timer, sier.)

Overbelastning Av Varsler er en større fare for de fleste datasentre enn de fleste er klar over. Tanken er ofte “hvis ett varsel er bra, må mer være bedre.”I stedet fokuserer du på å identifisere de primære funksjonene til enheter-angi feilnivåvarsler på disse funksjonene, og bruk Advarsler for å informere deg om forhold som kan svekke funksjonene, eller for å hjelpe til med feilsøking. (Hvis latens på En NetApp er høy, OG CPU-belastningen er også i varsel, hjelper det åpenbart med å diagnostisere problemet, i stedet for å lete etter uvanlig volumaktivitet.)

Reserver Kritiske varsler for systemytelse og tilgjengelighet som helhet.

med LogicMonitor hosted monitoring har varslingsdefinisjonene for alle datasenterenheter sine varslingsterskler forhåndsdefinert på ovennevnte måte – det er en måte vi bidrar til å gi meningsfull overvåking på få minutter.