Jo mer komplekst systemet er, jo mer blir det overgrodd med alle slags varsler. Og det er behov for å reagere på de samme varslene, samle dem og visualisere dem. Jeg tror dette er en situasjon som er kjent for mange til nervøsitet.
Løsningen som vil bli diskutert er ikke den mest uventede, men søket returnerer ikke en fullverdig artikkel om dette emnet.
Derfor bestemte jeg meg for å dele FunCorps erfaring og snakke om hvordan vaktprosessen er strukturert, hvem som ringer, hvorfor og hvordan du kan se på det hele.
Hva er PagerDuty?
Så for å løse alle disse problemene begynte vi å lete etter et praktisk verktøy. Etter litt leting valgte vi PagerDuty. PD syntes for oss å være en ganske komplett og kortfattet løsning med et stort antall integrasjoner og innstillinger. Hvordan er hun?
Kort fortalt er PagerDuty en hendelsesbehandlingsplattform som kan behandle innkommende hendelser gjennom ulike integrasjoner, sette opp vaktordrer og deretter varsle vakthavende ingeniør avhengig av nivået på hendelsen (på et høyt nivå - en samtale, på et lavt nivå - et trykk fra applikasjonen / SMS).
Hvem er vaktleder?
Dette er sannsynligvis det første stedet å begynne å sette opp PD.
Hos FunCorp er det, i likhet med andre selskaper, en æresstilling som vaktleder. Det overføres fra ingeniør til ingeniør en gang om dagen. Det er en såkalt første og andre linje med respons på et varsel fra PagerDuty. Anta at et varsel med høy prioritet kommer, og hvis det 10 minutter etter anropet til vakthavende fra første linje ikke er noen reaksjon på det (dvs. det er ikke overført til bekreftelses- eller løst-status), går anropet til den andre vakthavende ingeniør. Dette er konfigurert i selve PagerDuty gjennom eskaleringspolicyer.
Hvis den andre vakthavende ikke svarer, går meldingen tilbake til hoved- til vakthavende.
Dermed kan ikke innkommende høyprioritetsvarsler forbli ubehandlet.
La oss nå se hvor hendelser kan komme fra.
Hvilke integrasjoner bruker vi?
PD mottar mange ulike hendelser fra ulike tjenester. Vi har i dag ca 25 slike tjenester, og for å behandle dem bruker vi noen ferdige integrasjoner.
- Prometheus
Det viktigste innsamlingssystemet for beregninger er Prometheus. Det er allerede skrevet mye om det på Habré, jeg vil bare si at vi har flere av dem for forskjellige miljøer: en samler inn beregninger fra virtuelle maskiner og dockers, en annen fra Amazon-tjenester, den tredje fra maskinvaremaskiner. Telegraf brukes hovedsakelig som metrikkeksportør.
- Epost
Også her synes jeg alt er klart av tittelen. Denne integrasjonen brukes til å sende varsler fra enkelte skript utført av cron. PD gir deg en bestemt adresse du sender brev til. Når du oppretter en tjeneste med slik integrasjon, kan du angi prioriteringer, i hvilken rekkefølge innkommende hendelser skal behandles, hvordan du nøyaktig oppretter et varsel (for hvert innkommende brev, for et innkommende brev + en bestemt regel osv.).
- Slack
Etter min mening en veldig interessant integrasjon. Det er tider når noe skjer, men ikke dekkes av hendelser. Derfor la vi til integrasjon fra Slack for å lage en hendelse. Det vil si at du kan skrive til bedriftens Slack /callofduty alt er tregt og vil gå i stykker snart og PD vil behandle den og sende hendelsen til vakthavende ingeniør.
Vi gjør:
Vi ser:
- API
HTTP-integrasjon. Faktisk er det ikke noe spesielt interessant her, bare en POST-forespørsel med en body i JSON-format. For eksempel noe interessant: vi bruker det til ekstern overvåking ved hjelp av . Denne tjenesten sjekker tilgjengeligheten til nettstedene våre fra forskjellige deler av verden. I tilfellet når vi mottar en uakseptabel svarkode (for eksempel 502), opprettes en hendelse og deretter følger alt kjeden beskrevet ovenfor. StatusCake har selv muligheten til å overvåke interne URL-er, SSL-sertifikat eller domeneutløp.
- LibreNMS
Dette er et annet overvåkingssystem, du kan lese mer om det på nettsiden deres . Med dens hjelp overvåker vi nettverksgrensesnitt og iDRAC fra servere.
Det var også integrasjoner som Datadog, CloudWatch. Du kan se mer om hva som skjedde med dem .
Visualisering
Hovedhendelsesrapporteringssystemet er Slack. Alle hendelser som kommer til PD skrives til en spesiell chat, og dersom status endres vises dette også i chatten.
Da muligheten dukket opp for å vise nyttige data på skjermene til monitorer som henger i taket, innså vi plutselig at vi (i devops-avdelingen) ikke hadde noe å vise på dem. Det er en fantastisk Grafana, men den dekker ikke alt, og ansatte reagerer på varsler, ikke diagrammer.
Etter et grundig, men mislykket søk på GitHub etter en kortfattet og informativ "tavle" for PD, bestemte vi oss for å skrive vår egen - bare med det vi trengte. Selv om det først var en idé om å vise selve PD-grensesnittet, så det enda mer upraktisk ut.
For å skrive det, er alt du trenger å gjøre å få en nøkkel fra en PD med skrivebeskyttede rettigheter.
Og dette er hva vi fikk:
Skjermen viser gjeldende åpne hendelser, navnet på gjeldende ingeniør på vakt fra den valgte tidsplanen, og tiden uten høy prioritet hendelse (panelet med høy prioritet hendelse vil være uthevet i rødt).
.
Som et resultat mottok vi et praktisk dashbord for å se alle hendelsene våre. Jeg vil bli glad hvis noen av dere finner vår erfaring nyttig.
Kilde: www.habr.com