Kuo sudėtingesnė sistema, tuo labiau ji apauga įvairiausiais įspėjimais. Ir reikia reaguoti į tuos pačius įspėjimus, juos apibendrinti ir vizualizuoti. Manau, kad tai daugeliui iki nervingumo pažįstama situacija.
Sprendimas, apie kurį bus kalbama, nėra pats netikėčiausias, tačiau paieška visaverčio straipsnio šia tema neduoda.
Todėl nusprendžiau pasidalinti FunCorp patirtimi ir pakalbėti apie tai, kaip vyksta budėjimo procesas, kas skambina, kodėl ir kaip į visa tai galima pažvelgti.
Kas yra PagerDuty?
Taigi, norėdami išspręsti visas šias problemas, pradėjome ieškoti patogaus įrankio. Po kiek paieškų pasirinkome PagerDuty. PD mums atrodė gana išsamus ir glaustas sprendimas su daugybe integracijų ir nustatymų. Kokia ji?
Trumpai tariant, „PagerDuty“ yra incidentų apdorojimo platforma, kuri gali apdoroti gaunamus incidentus per įvairias integracijas, nustatyti budėjimo nurodymus ir įspėti budintį inžinierių, atsižvelgiant į incidento lygį (aukštu lygiu – skambučiu, žemu – paspaudimas iš programos / SMS) .
Kas yra budintis pareigūnas?
Tai turbūt pirmoji vieta, kur pradėti kurti PD.
„FunCorp“, kaip ir kitose įmonėse, užima garbės pareigūno pareigas. Jis perduodamas iš inžinieriaus inžinieriui kartą per dieną. Yra vadinamoji pirmoji ir antroji atsako eilutės į įspėjimą iš PagerDuty. Tarkime, atkeliauja aukšto prioriteto perspėjimas ir jei po 10 minučių po skambučio budėtojui iš pirmos linijos į jį nereaguojama (t.y. neperkeliama į patvirtinimo ar išspręsto būseną), skambutis pereina į antrąjį. budintis inžinierius. Tai sukonfigūruojama pačioje PagerDuty naudojant eskalavimo politiką.
Jei antrasis budintis pareigūnas neatsako, pranešimas grąžinamas atgal pagrindinis budėtojui.
Taigi bet koks gaunamas didelio prioriteto įspėjimas negali likti neapdorotas.
Dabar pažiūrėkime, iš kur gali kilti incidentų.
Kokias integracijas naudojame?
PD sulaukia daug įvairių incidentų iš įvairių tarnybų. Šiuo metu turime apie 25 tokias paslaugas ir joms apdoroti naudojame tam tikras jau paruoštas integracijas.
- Prometėjas
Pagrindinė metrikų rinkimo sistema yra Prometėjas. Apie tai Habré jau daug parašyta, tik pasakysiu, kad turime keletą jų skirtingoms aplinkoms: vienas renka metrikas iš virtualių mašinų ir dokerių, kitas – iš Amazon paslaugų, trečias – iš aparatinės įrangos. „Telegraf“ daugiausia naudojamas kaip metrikos eksportuotojas.
- El.pašto adresas*
Čia irgi, manau, viskas aišku iš pavadinimo. Ši integracija naudojama siunčiant pranešimus iš kai kurių scenarijų, kuriuos vykdo cron. PD suteikia jums tam tikrą adresą, kuriuo siunčiate laiškus. Kuriant paslaugą su tokia integracija galima nustatyti prioritetus, kokia tvarka bus apdorojami gaunami incidentai, kaip tiksliai sukurti įspėjimą (už kiekvieną gaunamą laišką, už gaunamą laišką + tam tikra taisyklė ir pan.).
- Palaidas
Mano nuomone, labai įdomi integracija. Būna atvejų, kai kažkas nutinka, bet to neapima incidentai. Todėl, norėdami sukurti incidentą, įtraukėme integraciją iš „Slack“. Tai yra, galite rašyti į „Slack“. /callofduty viskas lėtai ir greitai suges PD jį apdoros ir nusiųs įvykį budinčiam inžinieriui.
Mes darome:
Mes matome:
- API
HTTP integracija. Tiesą sakant, čia nėra nieko ypač įdomaus, tik POST užklausa su JSON formatu. Pavyzdžiui, kažkas įdomaus: mes naudojame jį išoriniam stebėjimui . Ši paslauga tikrina mūsų svetainių iš įvairių pasaulio vietų pasiekiamumą. Tuo atveju, kai gauname nepriimtiną atsakymo kodą (pvz., 502), sukuriamas incidentas ir viskas vyksta aukščiau aprašyta grandine. Pati „StatusCake“ turi galimybę stebėti vidinius URL, SSL sertifikatą ar domeno galiojimo pabaigą.
- LibreNMS
Tai dar viena stebėjimo sistema, daugiau apie ją galite pasiskaityti jų svetainėje . Jos pagalba stebime tinklo sąsajas ir iDRAC iš serverių.
Taip pat buvo tokių integracijų kaip „Datadog“, „CloudWatch“. Galite pamatyti daugiau apie tai, kas jiems nutiko .
Vizualizacija
Pagrindinė pranešimo apie incidentus sistema yra „Slack“. Visi į PD atkeliaujantys incidentai įrašomi į specialų pokalbį, o pasikeitus jų būsenai, tai taip pat rodoma pokalbyje.
Kai atsirado galimybė ant lubų kabančių monitorių ekranų atvaizduoti naudingus duomenis, staiga supratome, kad mes (devops skyriuje) neturime ką juose rodyti. Yra nuostabi Grafana, bet ji neapima visko, o darbuotojai reaguoja į įspėjimus, o ne diagramas.
Po kruopštaus, bet nesėkmingo paieškų GitHub glaustos ir informatyvios PD „lentos“, nusprendėme parašyti savo – tik su tuo, ko mums reikia. Nors iš pradžių buvo kilusi mintis rodyti pačią PD sąsają, ji atrodė dar nepatogiau.
Norėdami jį parašyti, tereikia gauti raktą iš PD su tik skaitymo teisėmis.
Štai ką mes gavome:
Ekrane rodomi dabartiniai atviri incidentai, dabartinio budinčio inžinieriaus vardas pagal pasirinktą tvarkaraštį ir laikas be didelio prioriteto incidento (skydelis su didelio prioriteto incidentu bus paryškintas raudonai).
.
Dėl to gavome patogų prietaisų skydelį, kuriame galite peržiūrėti visus mūsų incidentus. Man bus malonu, jei kai kuriems iš jūsų mūsų patirtis bus naudinga.
Šaltinis: www.habr.com