Sa më kompleks të jetë sistemi, aq më shumë bëhet i tejmbushur me të gjitha llojet e sinjalizimeve. Dhe ka nevojë për të reaguar ndaj të njëjtave sinjalizime, për t'i grumbulluar dhe për t'i vizualizuar ato. Mendoj se kjo është një situatë e njohur për shumë njerëz deri në nervozizëm.
Zgjidhja që do të diskutohet nuk është më e papritura, por kërkimi nuk kthen një artikull të plotë për këtë temë.
Prandaj, vendosa të ndaj përvojën e FunCorp dhe të flas se si është strukturuar procesi i detyrës, kush telefonon, pse dhe si mund t'i shikoni të gjitha.
Çfarë është PagerDuty?
Pra, për të zgjidhur të gjitha këto probleme, filluam të kërkojmë një mjet të përshtatshëm. Pas disa kërkimeve, ne zgjodhëm PagerDuty. PD na dukej si një zgjidhje mjaft e plotë dhe koncize me një numër të madh integrimesh dhe cilësimesh. Si është ajo?
Shkurtimisht, PagerDuty është një platformë për përpunimin e incidenteve që mund të përpunojë incidentet hyrëse përmes integrimeve të ndryshme, të vendosë urdhra detyrash dhe më pas të paralajmërojë inxhinierin në detyrë në varësi të nivelit të incidentit (në një nivel të lartë - një thirrje, në një nivel të ulët - një shtytje nga aplikacioni / SMS).
Kush është nëpunësi i detyrës?
Ky është ndoshta vendi i parë për të filluar ngritjen e PD.
Në FunCorp, si kompanitë e tjera, ka një pozicion nderi të oficerit të detyrës. Ai transmetohet nga inxhinieri në inxhinier një herë në ditë. Ekziston një e ashtuquajtur linjë e parë dhe e dytë e përgjigjes ndaj një alarmi nga PagerDuty. Supozoni se vjen një alarm me prioritet të lartë, dhe nëse 10 minuta pas thirrjes së oficerit të shërbimit nga linja e parë nuk ka asnjë reagim ndaj tij (d.m.th., nuk transferohet në statusin e njohjes ose të zgjidhjes), thirrja shkon tek e dyta. inxhinier i detyrës. Kjo është konfiguruar në vetë PagerDuty përmes Politikave të Përshkallëzimit.
Nëse oficeri i dytë i detyrës nuk përgjigjet, njoftimi kthehet përsëri në kryesore tek oficeri i detyrës.
Kështu, çdo sinjalizim me prioritet të lartë nuk mund të mbetet i papërpunuar.
Tani le të shohim se nga mund të vijnë incidentet.
Çfarë integrimesh përdorim?
PD merr shumë incidente të ndryshme nga shërbime të ndryshme. Aktualisht kemi rreth 25 shërbime të tilla dhe për t'i përpunuar ato përdorim disa integrime të gatshme.
- Prometeu
Sistemi kryesor i mbledhjes së metrikës është Prometheus. Tashmë është shkruar shumë për të në Habré, do të them vetëm se ne kemi disa prej tyre për mjedise të ndryshme: njëri mbledh metrikë nga makinat virtuale dhe dokerët, tjetri nga shërbimet e Amazon, i treti nga makinat harduerike. Telegraf përdoret kryesisht si eksportues metrikë.
Edhe këtu mendoj se gjithçka është e qartë nga titulli. Ky integrim përdoret për të dërguar njoftime nga disa skripte të ekzekutuara nga cron. PD ju jep një adresë të caktuar në të cilën dërgoni letra. Kur krijoni një shërbim me një integrim të tillë, mund të vendosni përparësitë, në çfarë rendi do të përpunohen incidentet hyrëse, si të krijoni saktësisht një alarm (për secilën letër hyrëse, për një letër hyrëse + një rregull të caktuar, etj.).
- I plogët
Për mendimin tim, një integrim shumë interesant. Ka raste kur diçka ndodh por nuk mbulohet nga incidente. Prandaj, ne shtuam integrimin nga Slack për të krijuar një incident. Kjo do të thotë, ju mund t'i shkruani korporatës Slack /callofduty gjithçka është e ngadaltë dhe do të prishet së shpejti dhe PD do ta përpunojë dhe do t'ia dërgojë incidentin inxhinierit të shërbimit.
Ne bejme:
Ne shohim:
- API
Integrimi HTTP. Në fakt, nuk ka asgjë veçanërisht interesante këtu, vetëm një kërkesë POST me një trup në formatin JSON. Për shembull, diçka interesante: ne e përdorim atë për monitorim të jashtëm duke përdorur . Ky shërbim kontrollon aksesin e faqeve tona nga pjesë të ndryshme të botës. Në rastin kur marrim një kod përgjigjeje të papranueshme (për shembull, 502), krijohet një incident dhe më pas gjithçka ndjek zinxhirin e përshkruar më sipër. Vetë StatusCake ka aftësinë të monitorojë URL-të e brendshme, certifikatën SSL ose skadimin e domenit.
- LibreNMS
Ky është një tjetër sistem monitorimi, ju mund të lexoni më shumë rreth tij në faqen e tyre të internetit . Me ndihmën e tij, ne monitorojmë ndërfaqet e rrjetit dhe iDRAC nga serverët.
Kishte edhe integrime si Datadog, CloudWatch. Ju mund të shihni më shumë se çfarë ndodhi me ta .
Vizualizimi
Sistemi kryesor i raportimit të incidenteve është Slack. Të gjitha incidentet që vijnë në PD shkruhen në një bisedë të veçantë dhe nëse statusi i tyre ndryshon, kjo shfaqet edhe në chat.
Kur u krijua mundësia për të shfaqur të dhëna të dobishme në ekranet e monitorëve të varur nga tavani, papritmas kuptuam se ne (në departamentin e devops) nuk kishim asgjë për të shfaqur në to. Ka një Grafana të mrekullueshme, por nuk mbulon gjithçka, dhe punonjësit reagojnë ndaj sinjalizimeve, jo grafikëve.
Pas një kërkimi të plotë, por të pasuksesshëm në GitHub për një "bord" konciz dhe informues për PD, vendosëm të shkruanim tonën - vetëm me atë që na nevojitej. Edhe pse në fillim kishte një ide për të shfaqur vetë ndërfaqen PD, ajo dukej edhe më e papërshtatshme.
Për ta shkruar atë, gjithçka që duhet të bëni është të merrni një çelës nga një PD me të drejta vetëm për lexim.
Dhe kjo është ajo që kemi:
Ekrani shfaq incidentet aktuale të hapura, emrin e inxhinierit aktual në detyrë nga orari i zgjedhur dhe kohën pa një incident me përparësi të lartë (paneli me një incident me përparësi të lartë do të theksohet me të kuqe).
.
Si rezultat, ne morëm një panel të përshtatshëm për të parë të gjitha incidentet tona. Do të jem i lumtur nëse disa prej jush do ta kenë të dobishme përvojën tonë.
Burimi: www.habr.com