A Mon-ifesto 2. rész: Riasztás és ábrázolás

3 részes útmutató a jobb alkalmazásfigyeléshez

< 3 részből álló sorozat 2. része a megfigyelésről. Itt olvashat 1. rész itt.

Ha a mutatóit azonosították, az alapvonalat megállapították és az adatok áramlottak, akkor mi van? A következő a riasztás beállítása.

A mutatói négyféle figyelmeztetést generálnak: alacsony prioritású, közepes prioritású, magas prioritású és információs . Annak kiderítése, hogy mely riasztások mely riasztásokat generálják, és a megfelelő csatornákra irányítása nagyban hozzájárul a „személyhívó fáradtságának” csökkentéséhez és a műveleti csapatok boldoggá (és kevésbé alváshiányossá) tételéhez. Vessünk egy pillantást az egyes riasztástípusokra, és néhány javaslatot az útvonalak továbbítására.

Felhívjuk figyelmét, hogy az ilyen riasztási típusok SLA-k általános irányelvek; az alkalmazás SLA-jai valószínűleg eltérőek lesznek, de ezek jó kiindulópontot jelentenek. Ebben az összefüggésben az SLA a riasztások létrehozásától a mérnökök általi nyugtázásig tartó idő, nem pedig a felbontásig eltelt idő.

1. Magas prioritású riasztások (SLA: percek)

A kiemelt fontosságú figyelmeztetések a legsúlyosabb riasztások, amelyeket alkalmazásod generál. Ezek a figyelmeztetések gyakran a négy legfontosabb mutató egyikének nagy (hirtelen megugrására) vonatkoznak (hívások percenként, hibaarány, válaszidő, sávszélesség telítettség). Figyelem, amit mondtam: „ nagy hirtelen csúcsok” – nem azt szeretné, hogy minden tüske kiemelt figyelmeztetést generáljon, csak azokat, amelyek jelzik az alkalmazás lehetséges meghibásodási állapotát. Ezenkívül a kiemelt figyelmeztetések az alkalmazás általános elérhetőségét szolgálják; ha az alkalmazás nem érhető el, akkor komoly problémája van.

A kiemelt fontosságú figyelmeztetések továbbítása meglehetősen egyszerű: ha integrálva van a vállalat NOC-jával, küldje el nekik a figyelmeztetéseket. Ha nem, akkor egy műveletkezelő eszköz felbecsülhetetlen. Egy ilyen eszköz lehetővé teszi, hogy felhívja mérnökeinek telefonjait, hogy figyelmeztesse őket a problémára. A kiemelt fontosságú figyelmeztetések azok a figyelmeztetések, amelyekre felébreszti az embereket, ezért ne légy félénk a hangos riasztások beállításával kapcsolatban. Szüksége van a mérnökeire, hogy ezekre ugyanúgy reagáljanak, mint a tűzoltók egy öt riasztás esetén.

A mérnökök lapozása mellett ezeket a figyelmeztetéseket is meg akarja jeleníteni valahol. Rendelkeznie kell a folyamatban lévő deszkával, hogy megbizonyosodjon arról, hogy az egész csapat ugyanazon az oldalon van, és megérti a prioritásokat. Erre egy böngészőalapú eseménytábla jó megoldás, de használhat tévéket vagy projektorokat is, ha csapata ugyanabban az irodában van.

2. Közepes prioritású figyelmeztetés (SLA: Órák)

Kezdjük azzal, hogy beszélünk arról, hogyan továbbítjuk a közepes riasztásokat. Ezekkel a riasztásokkal nem akar riasztást adni, hanem azt is, hogy a közepes riasztások láthatók legyenek a mérnökei előtt. Ehhez egy kétirányú megközelítést ajánlanék: irányítsa a riasztásokat egy olyan eszközhöz, mint a Slack, a Hipchat, a csapatok stb., És a figyelmeztető táblához. Valós idejű csevegőalkalmazás segítségével az ügyeletes mérnökeinek valós idejű riasztási csatornát ad, miközben az ügyeletes mérnökeinek lehetősége van figyelmen kívül hagyni a riasztásokat.

