Mit navn er Anton Baderin. Jeg arbejder på Højteknologicentret og laver systemadministration. For en måned siden sluttede vores virksomhedskonference, hvor vi delte vores akkumulerede erfaring med it-samfundet i vores by. Jeg talte om overvågning af webapplikationer. Materialet var beregnet til junior- eller mellemniveau, som ikke byggede denne proces fra bunden.
Hjørnestenen bag ethvert overvågningssystem er løsning af forretningsproblemer. Overvågning for overvågningens skyld er ikke interessant for nogen. Hvad vil erhvervslivet? Så alt fungerer hurtigt og uden fejl. Virksomheder ønsker at være proaktive, så vi selv identificerer problemer i servicen og løser dem hurtigst muligt. Det er faktisk de problemer, som jeg løste hele sidste år på et projekt for en af vores kunder.
cirka
Projektet er et af de største loyalitetsprogrammer i landet. Vi hjælper detailkæder med at øge salgsfrekvensen gennem forskellige marketingværktøjer såsom bonuskort. I alt omfatter projektet 14 applikationer, der kører på ti servere.
Under interviewprocessen bemærkede jeg gentagne gange, at administratorer ikke altid griber overvågning af webapplikationer korrekt an: mange fokuserer stadig på operativsystemmålinger og overvåger af og til tjenester.
I mit tilfælde var kundens overvågningssystem tidligere baseret på Icinga. Det løste ikke ovenstående problemer på nogen måde. Ofte informerede klienten os selv om problemer, og som oftest havde vi simpelthen ikke nok data til at komme til bunds i årsagen.
Derudover var der en klar forståelse af nytteløsheden af dens videre udvikling. Jeg tror, at de, der er fortrolige med Icinga, vil forstå mig. Så vi besluttede os for fuldstændigt at omdesigne webapplikationsovervågningssystemet til projektet.
Prometheus
Vi valgte Prometheus baseret på tre hovedindikatorer:
- Et stort antal tilgængelige metrics. I vores tilfælde er der 60 tusinde af dem. Det er selvfølgelig værd at bemærke, at vi ikke bruger langt de fleste af dem (sandsynligvis omkring 95%). Til gengæld er de alle relativt billige. For os er dette den anden yderlighed sammenlignet med den tidligere brugte Icinga. I det var det en særlig smerte at tilføje metrics: de eksisterende var dyre (se bare på kildekoden for ethvert plugin). Ethvert plugin var et script i Bash eller Python, hvis lancering er dyrt i forhold til ressourceforbrug.
- Dette system bruger en relativt lille mængde ressourcer. 600 MB RAM, 15 % af en kerne og et par dusin IOPS er nok til alle vores målinger. Selvfølgelig skal du køre metrics eksportører, men de er alle skrevet i Go og er heller ikke særlig strømkrævende. Jeg tror ikke, at dette i moderne virkelighed er et problem.
- Giver mulighed for at migrere til Kubernetes. I betragtning af kundens planer er valget oplagt.
ELK
Tidligere har vi ikke indsamlet eller behandlet logfiler. Manglerne er tydelige for enhver. Vi valgte ELK, fordi vi allerede havde erfaring med dette system. Vi gemmer kun applikationslogfiler der. De vigtigste udvælgelseskriterier var fuldtekstsøgning og dens hastighed.
Klikhus
I første omgang faldt valget på InfluxDB. Vi indså behovet for at indsamle Nginx-logfiler, statistik fra pg_stat_statements og gemme Prometheus historiske data. Vi kunne ikke lide Influx, fordi det med jævne mellemrum begyndte at forbruge en stor mængde hukommelse og styrtede ned. Derudover ville jeg gruppere forespørgsler efter remote_addr, men gruppering i dette DBMS er kun efter tags. Tags er dyre (hukommelse), deres antal er betinget begrænset.
Vi startede vores søgen igen. Det, der skulle til, var en analytisk database med minimalt ressourceforbrug, gerne med datakomprimering på disk.
Clickhouse opfylder alle disse kriterier, og vi har aldrig fortrudt vores valg. Vi skriver ikke nogen ekstraordinære mængder data ind i den (antallet af indsættelser er kun omkring fem tusinde i minuttet).
NewRelic
NewRelic har historisk set været med os, fordi det var kundens valg. Vi bruger det som en APM.
Zabbix
Vi bruger udelukkende Zabbix til at overvåge Black Box af forskellige API'er.
Definition af en overvågningsmetode
Vi ønskede at nedbryde opgaven og dermed systematisere tilgangen til overvågning.
For at gøre dette opdelte jeg vores system i følgende niveauer:
- hardware og VMS;
- operativ system;
- systemtjenester; softwarestabel;
- Ansøgning;
- forretningslogik.
Hvorfor denne tilgang er praktisk:
- vi ved, hvem der er ansvarlig for arbejdet på hvert niveau, og på baggrund af dette kan vi sende alarmer;
- vi kan bruge strukturen, når vi undertrykker advarsler - det ville være mærkeligt at sende en advarsel om database utilgængelighed, når den virtuelle maskine som helhed ikke er tilgængelig.
Da vores opgave er at identificere overtrædelser i driften af systemet, skal vi på hvert niveau fremhæve et bestemt sæt målinger, som er værd at være opmærksomme på, når man skriver varslingsregler. Lad os derefter gennemgå niveauerne "VMS", "Operativsystem" og "Systemtjenester, softwarestak".
Virtuelle maskiner
Hosting tildeler os en processor, disk, hukommelse og netværk. Og vi havde problemer med de to første. Så metrics:
CPU stjålet tid - når du køber en virtuel maskine på Amazon (t2.micro, for eksempel), bør du forstå, at du ikke er tildelt en hel processorkerne, men kun en kvote af dens tid. Og når du udtømmer den, vil processoren blive taget fra dig.
Denne metrik giver dig mulighed for at spore sådanne øjeblikke og træffe beslutninger. Er det for eksempel nødvendigt at tage en federe takst eller distribuere behandlingen af baggrundsopgaver og API-anmodninger til forskellige servere?
IOPS + CPU ventetid - af en eller anden grund synder mange cloud-hostings ved ikke at levere nok IOPS. Desuden er et skema med lav IOPS ikke et argument for dem. Derfor er det værd at samle CPU iowait. Med dette par af grafer - med lav IOPS og høj I/O-ventetid - kan du allerede nu tale med hostingen og løse problemet.
Operativsystem
Operativsystem-metrics:
- mængden af tilgængelig hukommelse i %;
- swap-brugsaktivitet: vmstat swapin, swapout;
- antal tilgængelige inoder og ledig plads på filsystemet i %
- gennemsnitlig belastning;
- antal forbindelser i to tilstand;
- conntrack tabellen fylde;
- Kvaliteten af netværket kan overvåges ved hjælp af ss-værktøjet, iproute2-pakken - få en indikator for RTT-forbindelser fra dets output, og grupper det efter destport.
Også på styresystemniveau har vi sådan en enhed som processer. Det er vigtigt at identificere et sæt processer i systemet, der spiller en vigtig rolle i dets drift. Hvis du for eksempel har flere pgpools, så skal du indsamle oplysninger for hver af dem.
Sættet af metrics er som følger:
- CPU'er;
- hukommelsen er primært hjemmehørende;
- IO - helst i IOPS;
- FileFd - åben og begræns;
- betydelige sidefejl - på denne måde kan du forstå, hvilken proces der bliver byttet om.
Vi implementerer al overvågning i Docker, og vi bruger Advisor til at indsamle metriske data. På andre maskiner bruger vi proces-eksportør.
Systemtjenester, softwarestak
Hver applikation har sine egne specifikationer, og det er svært at udskille et specifikt sæt af metrikker.
Det universelle sæt er:
- anmodning sats;
- antal fejl;
- reaktionstid;
- mætning.
Vores mest slående eksempler på overvågning på dette niveau er Nginx og PostgreSQL.
Den mest indlæste service i vores system er databasen. Tidligere havde vi ofte problemer med at finde ud af, hvad databasen lavede.
Vi så en høj belastning på diskene, men de langsomme logfiler viste ikke rigtig noget. Vi løste dette problem ved hjælp af pg_stat_statements, en visning, der indsamler forespørgselsstatistik.
Det er alt, hvad admin har brug for.
Vi bygger grafer over aktiviteten af læse- og skriveanmodninger:
Alt er enkelt og klart, hver anmodning har sin egen farve.
Et lige så slående eksempel er Nginx-logfiler. Det er ikke overraskende, at få mennesker analyserer dem eller nævner dem på listen over must-haves. Standardformatet er ikke særlig informativt og skal udvides.
Personligt tilføjede jeg request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Vi plotter responstid og antal fejl:
Vi bygger grafer over responstid og antal fejl. Husk? Talte jeg om forretningsopgaver? For hurtigt og uden fejl? Vi har allerede dækket disse problemer med to diagrammer. Og du kan allerede nu ringe til de vagthavende administratorer ved hjælp af dem.
Men endnu et problem er tilbage - at sikre hurtig eliminering af årsagerne til hændelsen.
Hændelsesopløsning
Hele processen fra identifikation til løsning af et problem kan opdeles i en række trin:
- identificere problemet;
- underretning til vagtadministratoren;
- reaktion på en hændelse;
- eliminering af årsager.
Det er vigtigt, at vi skal gøre det så hurtigt som muligt. Og hvis vi på stadierne med at identificere et problem og sende en meddelelse ikke kan vinde meget tid - der vil under alle omstændigheder blive brugt to minutter på dem, så bliver de efterfølgende simpelthen pløjet felt for forbedringer.
Lad os bare forestille os, at vagtchefens telefon ringede. Hvad vil han gøre? Se efter svar på spørgsmål - hvad gik i stykker, hvor gik det i stykker, hvordan reagerede man? Sådan besvarer vi disse spørgsmål:
Vi inkluderer simpelthen alle disse oplysninger i teksten til meddelelsen, giver den et link til en wiki-side, der beskriver, hvordan man reagerer på dette problem, hvordan man løser det og eskalerer det.
Jeg har stadig ikke sagt noget om applikationslaget og forretningslogikken. Desværre implementerer vores applikationer endnu ikke indsamling af metrics. Den eneste kilde til information fra disse niveauer er logfiler.
Et par punkter.
Skriv først strukturerede logfiler. Det er ikke nødvendigt at inkludere kontekst i meddelelsens tekst. Dette gør dem svære at gruppere og analysere. Logstash tager lang tid at normalisere alt dette.
For det andet skal du bruge sværhedsgraderne korrekt. Hvert sprog har sin egen standard. Personligt skelner jeg mellem fire niveauer:
- ingen fejl;
- klientside fejl;
- fejlen er på vores side, vi mister ikke penge, vi bærer ikke risici;
- Fejlen er på vores side, vi taber penge.
Lad mig opsummere. Du skal prøve at bygge overvågning baseret på forretningslogik. Prøv at overvåge selve applikationen og arbejde med sådanne målinger som antallet af salg, antallet af nye brugerregistreringer, antallet af aktuelt aktive brugere og så videre.
Hvis hele din virksomhed er én knap i browseren, skal du overvåge, om den klikker og fungerer korrekt. Alt det andet er ligegyldigt.
Hvis du ikke har dette, kan du prøve at indhente det i applikationslogfiler, Nginx-logfiler og så videre, som vi gjorde. Du skal være så tæt på ansøgningen som muligt.
Operativsystemmålinger er selvfølgelig vigtige, men erhvervslivet er ikke interesseret i dem, vi bliver ikke betalt for dem.
Kilde: www.habr.com