Mitt navn er Anton Baderin. Jeg jobber på Høyteknologisenteret og driver med systemadministrasjon. For en måned siden ble bedriftskonferansen vår avsluttet, hvor vi delte vår akkumulerte erfaring med IT-fellesskapet i byen vår. Jeg snakket om overvåking av nettapplikasjoner. Materialet var beregnet på ungdoms- eller mellomtrinnet, som ikke bygde denne prosessen fra bunnen av.
Hjørnesteinen til ethvert overvåkingssystem er å løse forretningsproblemer. Overvåking for overvåkingens skyld er ikke av interesse for noen. Hva ønsker næringslivet? Slik at alt fungerer raskt og uten feil. Virksomheter ønsker å være proaktive, slik at vi selv identifiserer problemer i tjenesten og fikser dem så raskt som mulig. Dette er faktisk problemene jeg løste hele fjoråret på et prosjekt for en av kundene våre.
О проекте
Prosjektet er et av de største lojalitetsprogrammene i landet. Vi hjelper butikkjeder med å øke salgsfrekvensen gjennom ulike markedsføringsverktøy som bonuskort. Totalt omfatter prosjektet 14 applikasjoner som kjører på ti servere.
Under intervjuprosessen la jeg gjentatte ganger merke til at administratorer ikke alltid nærmer seg overvåking av nettapplikasjoner riktig: mange fokuserer fortsatt på operativsystemmålinger og overvåker av og til tjenester.
I mitt tilfelle var kundens overvåkingssystem tidligere basert på Icinga. Det løste ikke problemene ovenfor på noen måte. Ofte informerte klienten oss selv om problemer, og oftere enn ikke hadde vi rett og slett ikke nok data til å komme til bunns i årsaken.
I tillegg var det en klar forståelse av nytteløsheten i den videre utviklingen. Jeg tror de som er kjent med Icinga vil forstå meg. Så vi bestemte oss for å fullstendig redesigne nettapplikasjonsovervåkingssystemet for prosjektet.
Prometheus
Vi valgte Prometheus basert på tre hovedindikatorer:
- Et stort antall tilgjengelige beregninger. I vårt tilfelle er det 60 tusen av dem. Selvfølgelig er det verdt å merke seg at vi ikke bruker de aller fleste av dem (sannsynligvis ca. 95%). På den annen side er de alle relativt billige. For oss er dette den andre ytterligheten sammenlignet med den tidligere brukte Icinga. I den var det vanskelig å legge til beregninger: de eksisterende var dyre (bare se på kildekoden til en hvilken som helst plugin). Enhver plugin var et skript i Bash eller Python, hvis lansering er dyrt i forhold til forbrukte ressurser.
- Dette systemet bruker en relativt liten mengde ressurser. 600 MB RAM, 15 % av én kjerne og et par dusin IOPS er nok for alle våre beregninger. Selvfølgelig må du kjøre metrikkeksportører, men de er alle skrevet i Go og er heller ikke veldig strømsyke. Jeg tror ikke at dette er et problem i moderne virkeligheter.
- Gir muligheten til å migrere til Kubernetes. Med tanke på kundens planer er valget åpenbart.
ELK
Tidligere har vi ikke samlet inn eller behandlet logger. Manglene er klare for alle. Vi valgte ELK fordi vi allerede hadde erfaring med dette systemet. Vi lagrer kun applikasjonslogger der. De viktigste utvalgskriteriene var fulltekstsøk og hastigheten.
Klikkhus
I utgangspunktet falt valget på InfluxDB. Vi innså behovet for å samle inn Nginx-logger, statistikk fra pg_stat_statements og lagre Prometheus historiske data. Vi likte ikke Influx fordi den med jevne mellomrom begynte å forbruke en stor mengde minne og krasjet. I tillegg ønsket jeg å gruppere spørringer etter remote_addr, men gruppering i denne DBMS er bare etter tagger. Tagger er dyre (minne), antallet er betinget begrenset.
Vi startet vårt søk igjen. Det som skulle til var en analytisk database med minimalt ressursforbruk, gjerne med datakomprimering på disk.
Clickhouse oppfyller alle disse kriteriene, og vi har aldri angret på valget vårt. Vi skriver ingen ekstraordinære mengder data inn i den (antall innsettinger er bare omtrent fem tusen per minutt).
NewRelic
NewRelic har historisk vært med oss fordi det var kundens valg. Vi bruker det som en APM.
Zabbix
Vi bruker Zabbix utelukkende for å overvåke Black Box til forskjellige APIer.
Definere en overvåkingsmetode
Vi ønsket å dekomponere oppgaven og dermed systematisere tilnærmingen til overvåking.
For å gjøre dette delte jeg systemet vårt i følgende nivåer:
- maskinvare og VMS;
- operativsystem;
- systemtjenester; programvarestabel;
- applikasjon;
- forretningslogikk.
Hvorfor denne tilnærmingen er praktisk:
- vi vet hvem som er ansvarlig for arbeidet på hvert nivå, og basert på dette kan vi sende varsler;
- vi kan bruke strukturen når vi undertrykker varsler - det ville være rart å sende et varsel om database utilgjengelighet når den virtuelle maskinen som helhet er utilgjengelig.
Siden vår oppgave er å identifisere brudd i driften av systemet, må vi på hvert nivå fremheve et visst sett med beregninger som det er verdt å ta hensyn til når man skriver varslingsregler. La oss deretter gå gjennom nivåene "VMS", "Operativsystem" og "Systemtjenester, programvarestabel".
Virtuelle maskiner
Hosting tildeler oss en prosessor, disk, minne og nettverk. Og vi hadde problemer med de to første. Så, beregningene:
CPU stjålet tid - når du kjøper en virtuell maskin på Amazon (t2.micro, for eksempel), bør du forstå at du ikke er tildelt en hel prosessorkjerne, men bare en kvote av dens tid. Og når du tømmer den, vil prosessoren bli tatt fra deg.
Denne beregningen lar deg spore slike øyeblikk og ta avgjørelser. Er det for eksempel nødvendig å ta en fetere tariff eller distribuere behandlingen av bakgrunnsoppgaver og API-forespørsler til forskjellige servere?
IOPS + CPU ventetid - av en eller annen grunn synder mange nettskyverter ved å ikke gi nok IOPS. Dessuten er ikke en tidsplan med lav IOPS et argument for dem. Derfor er det verdt å samle CPU iowait. Med dette paret med grafer - med lav IOPS og høy I/O-venting - kan du allerede snakke med hostingen og løse problemet.
Operativsystem
Operativsystemberegninger:
- mengde tilgjengelig minne i %;
- bytte bruksaktivitet: vmstat bytte, bytte ut;
- antall tilgjengelige inoder og ledig plass på filsystemet i %
- gjennomsnittlig belastning;
- antall tilkoblinger i to tilstand;
- conntrack tabellen fylde;
- Kvaliteten på nettverket kan overvåkes ved hjelp av ss-verktøyet, iproute2-pakken - få en indikator på RTT-tilkoblinger fra utgangen og grupper den etter målport.
Også på operativsystemnivå har vi en slik enhet som prosesser. Det er viktig å identifisere et sett med prosesser i systemet som spiller en viktig rolle i driften. Hvis du for eksempel har flere pgpools, må du samle inn informasjon for hver av dem.
Settet med beregninger er som følger:
- PROSESSOR;
- hukommelsen er først og fremst hjemmehørende;
- IO - fortrinnsvis i IOPS;
- FileFd - åpne og begrense;
- betydelige sidefeil - på denne måten kan du forstå hvilken prosess som byttes.
Vi distribuerer all overvåking i Docker, og vi bruker Advisor til å samle inn metrikkdata. På andre maskiner bruker vi prosesseksportør.
Systemtjenester, programvarestabel
Hver applikasjon har sine egne spesifikasjoner, og det er vanskelig å skille ut et spesifikt sett med beregninger.
Det universelle settet er:
- forespørsel rate;
- antall feil;
- ventetid;
- metning.
Våre mest slående eksempler på overvåking på dette nivået er Nginx og PostgreSQL.
Den mest belastede tjenesten i systemet vårt er databasen. Tidligere hadde vi ofte problemer med å finne ut hva databasen gjorde.
Vi så en høy belastning på diskene, men de trege loggene viste egentlig ingenting. Vi løste dette problemet ved å bruke pg_stat_statements, en visning som samler søkestatistikk.
Det er alt administratoren trenger.
Vi bygger grafer over aktiviteten til lese- og skriveforespørsler:
Alt er enkelt og tydelig, hver forespørsel har sin egen farge.
Et like slående eksempel er Nginx-logger. Det er ikke overraskende at få mennesker analyserer dem eller nevner dem i listen over must-haves. Standardformatet er lite informativt og må utvides.
Personlig la jeg til request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Vi plotter responstid og antall feil:
Vi bygger grafer over responstid og antall feil. Huske? Snakket jeg om forretningsmål? For raskt og uten feil? Vi har allerede dekket disse problemene med to diagrammer. Og du kan allerede ringe administratorene på vakt ved å bruke dem.
Men enda et problem gjenstår - å sikre rask eliminering av årsakene til hendelsen.
Hendelsesløsning
Hele prosessen fra identifisering til løsning av et problem kan deles inn i en rekke trinn:
- identifisere problemet;
- melding til vaktadministrator;
- respons på en hendelse;
- eliminering av årsaker.
Det er viktig at vi må gjøre dette så raskt som mulig. Og hvis vi ikke kan vinne mye tid på stadiene med å identifisere et problem og sende et varsel - to minutter vil bli brukt på dem i alle fall, så er de påfølgende ganske enkelt oppløst felt for forbedringer.
La oss bare tenke oss at vaktmesterens telefon ringte. Hva vil han gjøre? Se etter svar på spørsmål - hva gikk i stykker, hvor gikk det i stykker, hvordan reagerer du? Slik svarer vi på disse spørsmålene:
Vi inkluderer ganske enkelt all denne informasjonen i varselteksten, gir den en lenke til en wiki-side som beskriver hvordan du skal svare på dette problemet, hvordan du løser det og eskalerer det.
Jeg har fortsatt ikke sagt noe om applikasjonslaget og forretningslogikken. Dessverre implementerer ikke applikasjonene våre innsamling av beregninger ennå. Den eneste kilden til informasjon fra disse nivåene er logger.
Et par poeng.
Skriv først strukturerte logger. Det er ikke nødvendig å inkludere kontekst i meldingens tekst. Dette gjør dem vanskelige å gruppere og analysere. Logstash bruker lang tid på å normalisere alt dette.
For det andre, bruk alvorlighetsgradene riktig. Hvert språk har sin egen standard. Personlig skiller jeg fire nivåer:
- ingen feil;
- klientsidefeil;
- feilen er på vår side, vi taper ikke penger, vi bærer ikke risiko;
- Feilen er på vår side, vi taper penger.
La meg oppsummere. Du må prøve å bygge overvåking basert på forretningslogikk. Prøv å overvåke selve applikasjonen og arbeid med slike beregninger som antall salg, antall nye brukerregistreringer, antall aktive brukere, og så videre.
Hvis hele virksomheten din er én knapp i nettleseren, må du overvåke om den klikker og fungerer som den skal. Alt det andre spiller ingen rolle.
Hvis du ikke har dette, kan du prøve å fange opp med det i applikasjonslogger, Nginx-logger og så videre, som vi gjorde. Du bør være så nærme søknaden som mulig.
Operativsystemmålinger er selvfølgelig viktige, men næringslivet er ikke interessert i dem, vi får ikke betalt for dem.
Kilde: www.habr.com