Mitä monimutkaisempi järjestelmä, sitä enemmän se peittyy kaikenlaisilla hälytyksillä. Ja näihin samoihin hälytyksiin on reagoitava, ne on yhdistettävä ja visualisoitava. Luulen, että tämä on monille hermostuneisuuteen asti tuttu tilanne.
Ratkaisu, josta keskustellaan, ei ole odottamattomin, mutta haku ei palauta täysimittaista artikkelia tästä aiheesta.
Siksi päätin jakaa FunCorpin kokemuksen ja puhua siitä, miten päivystysprosessi rakentuu, kuka soittaa, miksi ja miten sitä kaikkea voi tarkastella.
Mikä on PagerDuty?
Joten kaikkien näiden ongelmien ratkaisemiseksi aloimme etsiä kätevää työkalua. Pienen etsinnän jälkeen valitsimme PagerDutyn. PD vaikutti meistä melko täydelliseltä ja ytimekkäältä ratkaisulta, jossa oli paljon integraatioita ja asetuksia. Millainen hän on?
Lyhyesti sanottuna PagerDuty on tapausten käsittelyalusta, joka voi käsitellä saapuvia tapauksia erilaisten integraatioiden avulla, asettaa päivystyskäskyjä ja sitten hälyttää päivystävälle insinöörille tapahtuman tasosta riippuen (korkealla tasolla - puhelu, matalalla - push sovelluksesta / SMS) .
Kuka on päivystäjä?
Tämä on luultavasti ensimmäinen paikka aloittaa PD:n määrittäminen.
FunCorpilla, kuten muillakin yrityksillä, on päivystäjän kunniatehtävä. Se välitetään insinööriltä insinöörille kerran päivässä. PagerDutyn hälytyksiin vastataan niin sanotulla ensimmäisellä ja toisella rivillä. Oletetaan, että korkean prioriteetin hälytys saapuu, ja jos 10 minuutin kuluttua ensimmäiseltä linjalta päivystäjälle soiton jälkeen siihen ei reagoida (eli sitä ei siirretä kuittaus- tai ratkaistu-tilaan), puhelu siirtyy toiseen. päivystävä insinööri. Tämä määritetään itse PagerDutyssa eskalointikäytäntöjen kautta.
Jos toinen päivystäjä ei vastaa, ilmoitus palaa takaisin pää päivystäjälle.
Siten mikään saapuva korkean prioriteetin hälytys ei voi jäädä käsittelemättä.
Katsotaan nyt, mistä tapahtumat voivat johtua.
Mitä integraatioita käytämme?
PD vastaanottaa monia erilaisia tapauksia eri palveluilta. Meillä on tällä hetkellä noin 25 tällaista palvelua, joiden käsittelyyn käytämme valmiita integraatioita.
- Prometheus
Pääasiallinen mittausjärjestelmä on Prometheus. Siitä on kirjoitettu jo paljon Habressa, sanon vain, että meillä on niitä useita eri ympäristöihin: yksi kerää mittareita virtuaalikoneen ja telakointiaseman kautta, toinen Amazon-palveluista, kolmas laitteistokoneista. Telegrafia käytetään pääasiassa mittarien viejänä.
- Sähköposti
Tässäkin mielestäni kaikki on selvää otsikosta. Tätä integraatiota käytetään lähettämään ilmoituksia joistakin cronin suorittamista komentosarjoista. PD antaa sinulle tietyn osoitteen, johon lähetät kirjeitä. Kun luot palvelua tällaisella integraatiolla, voit asettaa prioriteetteja, missä järjestyksessä saapuvat tapahtumat käsitellään, kuinka tarkkaan luodaan hälytys (jokaiselle saapuvalle kirjeelle, saapuvalle kirjeelle + tietty sääntö jne.).
- New Rose Hotel
Minusta erittäin mielenkiintoinen integraatio. Joskus tapahtuu, mutta tapahtumat eivät kata sitä. Siksi lisäsimme Slackin integroinnin tapauksen luomiseksi. Eli voit kirjoittaa yritys Slackiin /callofduty kaikki on hidasta ja hajoaa pian ja PD käsittelee sen ja lähettää tapahtuman päivystäjälle.
Me teemme:
Me näemme:
- API
HTTP-integraatio. Itse asiassa tässä ei ole mitään erityisen mielenkiintoista, vain POST-pyyntö, jonka runko on JSON-muodossa. Esimerkiksi jotain mielenkiintoista: käytämme sitä ulkoiseen seurantaan käyttämällä . Tämä palvelu tarkistaa sivustojemme saavutettavuuden eri puolilta maailmaa. Siinä tapauksessa, että saamme kelpaamattoman vastauskoodin (esimerkiksi 502), syntyy tapahtuma ja sitten kaikki seuraa yllä kuvattua ketjua. StatusCake itse pystyy valvomaan sisäisiä URL-osoitteita, SSL-varmennetta tai verkkotunnuksen vanhenemista.
- FreeNMS
Tämä on toinen seurantajärjestelmä, voit lukea siitä lisää heidän verkkosivuillaan . Sen avulla valvomme verkkorajapintoja ja iDRACia palvelimilta.
Mukana oli myös integraatioita, kuten Datadog, CloudWatch. Voit nähdä enemmän siitä, mitä heille tapahtui .
Visualisointi
Pääasiallinen tapahtumaraportointijärjestelmä on Slack. Kaikki PD:hen tulevat tapahtumat kirjoitetaan erityiseen chattiin, ja jos niiden tila muuttuu, se näkyy myös chatissa.
Kun tuli tilaisuus näyttää hyödyllistä dataa katosta roikkuvien monitorien näytöillä, tajusimme yhtäkkiä, ettei meillä (devops-osastolla) ollut mitään näytettävää niissä. Siellä on upea Grafana, mutta se ei kata kaikkea, ja työntekijät reagoivat hälytyksiin, eivät kaavioihin.
Kun etsimme GitHubista perusteellista mutta epäonnistunutta tiivistä ja informatiivista "taulua" PD:tä varten, päätimme kirjoittaa oman - vain sen, mitä tarvitsimme. Vaikka aluksi oli ajatus näyttää itse PD-käyttöliittymä, se näytti vieläkin hankalammalta.
Kirjoittaaksesi sen, sinun tarvitsee vain hankkia avain PD:ltä, jolla on vain lukuoikeudet.
Ja tämän saimme:
Näytöllä näkyvät nykyiset avoimet tapahtumat, valitun aikataulun mukaan päivystävän nykyisen insinöörin nimi ja aika ilman korkean prioriteetin tapahtumaa (paneeli, jossa on korkean prioriteetin tapahtuma, on korostettu punaisella).
.
Tuloksena saimme kätevän kojelaudan, josta voit tarkastella kaikkia tapauksiamme. Olen iloinen, jos joku teistä kokee kokemuksemme hyödylliseksi.
Lähde: will.com