miksi suorittimen kuormituksen ei pitäisi (yleensä) olla kriittinen hälytys.

yksi monesti seurannassa esiin nouseva kysymys on, miten hälytystasot ja – nousut määritellään ja millä tasolla erilaiset hälytykset asetetaan-kriittiseen, virheeseen tai varoitukseen.

olettaen, että sinulla on virheitä ja kriittisiä hälytyksiä, jotka on asetettu ilmoittamaan tiimeille hakulaitteella/puhelimella, ja kriittisiä hälytyksiä, joiden eskalointiaika on lyhyempi, Seuraavassa on muutamia yksinkertaisia ohjeita:

kriittisten hälytysten tulee olla sellaisia tapahtumia varten, joilla on välitön asiakasvaikutus. Esimerkiksi tuotannon virtuaalinen IP valvotussa kuormanpalantimessa menee alas, koska sillä ei ole käytettävissä palveluja liikenteen reitittämiseen. Sivusto on alhaalla, joten hakekaa kaikki.

Virhehälytysten tulisi olla sellaisia tapahtumia varten, jotka vaativat välitöntä huomiota ja jotka ratkaisemattomina lisäävät todennäköisyyttä, että tapahtumaan vaikuttava tuotanto tapahtuu. Jos haluat jatkaa kuormituksen tasapainottajan esimerkkiä, virhe pitäisi laukaista, jos virtuaalisella IP: llä on vain yksi toimiva taustapalvelin, johon liikennettä ohjataan – nyt ei ole redundanssia, joten yksi vika voi viedä sivuston offline-tilaan.

varoitukset, joita yleensä suosittelemme lähettämään vain sähköpostitse, koskevat kaikkia muita tapahtumia. Yhden taustapalvelimen menettäminen Virtuaaliselta IP: ltä, kun 20 muuta palvelinta toimii, ei oikeuta ketään heräämään yöllä.

päätettäessä, mille tasolle kuulutukset annetaan, on otettava huomioon laitteen ensisijainen tehtävä. Esimerkiksi NetApp-tallennusryhmän tapauksessa laitteen tehtävänä on palvella lukea ja kirjoittaa IO-pyyntöjä. Joten ensisijainen asia seurannan NetApps pitäisi olla saatavuus ja suorituskyky (latenssi) näiden lukea ja kirjoittaa pyyntöjä. Jos volyymin huoltopyynnöissä on korkea latenssi – esimerkiksi 70 ms kirjoituspyyntöä kohti-tämän pitäisi olla virhetason hälytys (joissakin yrityksissä se voi olla tarkoituksenmukaista määrittää kriittisen tason hälytykseksi, mutta yleensä kriittinen suorituskykyhälytys pitäisi laukaista vain, jos loppukäytön suorituskyky heikkenee kohtuuttomasti.) Kuitenkin, jos CPU kuormitus NetApp on 99% ajaksi, vaikka se kuulostaa hälyttävä, ehdotan, että käsitellään Varoitustaso hälytys vain. Jos viiveellä ei ole vaikutusta, miksi herättää ihmisiä yöllä? Lähetä sähköpostihälytys, jotta asia voidaan tutkia, mutta jos laitteen toiminta ei ole heikentynyt, älä ylireagoi. (Jos haluat, voit määritellä hälytys eskalaatiot niin, että tällaiset ehdot johtavat sivuja, jos korjaamattomia tai unacnowledged yli 5 tuntia, sanoa.)

Alert Overload on suurempi vaara useimmille datakeskuksille kuin useimmat ihmiset tajuavatkaan. Usein ajatellaan ,että ” jos yksi hälytys on hyvä, useamman pitää olla parempi.”Sen sijaan, keskittyä tunnistamaan ensisijaiset toiminnot laitteiden-set virhetaso hälytykset näistä toiminnoista, ja käyttää varoituksia kertoa olosuhteista, jotka voivat heikentää, että toimintoja, tai tukea vianmääritys. (Jos latenssi NetApp on korkea, ja CPU kuormitus on myös hälytys, joka ilmeisesti auttaa diagnosoimaan ongelman, sen sijaan, että etsit epätavallinen tilavuus toimintaa.)

Reserve Critical alerts for system performance and availability as a whole.

Logicmonitorin isännöidyssä seurannassa kaikkien datakeskuslaitteiden varoitusmääritelmien varoituskynnykset on ennalta määritelty edellä mainitulla tavalla – tämä on yksi tapa, jolla autamme tarjoamaan mielekästä seurantaa minuuteissa.