Jo mere komplekst systemet er, desto mere bliver det tilgroet med alle slags advarsler. Og der er behov for at reagere på de samme advarsler, samle dem og visualisere dem. Jeg tror, det er en situation, der er kendt for mange til nervøsitet.
Løsningen, der vil blive diskuteret, er ikke den mest uventede, men søgningen returnerer ikke en fuldgyldig artikel om dette emne.
Derfor besluttede jeg at dele FunCorps erfaring og tale om, hvordan vagtforløbet er bygget op, hvem der ringer, hvorfor og hvordan man kan se på det hele.
Hvad er PagerDuty?
Så for at løse alle disse problemer begyndte vi at lede efter et praktisk værktøj. Efter lidt søgen valgte vi PagerDuty. PD forekom os at være en ret komplet og kortfattet løsning med en lang række integrationer og indstillinger. Hvordan er hun?
Kort sagt er PagerDuty en hændelsesbehandlingsplatform, der kan behandle indgående hændelser gennem forskellige integrationer, opsætte vagtordrer og derefter advare den vagthavende ingeniør afhængigt af hændelsens niveau (på et højt niveau - et opkald, på et lavt niveau - et tryk fra applikationen / SMS).
Hvem er vagthavende?
Dette er formentlig det første sted at starte opsætningen af PD.
Hos FunCorp er der ligesom andre virksomheder en ærespost som vagthavende. Det overføres fra ingeniør til ingeniør en gang om dagen. Der er en såkaldt første og anden svarlinje på en advarsel fra PagerDuty. Antag, at en alarm med høj prioritet ankommer, og hvis der 10 minutter efter opkaldet til vagthavende tekniker fra første linje ikke er nogen reaktion på den (dvs. den overføres ikke til bekræftelses- eller løst status), går opkaldet til den anden. vagthavende ingeniør. Dette er konfigureret i selve PagerDuty gennem eskaleringspolitikker.
Hvis den anden vagthavende ikke reagerer, vender meddelelsen tilbage til vigtigste til vagthavende.
En indkommende alarm med høj prioritet kan således ikke forblive ubehandlet.
Lad os nu se, hvor hændelser kan komme fra.
Hvilke integrationer bruger vi?
PD modtager mange forskellige hændelser fra forskellige tjenester. Vi har i øjeblikket omkring 25 sådanne tjenester, og til at behandle dem bruger vi nogle færdige integrationer.
- Prometheus
Det vigtigste indsamlingssystem for metrik er Prometheus. Der er allerede skrevet meget om det på Habré, jeg vil bare sige, at vi har flere af dem til forskellige miljøer: en indsamler metrics fra virtuelle maskiner og dockers, en anden fra Amazon-tjenester, den tredje fra hardware-maskiner. Telegraf bruges hovedsageligt som metrikeksportør.
Også her, synes jeg, fremgår alt af titlen. Denne integration bruges til at sende meddelelser fra nogle scripts udført af cron. PD giver dig en bestemt adresse, som du sender breve til. Når du opretter en tjeneste med en sådan integration, kan du sætte prioriteter, i hvilken rækkefølge indgående hændelser vil blive behandlet, hvordan man præcist opretter en advarsel (for hvert indgående brev, for et indgående brev + en bestemt regel osv.).
- Slack
Efter min mening en meget interessant integration. Der er tidspunkter, hvor der sker noget, men ikke er dækket af hændelser. Derfor tilføjede vi integration fra Slack for at skabe en hændelse. Det vil sige, at du kan skrive til virksomhedens Slack /callofduty alt er langsomt og vil snart gå i stykker og PD vil behandle det og sende hændelsen til vagthavende ingeniør.
Det gør vi:
Vi ser:
- API
HTTP integration. Faktisk er der ikke noget særligt interessant her, bare en POST-anmodning med en krop i JSON-format. For eksempel noget interessant: vi bruger det til ekstern overvågning ved hjælp af . Denne service kontrollerer tilgængeligheden af vores websteder fra forskellige dele af verden. I det tilfælde, hvor vi modtager en uacceptabel svarkode (f.eks. 502), oprettes en hændelse, og så følger alt kæden beskrevet ovenfor. StatusCake har selv mulighed for at overvåge interne URL'er, SSL-certifikat eller domæneudløb.
- LibreNMS
Dette er endnu et overvågningssystem, du kan læse mere om det på deres hjemmeside . Med dens hjælp overvåger vi netværksgrænseflader og iDRAC fra servere.
Der var også integrationer som Datadog, CloudWatch. Du kan se mere om, hvad der skete med dem .
Visualisering
Det vigtigste hændelsesrapporteringssystem er Slack. Alle hændelser, der kommer til PD, skrives til en særlig chat, og hvis deres status ændres, vises dette også i chatten.
Da muligheden opstod for at vise nyttige data på skærmene på skærme, der hang fra loftet, indså vi pludselig, at vi (i devops-afdelingen) ikke havde noget at vise på dem. Der er en vidunderlig Grafana, men den dækker ikke alt, og medarbejderne reagerer på advarsler, ikke diagrammer.
Efter en grundig, men mislykket søgning på GitHub efter en kortfattet og informativ "board" til PD, besluttede vi at skrive vores egen - kun med det, vi havde brug for. Selvom der først var en idé om at vise selve PD-grænsefladen, så det endnu mere ubelejligt ud.
For at skrive den skal du blot få en nøgle fra en PD med skrivebeskyttede rettigheder.
Og dette er hvad vi fik:
Skærmen viser de aktuelle åbne hændelser, navnet på den aktuelle vagthavende ingeniør fra den valgte tidsplan og tiden uden en høj prioritet hændelse (panelet med en høj prioritet hændelse vil blive fremhævet med rødt).
.
Som et resultat modtog vi et praktisk dashboard til at se alle vores hændelser. Jeg vil blive glad, hvis nogle af jer finder vores erfaring nyttig.
Kilde: www.habr.com