Mida keerulisem on süsteem, seda rohkem see kogub igasuguseid häireid. Ja tekib vajadus nendele häiretele reageerida, neid koondada ja visualiseerida. Arvan, et see olukord on paljudele tuttav ja võib tekitada närvilist tiksumist.
Teema, millest jutt käib, ei ole kõige ootamatum, kuid selle kohta ei leia päris terviklikku artiklit.
Seetõttu otsustasin jagada FunCorpi kogemust ja rääkida, kuidas hädaliste tööprotsess on üles seatud, kes helistab, miks ja kuidas sellele kõigile vaadata.
Mis on PagerDuty?
Nii et nende ülesannete lahendamiseks hakkasime otsima mugavat tööriista. Pärast lühikest otsingut valisime PagerDuty. PD tundus meile piisavalt põhjaliku ja lühidalt esitatud lahendusena suure hulga integratsioonide ja seadistustega. Mis see tegelikult on?
Lühidalt, PagerDuty on intsidendi haldamise platvorm, mis oskab hallata saabunud intsidente erinevate integratsioonide kaudu, seadistada ööpäevaringsete töötajate vahetuste järjekorra ja edastada häire džeensõnumi insenerile vastavalt intsidendi tasemele (kõrge taseme korral helistamine, madala taseme korral rakenduse kaudu push-teade/või SMS).
Kes on ööpäevaringset töötaja?
Võib-olla on see esimene asi, millega PD seadistamine alustada.
FunCorpis, nagu teisteski ettevõtetes, on auametina dežuurimise ametikohad. Need antakse insenerilt insenerile üle iga päev. On olemas nn esimene ja teine tasand, mis reageerib PagerDuty häiretetele. Eeldame, et tuleb kõrge prioriteediga häire, ja kui 10 minuti jooksul pärast esimese tasandi dežuurimise inseneriga helistamist ei ole reageeringut (s.t. seda ei ole muudetud staatuseks acknowledge või resolved), siis läheb kõne teisele dežuurile insenerile. Seda seadistatakse otse PagerDuty's Escalation Policies kaudu.
Kui ka teine dežuur ei reageeri, siis teavitamine naaseb peadežuurile. Nii ei saa ükski tulev häire kõrge prioriteediga jääda tähelepanuta.
Nüüd vaatame, kust võivad tulla juhtumid.
Milliseid integratsioone kasutame?
PD-sse tuleb palju erinevaid juhtumeid erinevatelt teenustelt. Praegu on meil neid teenuseid umbes 25, ja nende töötlemiseks kasutame mõned valmis integratsioonid.
PD-s esinevad hulgaliselt erinevaid sündmusi erinevatelt teenustelt. Praegu on meil selliseid teenuseid umbes 25 ja nende töötlemiseks kasutame mõned valmis integratsioonid.
- Prometheus
Peamine meetrikate kogumise süsteem on Prometheus. Selle kohta on juba palju kirjutatud Habr's, ütlen vaid, et meil on neid mitu erinevate keskkondade jaoks: üks kogub meetrikat virtuaalmasinatelt ja konteineritelt, teine - Amazon'i teenustelt, kolmas - 'raudmasinatelt'. Peamiselt kasutatakse meetrikate eksportimiseks Telegrafi.
Siin, arvan, on kõik nimest selge. Seda integratsiooni kasutatakse teatud skriptide saadetiste edastamiseks, mis toimuvad cron'i järgi. PD annab teile teatud aadressi, kuhu sa saadate kirju. Kui loote teenuse sellise integratsiooniga, saate häälestada prioriteedid, millises järjekorras töödeldakse sissetulevaid sündmusi, ning kuidas täpselt alert'i luua (iga saabuva kirja jaoks, saabuvale kirjale + mingi reegel jne).
- Slack
Minu arvates on see väga huvitav integratsioon. On juhtumeid, kus toimub midagi, kuid see ei kata sündmusi. Seetõttu lisasime Slack'i integratsiooni sündmuse loomiseks. See tähendab, et ettevõtte Slack'is saad kirjutada /callofduty все тормозит и скоро сломается ja PD töötleb seda ning saadab sündmuse valveinsenerile.
Teeme:
Näeme:
- API
HTTP integreerimine. Siin ei ole tegelikult midagi huvitavat, lihtsalt POST-päring JSON-formaadis. Näiteks huvitav on see, et kasutame seda väliste jälgimiste tegemiseks . See teenus kontrollib meie veebisaitide kättesaadavust erinevatest maailmapunktidest. Kui saame vastuvõetamatud vastuskoodid (näiteks 502), siis luuakse juhtum ja kõik jätkub eelnevalt kirjeldatud ahelas. StatusCake'is on võimalik jälgida ka sisemisi URL-e, SSL-sertifikaadi või domeeni aegumist.
- LibreNMS
See on veel üks jälgimissüsteem, rohkem selle kohta saab lugeda nende veebisaidilt . Selle abil teostame võrguliideste ja iDRAC-i jälgimist serveritest.
Oli ka selliseid integreerimisi nagu Datadog, CloudWatch. Üksikasju selle kohta, mis nendega juhtus, saab vaadata .
Visualiseerimine
Peamine teavitamissüsteem juhtumitest on Slack. Erilistesse kanalitesse kirjutatakse kõik PD-sse saabuvad juhtumid ning kui nende seisund muutub, kajastub see ka kanalites.
Kui tekkis võimalus kuvada kasulikke andmeid lael rippuvate monitoride ekraanidele, mõistsime äkki, et meil (devops-osakonnas) pole midagi, mida sinna kuvada. Grafana on suurepärane, aga see ei ulatu kõike katma, lisaks reageerivad töötajad häiretele, mitte diagrammidele.
Pärast põhjalikku, kuid ebaõnnestunud otsingut GitHubis lakoonilise ja informatiivse PD „board’i” jaoks, otsustasime kirjutada oma — ainult selle, mis on vajalik meile. Kuigi alguses oli mõte kuvada ekraanil PD enda kasutajaliidest, tundus see veelgi ebamugavam.
Selle kirjutamiseks piisab ainult PD lugemisõiguseta võtme saamisest.
Ja siin on, mis meil välja tuli:
Ekraanile kuvatakse aktuaalsed avatud juhtumid, valitud graafikust praeguse vahetuse inseneri nimi ning kõrge prioriteediga juhtu ilma, et see jääks nähtamatuks (kõrge prioriteedi juhtumi paneel on esile tõstetud punase värviga).
.
Kokkuvõttes saime mugava armatuurlauale kõigi meie juhtumite uurimiseks. Olen rõõmus, kui meie kogemus saab kellelegi kasuks tulla.
Allikas: habr.com