Ami azt jelenti, hogy milyen figyelmeztetéseket kell közepes prioritásnak tekinteni, akkor általában tartósan megnövekedett mutatókat vagy olyan mutatók hirtelen megugrását szeretné megvizsgálni, amelyek nem jelentik az alkalmazásának potenciális meghibásodási állapotát. Ezen felül, ha szeretné, felveheti a host-down értesítéseket a közepes prioritású kategóriába. Ha az alkalmazásszolgáltatást megfelelően tervezte meg, akkor a down hostok nem kritikus tömege nem jelenthet válsághelyzetet. A leállított állomások és az ismeretlen jövőbeli forgalmi minták együttesen azt jelentik, hogy fogalmad sincs, hogy bejövő forgalom áradatát látod-e vagy sem, és a legrosszabbra kell tervezned.

3. Alacsony prioritású figyelmeztetések (SLA: Napok)

Az alacsony prioritású figyelmeztetések a legalacsonyabb prioritású figyelmeztetések, amelyekre mérnökeinek reagálnia kell. Ezek a riasztások mindenre vonatkozhatnak, amely valamilyen emberi beavatkozást igényel – alacsony lemezterület, CPU-csúcsok, elejtett hálózati csomagok stb. Azért kezeljük ezeket a riasztásokat alacsony prioritásként, mert az 1. részben leírtak szerint az alkalmazás alapjául szolgáló infrastruktúrával vagy környezettel kapcsolatos bármely súlyos probléma a négy legfontosabb mutatóig terjed. Önmagában az olyan dolgok, mint a CPU-használat, nem sokat jelentenek, de egy mérnöknek meg kell vizsgálnia, ha van egy kis ideje, és megnézheti, van-e valamilyen mélyebb kérdés.

Ezeknek a riasztásoknak az átirányítása egyszerű: küldje el a JIRA-nak vagy más feladatkövető alkalmazásnak. Mivel az SLA-t napokban mérik, ezek a riasztások nyugodtan beülhetnek egy JIRA-sorba, hogy a mérnöki csapatok egyesével válogathassanak, ha nem vesznek igénybe magasabb prioritású riasztásokat. Ezen kívül ne lepődjön meg, ha az alacsony prioritású problémák többsége gyorsan lezárul, mivel „nem tudott reprodukálni”, ezek a riasztások gyakran átmeneti jellegűek, a mérnöki csapat vezérlésén kívül eső tényezők miatt (a fájlmentés hálózati I / O szűk keresztmetszetet okozott) stb.).

Ha rendelkezik fejlesztési kapacitással, az alacsony prioritású riasztások nagyon jó célpontok a riasztási válasz automatizálásához. Gyakran egy probléma megismételhető felbontású lesz (indítsa újra a gépet, törölje a / tmp mappát stb.), És ezeknek a feladatoknak az automatizálása jó módja annak, hogy mérnökei számára ciklusokat szabadítson fel fontosabb feladatok elvégzéséhez.

4. Információs figyelmeztetések (SLA: Nincs)

Eddig olyan riasztásokról beszéltünk, amelyek bizonyos minőségben emberi beavatkozást igényelnek. Az információs riasztások nem; aligha nevezhetők „riasztásoknak”, mivel jobban hasonlítanak a „közleményekhez” vagy „hozzászólásokhoz”. Itt lehet hasznos egy olyan rendszer, mint a Splunk vagy az ELK verem; ezeket az értesítéseket valamilyen szöveg-összesítő rendszerhez tolhatja, későbbi elemzéshez vagy korrelációhoz, ha akarja. Ezek az értesítések hasznosak lehetnek olyan metrikus irányítópultok készítéséhez, amelyek nyomon követik a statisztikákat, például az alkalmazásbevezetéseket vagy a JVM újraindítását.

Most, hogy meghatároztuk a riasztási szintünket és azt, hogy miként fogjuk értesíteni mérnökeinket a problémákról, meg kell találnunk, hogyan fogunk pontosan reagálni ezekre a riasztásokra.

* A Mon-ifesto 1. rész: Mutatók

* A Mon-ifesto 3. rész: Riasztási válasz és halál utáni

< KÖZZÉTÉTELI NYILATKOZAT: Ezek a vélemények a szerző véleményei. Hacsak a bejegyzés másképp nem rendelkezik, a Capital One nem áll kapcsolatban és nem is támogatja az említett vállalatokat. Minden használt vagy bemutatott védjegy és egyéb szellemi tulajdon a megfelelő tulajdonosok tulajdonában van. Ez a cikk © 2018 Capital One.