Hoe komplekser it systeem, hoe mear it wurdt oergroeid mei allerhanne warskôgings. En d'r is needsaak om te reagearjen op deselde warskôgings, se aggregearje en visualisearje. Ik tink dat dit in situaasje is dy't in protte bekend is oant it punt fan nervositeit.
De oplossing dy't sil wurde besprutsen is net de meast ûnferwachte, mar it sykjen jout gjin folweardich artikel oer dit ûnderwerp.
Dêrom besleat ik de ûnderfining fan FunCorp te dielen en te praten oer hoe't it plichtproses strukturearre is, wa't ropt, wêrom en hoe't jo it allegear kinne besjen.
Wat is PagerDuty?
Dat, om al dizze problemen op te lossen, begûnen wy te sykjen nei in handich ark. Nei wat sykjen hawwe wy keazen foar PagerDuty. PD like ús in frij folsleine en bondige oplossing te wêzen mei in grut oantal yntegraasjes en ynstellingen. Hoe is sy?
Koartsein, PagerDuty is in platfoarm foar ynsidintferwurking dat ynkommende ynsidinten kin ferwurkje fia ferskate yntegraasjes, plichtopdrachten ynstelle en dan de yngenieur op plicht warskôgje ôfhinklik fan it nivo fan it ynsidint (op in heech nivo - in oprop, op in leech nivo - in druk fan 'e applikaasje / SMS).
Wa is de tsjinstoffisier?
Dit is wierskynlik it earste plak om te begjinnen mei it opsetten fan PD.
By FunCorp is, lykas oare bedriuwen, in earefunksje fan tsjinstoffisier. It wurdt ien kear deis fan yngenieur nei yngenieur oerbrocht. Der is in saneamde earste en twadde line fan reaksje op in warskôging fan PagerDuty. Stel dat der in warskôging mei hege prioriteit komt, en as 10 minuten nei de oprop oan 'e tsjinst yngenieur fan' e earste rigel gjin reaksje is (dat wol sizze, it wurdt net oerdroegen oan 'e erkennen of oplost status), de oprop giet nei de twadde plicht yngenieur. Dit is konfigurearre yn PagerDuty sels fia Escalation Policies.
As de twadde tsjinstoffisier net reagearret, giet de notifikaasje werom nei foarnaamste oan de tsjinstoffisier.
Sa kin elke ynkommende warskôging mei hege prioriteit net ûnferwurke bliuwe.
Litte wy no sjen wêr't ynsidinten wei komme kinne.
Hokker yntegraasjes brûke wy?
PD ûntfangt in protte ferskillende ynsidinten fan ferskate tsjinsten. Wy hawwe op it stuit sa'n 25 sokke tsjinsten, en om se te ferwurkjen brûke wy wat klearmakke yntegraasjes.
- Prometheus
It wichtichste systeem foar sammeljen fan metriken is Prometheus. Der is al in protte oer skreaun op Habré, ik sil gewoan sizze dat wy ferskate fan har hawwe foar ferskate omjouwings: ien sammelet metriken fan firtuele masines en dockers, in oare fan Amazon-tsjinsten, de tredde fan hardwaremasines. Telegraf wurdt benammen brûkt as metrike eksporteur.
Ek hjir is, tinkt my, alles dúdlik út de titel. Dizze yntegraasje wurdt brûkt om notifikaasjes te stjoeren fan guon skripts útfierd troch cron. PD jout jo in bepaald adres dêr't jo brieven nei stjoere. By it meitsjen fan in tsjinst mei sa'n yntegraasje kinne jo prioriteiten ynstelle, yn hokker folchoarder ynkommende ynsidinten sille wurde ferwurke, hoe krekt in warskôging te meitsjen (foar elke ynkommende brief, foar in ynkommende brief + in bepaalde regel, ensfh.).
- slack
Neffens my in tige nijsgjirrige yntegraasje. D'r binne tiden dat der wat bart, mar net wurdt bedekt troch ynsidinten. Dêrom hawwe wy yntegraasje fan Slack tafoege om in ynsidint te meitsjen. Dat is, jo kinne skriuwe nei bedriuw Slack /callofduty alles is stadich en sil gau brekke en de PD sil it ferwurkje en it ynsidint stjoere nei de plichtingenieur.
Wy dogge:
Wy sjogge:
- API
HTTP yntegraasje. Yn feite is d'r hjir neat spesjaal ynteressant, gewoan in POST-fersyk mei in lichem yn JSON-formaat. Bygelyks, wat nijsgjirrichs: wy brûke it foar eksterne tafersjoch mei help . Dizze tsjinst kontrolearret de tagonklikens fan ús siden út ferskate dielen fan 'e wrâld. Yn it gefal as wy ûntfange in net akseptabel antwurd koade (bygelyks, 502), in ynsidint wurdt makke en dan alles folget de keten beskreaun hjirboppe. StatusCake sels hat de mooglikheid om ynterne URL's, SSL-sertifikaat of domeinferrin te kontrolearjen.
- LibreNMS
Dit is in oar monitoaringsysteem, jo kinne der mear oer lêze op har webside . Mei har help kontrolearje wy netwurkynterfaces en iDRAC fan servers.
D'r wiene ek yntegraasjes lykas Datadog, CloudWatch. Jo kinne mear sjen oer wat der mei har bard is .
Fisualisaasje
It wichtichste rapportaazjesysteem foar ynsidinten is Slack. Alle ynsidinten dy't nei PD komme, wurde skreaun nei in spesjale petear, en as har status feroaret, wurdt dit ek werjûn yn it petear.
Doe't de kâns ûntstie om nuttige gegevens te werjaan op 'e skermen fan monitors dy't oan it plafond hingje, realisearren wy ynienen dat wy (yn 'e devops-ôfdieling) neat hienen om derop te sjen. Der is in prachtige Grafana, mar it omfiemet net alles, en meiwurkers reagearje op warskôgings, net charts.
Nei in yngeande, mar mislearre sykjen op GitHub foar in bondich en ynformatyf "boerd" foar PD, besletten wy ús eigen te skriuwen - allinich mei wat wy nedich wiene. Hoewol d'r earst in idee wie om de PD-ynterface sels wer te jaan, like it noch ûngemakliker.
Om it te skriuwen, alles wat jo hoege te dwaan is in kaai te krijen fan in PD mei allinich-lêsrjochten.
En dit is wat wy krigen:
It skerm toant de aktuele iepen ynsidinten, de namme fan 'e aktuele yngenieur op plicht út it selektearre skema, en de tiid sûnder in ynsidint mei hege prioriteit (it paniel mei in ynsidint mei hege prioriteit wurdt yn read markearre).
.
As resultaat krigen wy in handich dashboard foar it besjen fan al ús ynsidinten. Ik sil bliid wêze as guon fan jo ús ûnderfining nuttich fine.
Boarne: www.habr.com