I dag, i tillegg til monolitisk kode, inkluderer prosjektet vårt dusinvis av mikrotjenester. Hver av dem må overvåkes. Å gjøre dette i en slik skala ved hjelp av DevOps-ingeniører er problematisk. Vi har utviklet et overvåkingssystem som fungerer som en tjeneste for utviklere. De kan uavhengig skrive beregninger inn i overvåkingssystemet, bruke dem, bygge dashboards basert på dem, og legge ved varsler til dem som vil utløses når terskelverdier nås. For DevOps-ingeniører, kun infrastruktur og dokumentasjon.
Dette innlegget er en utskrift av talen min med vår på RIT++. Mange ba oss lage tekstversjoner av rapporter derfra. Hvis du var på konferansen eller så videoen, vil du ikke finne noe nytt. Og alle andre - velkommen til katten. Jeg skal fortelle deg hvordan vi kom til et slikt system, hvordan det fungerer og hvordan vi planlegger å oppdatere det.
Fortiden: ordninger og planer
Hvordan kom vi frem til dagens overvåkingssystem? For å svare på dette spørsmålet må du gå til 2015. Slik så det ut da:
Vi hadde ca 24 noder som var ansvarlige for overvåking. Det er en hel pakke med forskjellige kroner, skript, demoner som på en eller annen måte overvåker noe, sender meldinger og utfører funksjoner. Vi tenkte at jo lenger vi kom, jo mindre levedyktig ville et slikt system være. Det er ingen vits i å utvikle det: det er for tungvint.
Vi bestemte oss for å velge de overvåkingselementene vi vil beholde og utvikle, og de vi vil forlate. Det var 19. Bare grafitter, aggregatorer og Grafana som dashbord gjensto. Men hvordan vil det nye systemet se ut? Som dette:
Vi har et metrikklager: dette er grafitter, som vil være basert på raske SSD-stasjoner, dette er visse aggregatorer for metrikk. Neste - Grafana for visning av dashbord og Moira for varsling. Vi ønsket også å utvikle et system for søk etter anomalier.
Standard: Overvåking 2.0
Slik så planene ut i 2015. Men vi måtte forberede ikke bare infrastrukturen og selve tjenesten, men også dokumentasjonen for det. Vi har utviklet en bedriftsstandard for oss selv, som vi kaller overvåking 2.0. Hva var kravene til systemet?
- konstant tilgjengelighet;
- metrikklagringsintervall = 10 sekunder;
- strukturert lagring av beregninger og dashbord;
- SLA > 99,99 %
- samling av hendelsesberegninger via UDP (!).
Vi trengte UDP fordi vi har en stor flyt av trafikk og hendelser som genererer beregninger. Hvis du skriver dem alle inn i grafitt på en gang, vil lagringen kollapse. Vi valgte også prefikser på første nivå for alle beregninger.
Hvert av prefiksene har en viss egenskap. Det er beregninger for servere, nettverk, containere, ressurser, applikasjoner og så videre. Tydelig, streng, maskinskrevet filtrering er implementert, der vi aksepterer førstenivåberegninger og bare dropper resten. Slik planla vi dette systemet i 2015. Hva er i nåtiden?
Tilstede: diagram over interaksjon av overvåkingskomponenter
Først av alt overvåker vi applikasjoner: PHP-koden vår, applikasjoner og mikrotjenester – kort sagt alt som utviklerne våre skriver. Alle applikasjoner sender beregninger via UDP til Brubeck-aggregatoren (statsd, omskrevet i C). Det viste seg å være raskest i syntetiske tester. Og den sender de allerede aggregerte beregningene til Graphite via TCP.
Den har en type beregninger som kalles tidtakere. Dette er en veldig praktisk ting. For hver brukertilkobling til tjenesten sender du for eksempel en beregning med responstid til Brubeck. En million svar kom inn, men aggregatoren returnerte bare 10 beregninger. Du har antall personer som kom, maksimum, minimum og gjennomsnittlig responstid, median og 4 persentiler. Deretter overføres dataene til Graphite og vi ser det hele live.
Vi har også aggregering for beregninger på maskinvare, programvare, systemmålinger og vårt gamle Munin-overvåkingssystem (det fungerte for oss frem til 2015). Vi samler alt dette gjennom C-daemonen CollectD (den har en hel pakke med forskjellige plugins innebygd i den, den kan polle alle ressursene til vertssystemet den er installert på, bare spesifiser i konfigurasjonen hvor dataene skal skrives) og skriv dataene til Graphite gjennom den. Den støtter også python-plugins og shell-skript, slik at du kan skrive dine egne tilpassede løsninger: CollectD vil samle inn disse dataene fra en lokal eller ekstern vert (forutsatt Curl) og sende dem til Graphite.
Deretter sender vi alle beregningene vi har samlet til Carbon-c-relay. Dette er Carbon Relay-løsningen fra Graphite, modifisert i C. Dette er en ruter som samler inn alle metrikkene som vi sender fra våre aggregatorer og ruter dem til noder. Også på rutingstadiet sjekker den gyldigheten av beregningene. For det første må de samsvare med prefiksskjemaet som jeg viste tidligere, og for det andre er de gyldige for grafitt. Ellers vil de falle.
Carbon-c-relé sender deretter metrikkene til grafittklyngen. Vi bruker Carbon-cache, omskrevet i Go, som hovedlagring av beregninger. Go-carbon, på grunn av sin multithreading, overgår Carbon-cache langt. Den mottar data og skriver den til disker ved hjelp av whisper-pakken (standard, skrevet i python). For å lese data fra lagrene våre bruker vi Graphite API. Det er mye raskere enn standard Graphite WEB. Hva skjer med dataene videre?
De drar til Grafana. Vi bruker grafittklyngene våre som hovedkilden til data, pluss at vi har Grafana som et nettgrensesnitt for visning av beregninger og bygging av dashboards. For hver av deres tjenester lager utviklere sitt eget dashbord. Deretter bygger de grafer basert på dem, som viser beregningene de skriver fra applikasjonene sine. I tillegg til Grafana har vi også SLAM. Dette er en pytondemon som beregner SLA basert på data fra grafitt. Som jeg allerede har sagt, har vi flere dusin mikrotjenester, som hver har sine egne krav. Ved hjelp av SLAM går vi til dokumentasjonen og sammenligner den med det som finnes i Graphite og sammenligner hvor godt kravene samsvarer med tilgjengeligheten til våre tjenester.
La oss gå videre: varsling. Det er organisert ved hjelp av et sterkt system - Moira. Den er uavhengig fordi den har sin egen grafitt under panseret. Utviklet av gutta fra SKB "Kontur", skrevet i python og Go, helt åpen kildekode. Moira mottar samme flyt som går inn i grafitt. Hvis lagringen av en eller annen grunn dør, vil varslingen fortsatt fungere.
Vi distribuerte Moira i Kubernetes; den bruker en klynge av Redis-servere som hoveddatabase. Resultatet ble et feiltolerant system. Den sammenligner strømmen av beregninger med listen over utløsere: hvis det ikke er noen omtale i den, dropper den beregningen. Så den er i stand til å fordøye gigabyte med beregninger per minutt.
Vi har også knyttet en bedrifts-LDAP til den, ved hjelp av hvilken hver bruker av bedriftssystemet kan lage varsler for seg selv basert på eksisterende (eller nyopprettede) triggere. Siden Moira inneholder grafitt, støtter den alle funksjonene. Så du tar først linjen og kopierer den inn i Grafana. Se hvordan dataene vises på grafene. Og så tar du samme linje og kopierer den inn i Moira. Du henger den med limits og får et varsel ved utgangen. For å gjøre alt dette trenger du ingen spesifikk kunnskap. Moira kan varsle via SMS, e-post, Jira, Slack... Den støtter også utførelse av tilpassede skript. Når en utløser skjer med henne, og hun abonnerer på et tilpasset skript eller binærprogram, kjører hun det og sender JSON til stdin for denne binærfilen. Følgelig må programmet ditt analysere det. Hva du vil gjøre med denne JSON er opp til deg. Hvis du vil, send det til Telegram, hvis du vil, åpne oppgaver i Jira, gjør hva som helst.
Vi bruker også vår egen utvikling for varsling – Imagotag. Vi tilpasset panelet, som vanligvis brukes til elektroniske prislapper i butikk, for å passe våre behov. Vi tok triggere fra Moira til den. Den indikerer hvilken tilstand de er i og når de oppstod. Noen av utviklingsgutta forlot varslinger i Slack og e-post til fordel for dette panelet.
Vel, siden vi er et progressivt selskap, overvåket vi også Kubernetes i dette systemet. Vi inkluderte det i systemet ved å bruke Heapster, som vi installerte i klyngen, det samler inn data og sender det til Graphite. Som et resultat ser diagrammet slik ut:
Overvåkingskomponenter
Her er en liste over lenker til komponentene vi brukte til denne oppgaven. Alle er åpen kildekode.
Grafitt:
- go-karbon:
- hviske:
- grafitt-api:
Karbon-c-relé:
Brubeck:
Samlet:
Moira:
Grafana:
Heapster:
Statistikk
Og her er noen tall om hvordan systemet fungerer for oss.
Aggregator (brubeck)
Antall beregninger: ~300 000/sek
Intervall for å sende beregninger til Graphite: 30 sek
Serverressursbruk: ~ 6% CPU (vi snakker om fullverdige servere); ~ 1 Gb RAM; ~3 Mbps LAN
Grafitt (go-karbon)
Antall beregninger: ~ 1 600 000 / min
Oppdateringsintervall for beregninger: 30 sek
Metrikklagringsskjema: 30 sek 35d, 5min 90d, 10min 365d (gir deg en forståelse av hva som skjer med tjenesten over lang tid)
Serverressursbruk: ~10 % CPU; ~ 20 Gb RAM; ~30 Mbps LAN
Fleksibilitet
Vi i Avito setter stor pris på fleksibilitet i vår overvåkingstjeneste. Hvorfor ble han egentlig slik? For det første er komponentene utskiftbare: både selve komponentene og deres versjoner. For det andre støttebarhet. Siden hele prosjektet er åpen kildekode, kan du redigere koden selv, gjøre endringer og implementere funksjoner som ikke er tilgjengelige umiddelbart. Det brukes ganske vanlige stabler, hovedsakelig Go og Python, så dette gjøres ganske enkelt.
Her er et eksempel på et reelt problem. En metrikk i Graphite er en fil. Den har et navn. Filnavn = metrisk navn. Og det er en måte å komme dit på. Filnavn i Linux er begrenset til 255 tegn. Og vi har (som "interne kunder") gutter fra databaseavdelingen. De forteller oss: «Vi ønsker å overvåke SQL-spørringene våre. Og de er ikke på 255 tegn, men 8 MB hver. Vi ønsker å vise dem i Grafana, se parameterne for denne forespørselen, og enda bedre, vi ønsker å se toppen av slike forespørsler. Det vil være flott om det vises i sanntid. Det ville vært veldig kult å sette dem i beredskap.»
Eksempelet SQL-spørring er tatt som et eksempel fra
Vi setter opp en Redis-server og bruker våre Collectd-plugins, som går til Postgres og tar all data derfra, og sender beregninger til Graphite. Men vi erstatter det metriske navnet med hashes. Vi sender samtidig den samme hashen til Redis som en nøkkel, og hele SQL-spørringen som en verdi. Alt vi trenger å gjøre er å sørge for at Grafana kan gå til Redis og ta denne informasjonen. Vi åpner Graphite API fordi... dette er hovedgrensesnittet for interaksjon av alle overvåkingskomponenter med grafitt, og vi går inn i en ny funksjon der kalt aliasByHash() - fra Grafana henter vi navnet på metrikken, og bruker den i en forespørsel til Redis som en nøkkel, i svar får vi verdien av nøkkelen, som er vår "SQL-spørring" " Dermed viste vi i Grafana en visning av en SQL-spørring, som i teorien var umulig å vise der, sammen med statistikk på den (anrop, rader, total_tid, ...).
Resultater av
Tilgjengelighet. Vår overvåkingstjeneste er tilgjengelig 24/7 fra enhver applikasjon og hvilken som helst kode. Hvis du har tilgang til lagringsfasiliteter, kan du skrive data til tjenesten. Språket er ikke viktig, beslutningene er ikke viktige. Du trenger bare å vite hvordan du åpner en stikkontakt, setter en metrikk der og lukker stikkontakten.
Pålitelighet. Alle komponenter er feiltolerante og håndterer lasten vår godt.
Lav inngangsbarriere. For å bruke dette systemet trenger du ikke å lære programmeringsspråk og spørringer i Grafana. Bare åpne applikasjonen din, skriv inn en socket som sender beregninger til Graphite, lukk den, åpne Grafana, lag dashbord der og se på oppførselen til beregningene dine, motta varsler gjennom Moira.
Selvstendighet. Du kan gjøre alt dette selv, uten hjelp fra DevOps-ingeniører. Og dette er en fordel, fordi du kan overvåke prosjektet ditt akkurat nå, du trenger ikke spørre noen - verken for å starte arbeidet eller for å gjøre endringer.
Hva sikter vi mot?
Alt oppført nedenfor er ikke bare abstrakte tanker, men noe som i det minste de første skrittene er tatt mot.
- Anomalidetektor. Vi ønsker å lage en tjeneste som vil gå til våre Graphite-lagre og sjekke hver beregning ved hjelp av forskjellige algoritmer. Det er allerede algoritmer som vi ønsker å se, det er data, vi vet hvordan vi skal jobbe med det.
- Metadata. Vi har mange tjenester, de endrer seg over tid, akkurat som menneskene som jobber med dem. Kontinuerlig vedlikehold av dokumentasjon manuelt er ikke et alternativ. Det er derfor vi nå bygger inn metadata i mikrotjenestene våre. Den oppgir hvem som har utviklet den, språkene den samhandler med, SLA-krav, hvor og til hvem varsler skal sendes. Når du distribuerer en tjeneste, opprettes alle enhetsdata uavhengig. Som et resultat får du to lenker – en til utløsere, den andre til dashbord i Grafana.
- Overvåking i alle hjem. Vi mener at alle utviklere bør bruke et slikt system. I dette tilfellet forstår du alltid hvor trafikken din er, hva som skjer med den, hvor den faller, hvor svakhetene er. Hvis for eksempel noe kommer og krasjer tjenesten din, vil du lære om det ikke under en samtale fra lederen, men fra et varsel, og du kan umiddelbart åpne de siste loggene og se hva som skjedde der.
- Høy ytelse. Prosjektet vårt vokser stadig, og i dag behandler det rundt 2 metriske verdier per minutt. For et år siden var dette tallet 000 000. Og veksten fortsetter, og dette betyr at etter en tid vil Graphite (hvisking) begynne å belaste diskundersystemet tungt. Som jeg allerede sa, er dette overvåkingssystemet ganske universelt på grunn av utskiftbarheten av komponenter. Noen vedlikeholder og utvider stadig infrastrukturen sin spesielt for Graphite, men vi bestemte oss for å gå en annen vei: bruk som et oppbevaringssted for våre beregninger. Denne overgangen er nesten fullført, og veldig snart vil jeg fortelle deg mer detaljert hvordan dette ble gjort: hvilke vanskeligheter det var og hvordan de ble overvunnet, hvordan migrasjonsprosessen gikk, jeg vil beskrive komponentene som ble valgt som bindende og deres konfigurasjoner.
Takk for din oppmerksomhet! Still spørsmålene dine om emnet, jeg skal prøve å svare her eller i følgende innlegg. Kanskje noen har erfaring med å bygge et lignende overvåkingssystem eller bytte til Clickhouse i en lignende situasjon - del det i kommentarfeltet.
Kilde: www.habr.com