Minél összetettebb a rendszer, annál inkább benőtte mindenféle riasztás. És ugyanezekre a figyelmeztetésekre reagálni kell, összesíteni és vizualizálni kell őket. Szerintem ez az idegességig sokak számára ismerős helyzet.
A szóba kerülő megoldás nem a legváratlanabb, de a keresés nem ad teljes értékű cikket ebben a témában.
Ezért úgy döntöttem, hogy megosztom a FunCorp tapasztalatait, és beszélek arról, hogyan épül fel az ügyelet, ki hív, miért és hogyan nézheti meg mindezt.
Mi az a PagerDuty?
Ezért ezeknek a problémáknak a megoldására elkezdtünk egy kényelmes eszközt keresni. Némi keresgélés után a PagerDuty mellett döntöttünk. Számunkra a PD meglehetősen teljes és tömör megoldásnak tűnt, számos integrációval és beállítással. Írd őt körül?
Röviden, a PagerDuty egy incidensfeldolgozó platform, amely különféle integrációkon keresztül képes feldolgozni a bejövő incidenseket, beállítani a szolgálati utasításokat, majd az incidens szintjétől függően riasztani az ügyeletes mérnököt (magas szinten - hívás, alacsony szinten - egy push az alkalmazásból / SMS) .
Ki az ügyeletes?
Valószínűleg ez az első hely, ahol elkezdheti a PD beállítását.
A FunCorp-nál más cégekhez hasonlóan tiszteletbeli ügyeletesi beosztás is van. Mérnöktől mérnökhöz naponta egyszer továbbítja. A PagerDuty riasztására egy úgynevezett első és második sor válaszol. Tegyük fel, hogy magas prioritású riasztás érkezik, és ha az első vonalról érkező ügyeletes hívása után 10 perccel nem reagál rá (azaz nem kerül át nyugtázási vagy megoldott állapotba), akkor a hívás a másodikra megy ügyeletes mérnök. Ez magában a PagerDutyban van beállítva az eszkalációs házirendeken keresztül.
Ha a második ügyeletes nem válaszol, az értesítés visszatér a címre fő- az ügyeletesnek.
Így a bejövő magas prioritású riasztások nem maradhatnak feldolgozatlanok.
Most pedig lássuk, honnan származhatnak az események.
Milyen integrációkat használunk?
A PD számos különböző incidenst kap különböző szolgáltatásoktól. Jelenleg mintegy 25 ilyen szolgáltatással rendelkezünk, ezek feldolgozásához néhány kész integrációt alkalmazunk.
- Prométheusz
A fő mérési rendszer a Prometheus. A Habrén már sokat írtak róla, csak annyit mondok, hogy nálunk több is van különböző környezetekhez: az egyik virtuális gépekből és dokkolóból gyűjti a mérőszámokat, a másik az Amazon szolgáltatásaiból, a harmadik hardveres gépekből. A Telegraf főként mérőszám-exportőrként szolgál.
Itt is szerintem a címből minden kiderül. Ez az integráció arra szolgál, hogy értesítéseket küldjön egyes cron által végrehajtott szkriptekről. A PD megad egy bizonyos címet, amelyre leveleket küld. Az ilyen integrációval rendelkező szolgáltatás létrehozásakor beállíthatja a prioritásokat, a beérkező incidensek feldolgozási sorrendjét, hogyan kell pontosan létrehozni egy riasztást (minden bejövő levélre, bejövő levélre + egy bizonyos szabály stb.).
- Laza
Szerintem nagyon érdekes integráció. Vannak esetek, amikor történik valami, de nem fedik le az események. Ezért egy incidens létrehozásához hozzáadtuk a Slack integrációját. Vagyis írhatsz a céges Slack-nek /callofduty minden lassú és hamarosan eltörik és a PD feldolgozza és elküldi az incidenst az ügyeletes mérnöknek.
Mi csináljuk:
Látjuk:
- API
HTTP integráció. Valójában nincs itt semmi különösebben érdekes, csak egy POST-kérés JSON formátumú törzstel. Például valami érdekeset: külső megfigyelésre használjuk . Ez a szolgáltatás ellenőrzi oldalaink elérhetőségét a világ különböző részein. Abban az esetben, ha elfogadhatatlan válaszkódot kapunk (például 502), akkor incidens jön létre, majd minden a fent leírt láncot követi. Maga a StatusCake képes figyelni a belső URL-eket, az SSL-tanúsítványt vagy a domain lejáratát.
- LibreNMS
Ez egy másik megfigyelő rendszer, erről bővebben a honlapjukon olvashat . Segítségével a hálózati interfészeket és az iDRAC-ot figyeljük szerverekről.
Voltak olyan integrációk is, mint a Datadog, CloudWatch. Bővebben megtekintheti, mi történt velük .
Megjelenítés
A fő eseményjelentési rendszer a Slack. A PD-hez érkező összes incidens egy speciális chatbe kerül, és ha az állapotuk megváltozik, akkor ez is megjelenik a chatben.
Amikor lehetőség nyílt arra, hogy a mennyezetről lelógó monitorok képernyőjén hasznos adatokat jelenítsen meg, hirtelen rájöttünk, hogy nekünk (a devops részlegen) nincs mit megjeleníteni rajtuk. Van egy csodálatos Grafana, de nem fed le mindent, és az alkalmazottak a riasztásokra reagálnak, nem a diagramokra.
Miután alaposan, de sikertelenül kerestük a GitHubon egy tömör és informatív „táblát” a PD számára, úgy döntöttünk, hogy megírjuk a sajátunkat – csak azzal, amire szükségünk van. Bár eleinte az volt az ötlet, hogy magát a PD felületet jelenítsék meg, ez még kényelmetlenebbnek tűnt.
Az íráshoz csak egy kulcsot kell beszereznie egy PD-től, amely csak olvasható joggal rendelkezik.
És ezt kaptuk:
A képernyőn megjelennek az aktuális nyitott események, a kiválasztott ütemterv szerint szolgálatban lévő mérnök neve, valamint a magas prioritású incidens nélküli idő (a magas prioritású eseményt tartalmazó panel piros színnel lesz kiemelve).
.
Ennek eredményeként egy kényelmes irányítópultot kaptunk, ahol minden eseményünket megtekinthetjük. Örülök, ha néhányan hasznosnak találják tapasztalatainkat.
Forrás: will.com