Bolj kot je sistem zapleten, bolj ga preraščajo raznorazna opozorila. In na ta ista opozorila se je treba odzvati, jih združiti in vizualizirati. Mislim, da je to situacija, ki je mnogim znana do nervoze.
Rešitev, o kateri bomo razpravljali, ni najbolj nepričakovana, vendar iskanje ne vrne polnopravnega članka o tej temi.
Zato sem se odločil deliti izkušnjo FunCorpa in spregovoriti o tem, kako je strukturiran proces dežurstva, kdo kliče, zakaj in kako lahko na vse to gledate.
Kaj je PagerDuty?
Zato smo za rešitev vseh teh težav začeli iskati priročno orodje. Po nekaj iskanja smo izbrali PagerDuty. PD se nam je zdel dokaj popolna in jedrnata rešitev z velikim številom integracij in nastavitev. Kakšna je?
Skratka, PagerDuty je platforma za obdelavo incidentov, ki lahko obdela dohodne incidente prek različnih integracij, nastavi dežurne naloge in nato opozori dežurnega inženirja glede na stopnjo incidenta (na visoki ravni - klic, na nizki ravni - push iz aplikacije/SMS).
Kdo je dežurni?
To je verjetno prvo mesto, kjer lahko začnete postavljati PD.
V FunCorpu, tako kot v drugih podjetjih, obstaja časten položaj dežurnega častnika. Enkrat na dan se prenaša od inženirja do inženirja. Obstajata tako imenovana prva in druga vrstica odgovora na opozorilo PagerDuty. Recimo, da prispe visoko prioritetno opozorilo in če 10 minut po klicu dežurnemu inženirju iz prve linije ni reakcije nanj (tj. Ne prenese se v stanje potrditve ali razrešeno), klic preide na drugo dežurni inženir. To je konfigurirano v samem PagerDuty s pravilniki o eskalaciji.
Če se drugi dežurni ne odzove, se obvestilo vrne nazaj na glavni dežurnemu.
Tako nobeno dohodno opozorilo visoke prioritete ne more ostati neobdelano.
Zdaj pa poglejmo, od kod lahko pride do incidentov.
Kakšne integracije uporabljamo?
PD prejme veliko različnih incidentov od različnih služb. Trenutno imamo približno 25 takih storitev, za njihovo obdelavo pa uporabljamo nekaj že pripravljenih integracij.
- Prometej
Glavni sistem zbiranja metrik je Prometheus. O tem je bilo na Habréju že veliko napisanega, povem le, da jih imamo več za različna okolja: eden zbira metrike iz virtualnih strojev in dockerjev, drugi iz Amazonovih storitev, tretji iz strojne opreme. Telegraf se uporablja predvsem kot izvoznik meritev.
- E-pošta
Tudi tukaj mislim, da je vse jasno iz naslova. Ta integracija se uporablja za pošiljanje obvestil iz nekaterih skriptov, ki jih izvaja cron. PD vam da določen naslov, na katerega pošiljate pisma. Pri ustvarjanju storitve s tako integracijo lahko nastavite prioritete, v kakšnem vrstnem redu bodo obdelani dohodni incidenti, kako natančno ustvariti opozorilo (za vsako dohodno pismo, za dohodno pismo + določeno pravilo itd.).
- Slack
Po moje zelo zanimiva integracija. Včasih se nekaj zgodi, vendar ni zajeto v incidentih. Zato smo dodali integracijo iz Slacka, da ustvarimo incident. To pomeni, da lahko pišete podjetju Slack /callofduty vse je počasno in se bo kmalu pokvarilo in PD ga bo obdelal in dogodek poslal dežurnemu inženirju.
delamo:
Vidimo:
- API
HTTP integracija. Pravzaprav tukaj ni nič posebej zanimivega, samo POST zahteva s telesom v formatu JSON. Na primer, nekaj zanimivega: uporabljamo ga za zunanji nadzor . Ta storitev preverja dostopnost naših spletnih mest z različnih koncev sveta. V primeru, ko prejmemo nesprejemljivo odzivno kodo (npr. 502), se ustvari incident in potem vse poteka po zgoraj opisani verigi. StatusCake sam ima možnost spremljanja notranjih URL-jev, SSL certifikata ali poteka domene.
- LibreNMS
To je še en nadzorni sistem, več o njem si lahko preberete na njihovi spletni strani . Z njegovo pomočjo spremljamo omrežne vmesnike in iDRAC s strežnikov.
Obstajale so tudi integracije, kot sta Datadog, CloudWatch. Več o tem, kaj se jim je zgodilo, lahko vidite .
Vizualizacija
Glavni sistem za poročanje o incidentih je Slack. Vsi dogodki, ki pridejo na PD, se zapišejo v poseben klepet in če se njihov status spremeni, se to tudi prikaže v klepetu.
Ko se je pojavila priložnost, da uporabne podatke prikažemo na zaslonih monitorjev, ki visijo s stropa, smo nenadoma ugotovili, da mi (v oddelku devops) nimamo kaj prikazati na njih. Obstaja čudovita Grafana, vendar ne pokriva vsega in zaposleni se odzivajo na opozorila, ne na grafikone.
Po temeljitem, a neuspešnem iskanju na GitHubu jedrnate in informativne »plošče« za PD, smo se odločili, da napišemo svojo - samo s tem, kar potrebujemo. Čeprav je sprva obstajala ideja o prikazovanju samega vmesnika PD, je bilo videti še bolj neprijetno.
Če ga želite napisati, morate le pridobiti ključ od PD s pravicami samo za branje.
In tole smo dobili:
Na zaslonu so prikazani trenutni odprti incidenti, ime trenutnega dežurnega inženirja iz izbranega urnika in čas brez incidenta visoke prioritete (plošča z incidentom visoke prioritete bo označena rdeče).
.
Kot rezultat smo prejeli priročno nadzorno ploščo za pregled vseh naših dogodkov. Vesela bom, če bo komu od vas naša izkušnja koristila.
Vir: www.habr.com