I dag opererer dusinvis af mikrotjenester ud over den monolitiske kode på vores projekt. Hver af dem skal overvåges. Det er problematisk at gøre dette i sådanne mængder af DevOps-ingeniører. Vi har udviklet et overvågningssystem, der fungerer som en service for udviklere. De kan selvstændigt skrive metrics til overvågningssystemet, bruge dem, bygge dashboards baseret på dem, vedhæfte advarsler til dem, der vil blive udløst, når tærskelværdier nås. Med DevOps-ingeniører - kun infrastruktur og dokumentation.
Dette indlæg er en udskrift af min tale fra vores på RIT++. Mange bad os lave tekstversioner af rapporter derfra. Hvis du har været til en konference eller set en video, finder du ikke noget nyt. Og til alle andre - velkommen under kat. Jeg vil fortælle dig, hvordan vi kom til et sådant system, hvordan det fungerer, og hvordan vi planlægger at opdatere det.
Fortid: ordninger og planer
Hvordan kom vi til det eksisterende overvågningssystem? For at besvare dette spørgsmål skal du gå til 2015. Sådan så det ud dengang:
Vi havde omkring 24 noder, der var ansvarlige for overvågning. Der er en hel masse forskellige crons, scripts, dæmoner, der overvåger noget et eller andet sted, sender beskeder, udfører funktioner. Vi troede, at jo længere, jo mindre ville et sådant system være levedygtigt. Det giver ingen mening at udvikle det: det er for besværligt.
Vi besluttede at vælge de overvågningselementer, som vi vil forlade og udvikle, og dem, som vi vil opgive. Der var 19. Kun grafitter, aggregatorer og Grafana som dashboard tilbage. Men hvordan kommer det nye system til at se ud? Sådan her:
Vi har et lager af metrikker: disse er grafitter, der vil være baseret på hurtige SSD-drev, disse er visse aggregatorer til metrikker. Næste - Grafana til visning af dashboards og Moira som en advarsel. Vi ønskede også at udvikle et system til at finde anomalier.
Standard: Overvågning 2.0
Sådan så planerne ud i 2015. Men vi skulle forberede ikke kun infrastrukturen og selve servicen, men også dokumentationen herfor. Vi har udviklet en virksomhedsstandard til os selv, som vi kaldte overvågning 2.0. Hvad var kravene til systemet?
- konstant tilgængelighed;
- metrisk lagringsinterval = 10 sekunder;
- struktureret lagring af metrikker og dashboards;
- SLA > 99,99 %
- indsamling af hændelsesmålinger via UDP (!).
Vi havde brug for UDP, fordi vi har en masse trafik og begivenheder, der genererer metrics. Hvis de alle er skrevet i grafit på én gang, vil depotet kollapse. Vi valgte også præfikser på første niveau for alle metrics.
Hvert af præfikserne har nogle egenskaber. Der er målinger for servere, netværk, containere, ressourcer, applikationer og så videre. Der er implementeret en klar, streng, indtastet filtrering, hvor vi accepterer de første niveaus metrics og blot dropper resten. Sådan planlagde vi dette system i 2015. Hvad er der i nuet?
Til stede: skemaet for interaktion mellem overvågningskomponenter
Først og fremmest overvåger vi applikationer: vores PHP-kode, applikationer og mikrotjenester - kort sagt alt, hvad vores udviklere skriver. Alle applikationer sender metrics via UDP til Brubeck-aggregatoren (statsd, omskrevet i C). Det viste sig at være den hurtigste ifølge resultaterne af syntetiske tests. Og den sender de allerede aggregerede metrics til Graphite via TCP.
Det har sådanne typer metrikker som timere. Dette er en meget praktisk ting. For hver brugerforbindelse til tjenesten sender du f.eks. en svartidsmåling til Brubeck. Der kom en million svar, og aggregatoren gav kun 10 målinger. Du har antallet af personer, der kom, maksimum, minimum og gennemsnitlige svartider, medianen og 4 percentiler. Derefter overføres dataene til Graphite, og vi ser dem alle live.
Vi har også aggregering til hardware, software, systemmålinger og vores gamle Munin-overvågningssystem (det fungerede hos os indtil 2015). Vi indsamler alt dette gennem C'ish-dæmonen CollectD (en hel masse forskellige plug-ins er syet ind i den, den kan forespørge på alle ressourcerne på værtssystemet, hvorpå den er installeret, bare specificer i konfigurationen, hvor data skal skrives ) og skriv data gennem det i Graphite. Det understøtter også python-plugins og shell-scripts, så du kan skrive dine egne brugerdefinerede løsninger: CollectD vil indsamle disse data fra en lokal eller ekstern vært (antag, at der er Curl) og sende dem til Graphite.
Yderligere sendes alle de målinger, vi har indsamlet, til Carbon-c-relæ. Dette er Graphites Carbon Relay-løsning, modificeret i C. Dette er en router, der samler alle de metrics, som vi sender fra vores aggregatorer, og dirigerer dem gennem noderne. Også på routingstadiet kontrollerer den gyldigheden af metrikken. For det første skal de matche præfiksskemaet, jeg viste tidligere, og for det andet skal de være gyldige for grafit. Ellers falder de.
Derefter sender Carbon-c-relæ metrikken til Graphite-klyngen. Vi bruger Carbon-cache omskrevet i Go som hovedlageret for metrics. Go-carbon er på grund af sin multi-threading langt overlegen i ydeevne i forhold til Carbon-cache. Den tager data ind i sig selv og skriver dem til disk ved hjælp af whisper-pakken (standard, skrevet i python). For at læse data fra vores lagre bruger vi Graphite API. Det virker meget hurtigere end standard Graphite WEB. Hvad sker der så med dataene?
De tager til Grafana. Vi bruger vores grafitklynger som den vigtigste datakilde, plus vi har Grafana som en webgrænseflade til visning af metrics, opbygning af dashboards. For hver af deres tjenester opretter udviklere deres eget dashboard. Derefter bygger de grafer baseret på dem, som viser de metrics, som de skriver fra deres applikationer. Udover Grafana har vi også SLAM. Dette er en pytonisk dæmon, der beregner SLA baseret på data fra grafit. Som sagt har vi flere dusin mikrotjenester, som hver har sine egne krav. Ved hjælp af SLAM går vi til dokumentationen og sammenligner den med hvad der er i Graphite og sammenligner, hvordan kravene svarer til tilgængeligheden af vores tjenester.
Gå videre: alarmerende. Det er organiseret med et stærkt system - Moira. Hun er selvstændig, fordi hun har sin egen grafit under hætten. Udviklet af fyrene fra SKB Kontur, skrevet i python og Go, fuldt åben kildekode. Moira modtager alt det samme flow, som går ind i grafitter. Hvis dit lager af en eller anden grund dør, vil din advarsel virke.
Vi implementerede Moira i Kubernetes, den bruger en klynge af Redis-servere som hoveddatabasen. Resultatet er et fejltolerant system. Den sammenligner strømmen af metrikker med listen over triggere: Hvis der ikke er nogen omtaler i den, så dropper den metrikken. Så hun er i stand til at fordøje gigabyte af metrikker i minuttet.
Vi har også tilføjet en virksomheds-LDAP til den, ved hjælp af hvilken hver bruger af virksomhedssystemet kan oprette notifikationer til sig selv på eksisterende (eller nyoprettede) triggere. Da Moira indeholder grafit, understøtter den alle dens funktioner. Så du tager først linjen og kopierer den ind i Grafana. Se, hvordan dataene vises på diagrammerne. Og så tager du den samme linje og kopierer den ind i Moira. Hæng den med grænser og få en advarsel ved udgangen. For at gøre alt dette behøver du ikke nogen specifik viden. Moira kan advare via SMS, e-mail, Jira, Slack... Det understøtter også brugerdefinerede scripts. Når hun har en trigger, og hun abonnerer på et brugerdefineret script eller binær, starter hun den og sender denne JSON-binær til stdin. Derfor bør dit program parse det. Hvad du vil gøre med denne JSON er op til dig. Hvis du vil, så send det til Telegram, hvis du vil, åbne opgaver i Jira, gør hvad du vil.
Vi bruger også vores egen udvikling til alarmering - Imagotag. Vi tilpassede panelet, som normalt bruges til elektroniske prisskilte i butikkerne, til vores behov. Vi bragte triggere fra Moira til det. Det angiver, hvilken tilstand de er i, hvornår de skete. Nogle af fyrene fra udviklingen forlod notifikationer i Slack og i posten til fordel for dette panel.
Da vi er en progressiv virksomhed, overvågede vi også Kubernetes i dette system. Inkluderet det i systemet ved hjælp af Heapster, som vi installerede i klyngen, det indsamler data og sender det til Graphite. Som et resultat ser ordningen således ud:
Overvågningskomponenter
Her er en liste over links til de komponenter, vi brugte til denne opgave. Alle er open source.
Grafit:
- gå kulstof:
- hviske:
- grafit-api:
Carbon-c-relæ:
Brubeck:
Indsamlet:
moira:
Grafana:
heapster:
Statistikker
Og her er nogle tal om, hvordan systemet fungerer for os.
Aggregator (brubeck)
Antal målinger: ~ 300/sek
Grafitmetrics Sendeinterval: 30 sek
Serverressourceudnyttelse: ~ 6% CPU (vi taler om fuldgyldige servere); ~ 1 Gb RAM; ~ 3 Mbps LAN
Grafit (go-carbon)
Antal målinger: ~ 1 / min
Metrisk opdateringsinterval: 30 sek
Metrisk lagringsskema: 30 sek. 35d, 5min. 90d, 10min. 365d (giver en forståelse af, hvad der sker med tjenesten over en lang periode)
Serverressourceforbrug: ~10% CPU; ~ 20 Gb RAM; ~30 Mbps LAN
fleksibilitet
Vi hos Avito sætter stor pris på fleksibiliteten i vores overvågningsservice. Hvorfor blev han egentlig sådan? For det første er dens bestanddele udskiftelige: både selve komponenterne og deres versioner. For det andet vedligeholdelsesdygtighed. Da hele projektet er bygget på open source, kan du selv redigere koden, foretage ændringer og implementere funktioner, der ikke er tilgængelige ud af boksen. Der bruges ganske almindelige stakke, primært Go og Python, så dette gøres ganske enkelt.
Her er et eksempel på et reelt problem. En metrik i Graphite er en fil. Den har et navn. Filnavn = metrisk navn. Og der er en måde at komme dertil. Filnavne i Linux er begrænset til 255 tegn. Og vi har (som "interne kunder") fyre fra databaseafdelingen. De fortæller os: "Vi vil gerne overvåge vores SQL-forespørgsler. Og de er ikke på 255 tegn, men 8 MB hver. Vi ønsker at vise dem i Grafana, se parametrene for denne anmodning, og endnu bedre, vi ønsker at se toppen af sådanne anmodninger. Det vil være fantastisk, hvis det vises i realtid. Og det ville være rigtig fedt at skubbe dem ind i alarmberedskabet.”
SQL-forespørgselseksemplet er taget som eksempel fra
Vi hæver Redis-serveren og vores Collectd-plugins, der går til Postgres og tager alle data derfra, sender metrics til Graphite. Men vi erstatter navnet på metrikken med hashes. Den samme hash sendes samtidigt til Redis som en nøgle, og hele SQL-forespørgslen som en værdi. Det er tilbage for os at gøre Grafana i stand til at tage til Redis og tage disse oplysninger. Vi åbner Graphite API pga dette er hovedgrænsefladen for interaktionen af alle overvågningskomponenter med grafit, og vi indtaster en ny funktion der kaldet aliasByHash () - vi får navnet på metrikken fra Grafana og bruger den i en anmodning til Redis som en nøgle, i svar får vi værdien af nøglen, som er vores "SQL-forespørgsel". Således bragte vi til Grafana visningen af en SQL-forespørgsel, som i teorien ikke kunne vises der, sammen med statistik over den (opkald, rækker, total_tid, ...).
Resultaterne af
Tilgængelighed. Vores overvågningsservice er tilgængelig 24/7 fra enhver applikation og enhver kode. Hvis du har adgang til lagrene, kan du skrive data til tjenesten. Sproget er ikke vigtigt, beslutninger er ikke vigtige. Du behøver kun at vide, hvordan man åbner en fatning, kaster en metrisk derhen og lukker fatningen.
Pålidelighed. Alle komponenter er fejltolerante og håndterer vores arbejdsbyrder godt.
Lav adgangstærskel. For at bruge dette system behøver du ikke at lære programmeringssprog og forespørgsler i Grafana. Bare åbn din applikation, tilføj en socket til den, der sender metrics til Graphite, luk den, åbn Grafana, opret dashboards der og se på adfærden af dine metrics, modtag notifikationer gennem Moira.
Uafhængighed. Du kan gøre alt dette selv uden hjælp fra DevOps-ingeniører. Og dette er en overfunktion, fordi du kan overvåge dit projekt lige nu, du behøver ikke at spørge nogen - hverken for at starte arbejdet eller at foretage ændringer.
Hvad stræber vi efter?
Alt, der er anført nedenfor, er ikke bare abstrakte tanker, men noget, som i det mindste er taget de første skridt hen imod.
- anomali detektor. Vi ønsker at skabe en tjeneste, der vil gå til vores grafitlagre og kontrollere hver metrik ved hjælp af forskellige algoritmer. Der er allerede algoritmer, som vi vil se, der er data, vi ved, hvordan vi skal arbejde med dem.
- metadata. Vi har mange tjenester, de ændrer sig over tid, såvel som de mennesker, der arbejder med dem. At føre optegnelser manuelt er ikke en mulighed. Derfor er metadata nu indlejret i vores mikrotjenester. Den angiver, hvem der har udviklet det, de sprog, det interagerer med, SLA-krav, hvor og til hvem der skal sendes notifikationer. Når du implementerer en tjeneste, oprettes alle enhedsdata uafhængigt. Som et resultat får du to links - et til triggere, det andet til dashboards i Grafana.
- Overvågning i alle hjem. Vi mener, at alle udviklere bør bruge sådan et system. I dette tilfælde forstår du altid, hvor din trafik er, hvad der sker med den, hvor den falder, hvor den har svage punkter. Hvis der for eksempel kommer noget og styrter din tjeneste ned, så vil du ikke finde ud af det under et opkald fra lederen, men fra en alarm, og du kan straks åbne friske logs og se, hvad der skete der.
- Høj ydeevne. Vores projekt vokser konstant, og i dag behandler det omkring 2 metriske værdier i minuttet. For et år siden var dette tal 000. Og væksten fortsætter, og det betyder, at Graphite (hvisker) efter nogen tid begynder at belaste diskundersystemet meget kraftigt. Som sagt er dette overvågningssystem ret alsidigt på grund af komponenternes udskiftelighed. Nogen specifikt til Graphite vedligeholder og udvider konstant deres infrastruktur, men vi besluttede at gå den anden vej: brug som et opbevaringssted for vores metrics. Denne overgang er næsten afsluttet, og meget snart vil jeg fortælle dig mere detaljeret, hvordan det blev gjort: hvad var vanskelighederne, og hvordan de blev overvundet, hvordan migreringsprocessen gik, jeg vil beskrive de komponenter, der er valgt som bindende og deres konfigurationer.
Tak for din opmærksomhed! Stil dine spørgsmål om emnet, jeg vil forsøge at besvare her eller i de følgende indlæg. Måske har nogen erfaring med at bygge et lignende overvågningssystem eller skifte til Clickhouse i en lignende situation - del det i kommentarerne.
Kilde: www.habr.com