Vandag, benewens die monolitiese kode, werk tientalle mikrodienste op ons projek. Elkeen van hulle moet gemonitor word. Dit is problematies om dit in sulke volumes deur DevOps-ingenieurs te doen. Ons het 'n moniteringstelsel ontwikkel wat as 'n diens vir ontwikkelaars werk. Hulle kan onafhanklik statistieke aan die moniteringstelsel skryf, dit gebruik, dashboards op grond daarvan bou, waarskuwings daaraan heg wat geaktiveer sal word wanneer drempelwaardes bereik word. Met DevOps-ingenieurs - slegs infrastruktuur en dokumentasie.
Hierdie pos is 'n transkripsie van my toespraak van ons op RIT++. Baie het ons gevra om teksweergawes van verslae van daar af te maak. As jy by 'n konferensie was of 'n video gekyk het, sal jy niks nuuts vind nie. En aan almal anders - welkom onder kat. Ek sal jou vertel hoe ons by so 'n stelsel uitgekom het, hoe dit werk en hoe ons beplan om dit op te dateer.
Verlede: skemas en planne
Hoe het ons by die bestaande moniteringstelsel uitgekom? Om hierdie vraag te beantwoord, moet jy na 2015 gaan. Hier is hoe dit toe gelyk het:
Ons het ongeveer 24 nodusse gehad wat vir monitering verantwoordelik was. Daar is 'n hele klomp verskillende crons, skrifte, daemone wat iewers iets monitor, boodskappe stuur, funksies verrig. Ons het gedink hoe verder, hoe minder sou so 'n stelsel lewensvatbaar wees. Dit maak geen sin om dit te ontwikkel nie: dit is te omslagtig.
Ons het besluit om daardie elemente van monitering te kies wat ons sal verlaat en ontwikkel, en dié wat ons sal laat vaar. Daar was 19. Slegs grafiete, aggregators en Grafana as 'n paneelbord het oorgebly. Maar hoe sal die nuwe stelsel lyk? Soos hierdie:
Ons het 'n bewaarplek van metrieke: dit is grafiete wat gebaseer sal wees op vinnige SSD-aandrywers, dit is sekere aggregators vir metrieke. Volgende - Grafana vir die vertoon van dashboards en Moira as 'n waarskuwing. Ons wou ook 'n stelsel ontwikkel om onreëlmatighede op te spoor.
Standaard: Monitering 2.0
Dit is hoe die planne gelyk het in 2015. Maar ons moes nie net die infrastruktuur en die diens self voorberei nie, maar ook die dokumentasie daarvoor. Ons het 'n korporatiewe standaard vir onsself ontwikkel, wat ons monitering 2.0 genoem het. Wat was die vereistes vir die stelsel?
- konstante beskikbaarheid;
- metrieke bergingsinterval = 10 sekondes;
- gestruktureerde berging van metrieke en dashboards;
- SLA > 99,99%
- versameling gebeurtenisstatistieke via UDP (!).
Ons het UDP nodig gehad omdat ons baie verkeer en gebeurtenisse het wat statistieke genereer. As hulle almal gelyktydig in grafiet geskryf is, sal die bewaarplek ineenstort. Ons het ook eerstevlak-voorvoegsels vir alle maatstawwe gekies.
Elkeen van die voorvoegsels het 'n sekere eienskap. Daar is maatstawwe vir bedieners, netwerke, houers, hulpbronne, toepassings, ensovoorts. 'n Duidelike, streng, getikte filter is geïmplementeer, waar ons die eerstevlak-metrieke aanvaar en eenvoudig die res laat vaar. Dit is hoe ons hierdie stelsel in 2015 beplan het. Wat is in die hede?
Aanwesig: die skema van interaksie van moniteringskomponente
Eerstens monitor ons toepassings: ons PHP-kode, toepassings en mikrodienste - in 'n woord, alles wat ons ontwikkelaars skryf. Alle toepassings stuur metrieke via UDP na die Brubeck-aggregator (statsd, herskryf in C). Dit blyk die vinnigste te wees volgens die resultate van sintetiese toetse. En dit stuur die reeds saamgestelde statistieke na Graphite via TCP.
Dit het sulke tipe statistieke soos timers. Dit is 'n baie handige ding. Byvoorbeeld, vir elke gebruikerverbinding met die diens, stuur jy 'n reaksietyd-metriek na Brubeck. 'n Miljoen antwoorde het gekom, en die versamelaar het slegs 10 statistieke gegee. Jy het die aantal mense wat gekom het, die maksimum, minimum en gemiddelde reaksietye, die mediaan en 4 persentiele. Dan word die data na Graphite oorgedra en ons sien hulle almal regstreeks.
Ons het ook samevoeging vir hardeware, sagteware, stelselstatistieke en ons ou Munin-moniteringstelsel (dit het tot 2015 met ons gewerk). Ons versamel dit alles deur die C'ish daemon CollectD ('n hele klomp verskillende inproppe is daarin vasgewerk, dit kan navraag doen oor al die hulpbronne van die gasheerstelsel waarop dit geïnstalleer is, spesifiseer net in die konfigurasie waar om data te skryf ) en skryf data daardeur in Graphite. Dit ondersteun ook python-inproppe en dopskrifte, sodat jy jou eie pasgemaakte oplossings kan skryf: CollectD sal hierdie data van 'n plaaslike of afgeleë gasheer insamel (met die veronderstelling dat Curl beskikbaar is) en dit na Graphite stuur.
Verder word al die maatstawwe wat ons ingesamel het na Carbon-c-relay gestuur. Dit is Graphite se Carbon Relay-oplossing, gewysig in C. Dit is 'n roeteerder wat al die maatstawwe wat ons van ons aggregators stuur, versamel en hulle deur die nodusse stuur. Ook in die roete-stadium, kontroleer dit die geldigheid van die metrieke. Eerstens moet hulle ooreenstem met die voorvoegselskema wat ek vroeër gewys het en tweedens moet hulle geldig wees vir grafiet. Andersins val hulle af.
Dan stuur Carbon-c-relay die metrieke na die Graphite cluster. Ons gebruik Carbon-cache herskryf in Go as die hoofberging vir metrieke. Go-carbon, as gevolg van sy multi-threading, is baie beter in prestasie as Carbon-cache. Dit neem data in homself en skryf dit na skyf met behulp van die fluisterpakket (standaard, geskryf in luislang). Om data uit ons bergings te lees, gebruik ons die Graphite API. Dit werk baie vinniger as die standaard Graphite WEB. Wat gebeur volgende met die data?
Hulle gaan Grafana toe. Ons gebruik ons grafietklusters as die hoofdatabron, plus ons het Grafana as 'n webkoppelvlak vir die vertoon van statistieke, die bou van dashboards. Vir elkeen van hul dienste skep ontwikkelaars hul eie kontroleskerm. Dan bou hulle grafieke op grond daarvan, wat die maatstawwe vertoon wat hulle uit hul toepassings skryf. Benewens Grafana het ons ook SLAM. Dit is 'n pytoniese demoon wat SLA bereken op grond van data van grafiet. Soos ek gesê het, het ons 'n paar dosyn mikrodienste, wat elkeen sy eie vereistes het. Met die hulp van SLAM gaan ons na die dokumentasie en vergelyk dit met wat in Graphite staan en vergelyk hoe die vereistes ooreenstem met die beskikbaarheid van ons dienste.
Gaan verder: waarskuwing. Dit is georganiseer met 'n sterk stelsel - Moira. Sy is onafhanklik omdat sy haar eie Graphite onder die enjinkap het. Ontwikkel deur die ouens van SKB Kontur, geskryf in python en Go, volledig oopbron. Moira ontvang dieselfde vloei wat in grafiete gaan. As jou stoorplek om een of ander rede doodgaan, sal jou waarskuwing werk.
Ons het Moira in Kubernetes ontplooi, dit gebruik 'n groep Redis-bedieners as die hoofdatabasis. Die resultaat is 'n foutverdraagsame stelsel. Dit vergelyk die vloei van metrieke met die lys snellers: as daar geen meldings daarin is nie, laat dit die metrieke weg. Sy is dus in staat om gigagrepe metrieke per minuut te verteer.
Ons het ook 'n korporatiewe LDAP daarby gevoeg, met behulp waarvan elke gebruiker van die korporatiewe stelsel vir homself kennisgewings op bestaande (of nuutgeskepte) snellers kan skep. Aangesien Moira grafiet bevat, ondersteun dit al sy kenmerke. So jy neem eers die lyn en kopieer dit in Grafana. Kyk hoe die data op die kaarte vertoon word. En dan neem jy dieselfde lyn en kopieer dit in Moira. Hang dit met perke en kry 'n waarskuwing by die uitset. Om dit alles te doen, het jy geen spesifieke kennis nodig nie. Moira kan waarsku via SMS, e-pos, Jira, Slack ... Dit ondersteun ook pasgemaakte skrifte. Wanneer sy 'n sneller het, en sy is ingeteken op 'n pasgemaakte skrif of binêre, loods sy dit en stuur hierdie JSON-binêre na stdin. Gevolglik moet jou program dit ontleed. Wat jy met hierdie JSON sal doen, is aan jou. As jy wil, stuur dit na Telegram, as jy wil, maak take oop in Jira, doen wat jy wil.
Ons gebruik ook ons eie ontwikkeling vir waarskuwing - Imagotag. Ons het die paneel, wat gewoonlik vir elektroniese prysetikette in winkels gebruik word, by ons behoeftes aangepas. Ons het snellers van Moira daarheen gebring. Dit dui aan in watter toestand hulle is, wanneer dit gebeur het. Sommige van die ouens van die ontwikkeling het kennisgewings in Slack en in die pos laat vaar ten gunste van hierdie paneel.
Wel, aangesien ons 'n progressiewe maatskappy is, het ons ook Kubernetes in hierdie stelsel gemonitor. Ingesluit in die stelsel met behulp van Heapster, wat ons in die groep geïnstalleer het, dit versamel data en stuur dit na Graphite. Gevolglik lyk die skema soos volg:
Monitering komponente
Hier is 'n lys van skakels na die komponente wat ons vir hierdie taak gebruik het. Almal van hulle is oopbron.
Grafiet:
- go-koolstof:
- fluister:
- grafiet-api:
Koolstof-c-aflos:
Brubeck:
Afgehaal:
Moira:
Grafana:
heapster:
statistieke
En hier is 'n paar syfers oor hoe die stelsel vir ons werk.
Aggregator (brubeck)
Aantal metrieke: ~ 300 000 / sek
Grafiet-metrieke Stuurinterval: 30 sek
Bedienerhulpbronbenutting: ~ 6% SVE (ons praat van volwaardige bedieners); ~ 1 Gb RAM; ~ 3 Mbps LAN
Grafiet (go-koolstof)
Aantal metrieke: ~ 1 600 000 / min
Metrieke opdateringsinterval: 30 sek
Metrieke bergingskema: 30 sek 35 d, 5 min 90 d, 10 min 365 d (gee 'n begrip van wat met die diens gebeur oor 'n lang tydperk)
Bedienerhulpbrongebruik: ~10% SVE; ~ 20 Gb RAM; ~ 30 Mbps LAN
Buigsaamheid
Ons by Avito waardeer die buigsaamheid in ons moniteringsdiens baie. Hoekom het hy eintlik so uitgedraai? Eerstens is die samestellende dele uitruilbaar: beide die komponente self en hul weergawes. Tweedens, onderhoubaarheid. Aangesien die hele projek op oopbron gebou is, kan jy self die kode wysig, veranderinge aanbring en funksies implementeer wat nie uit die boks beskikbaar is nie. Baie algemene stapels word gebruik, hoofsaaklik Go en Python, so dit word eenvoudig gedoen.
Hier is 'n voorbeeld van 'n werklike probleem. 'n Metriek in Graphite is 'n lêer. Dit het 'n naam. Lêernaam = metrieke naam. En daar is 'n manier om daar te kom. Lêername in Linux is beperk tot 255 karakters. En ons het (as “interne kliënte”) ouens van die databasisafdeling. Hulle sê vir ons: “Ons wil ons SQL-navrae monitor. En hulle is nie 255 karakters nie, maar 8 MB elk. Ons wil hulle in Grafana vertoon, die parameters vir hierdie versoek sien, en nog beter, ons wil die top van sulke versoeke sien. Dit sal wonderlik wees as dit in reële tyd vertoon word. En dit sal baie gaaf wees om hulle in die waarskuwing te stoot.”
Die SQL-navraagvoorbeeld word geneem as 'n voorbeeld van
Ons verhoog die Redis-bediener en ons Collectd-inproppe wat na Postgres gaan en al die data van daar af neem, statistieke na Graphite stuur. Maar ons vervang die naam van die metrieke met hashes. Dieselfde hash word gelyktydig as 'n sleutel na Redis gestuur, en die hele SQL-navraag as 'n waarde. Dit bly vir ons om Grafana in staat te stel om Redis toe te gaan en hierdie inligting te neem. Ons maak die Graphite API oop omdat dit is die hoofkoppelvlak vir die interaksie van alle moniteringskomponente met grafiet, en ons voer 'n nuwe funksie daar in genaamd aliasByHash () - ons kry die naam van die metriek van Grafana, en gebruik dit in 'n versoek aan Redis as 'n sleutel, in reaksie kry ons die waarde van die sleutel, wat ons "SQL-navraag" is. Ons het dus na Grafana die vertoning van 'n SQL-navraag gebring, wat in teorie nie daar vertoon kon word nie, saam met statistieke daaroor (oproepe, rye, totaal_tyd, ...).
Resultate van
Beskikbaarheid. Ons moniteringsdiens is 24/7 beskikbaar vanaf enige toepassing en enige kode. As jy toegang tot die bergings het, kan jy data na die diens skryf. Taal is nie belangrik nie, besluite is nie belangrik nie. Jy hoef net te weet hoe om 'n sok oop te maak, 'n maatstaf daar te gooi en die sok toe te maak.
Betroubaarheid. Alle komponente is foutverdraagsaam en hanteer ons werkladings goed.
Lae toegangsdrempel. Om hierdie stelsel te gebruik, hoef jy nie programmeertale en navrae in Grafana te leer nie. Maak net jou toepassing oop, voeg 'n sok daarby wat metrieke na Graphite sal stuur, maak dit toe, maak Grafana oop, skep dashboards daar en kyk na die gedrag van jou metrieke, ontvang kennisgewings deur Moira.
Onafhanklikheid. U kan dit alles self doen, sonder die hulp van DevOps-ingenieurs. En dit is 'n oorfunksie, want jy kan jou projek nou monitor, jy hoef niemand te vra nie - nie om te begin werk nie, of om veranderinge aan te bring.
Waarna streef ons?
Alles wat hieronder gelys word, is nie net abstrakte gedagtes nie, maar iets waarheen ten minste die eerste stappe geneem is.
- anomalie detektor. Ons wil 'n diens skep wat na ons Graphite-bergings sal gaan en elke maatstaf nagaan met behulp van verskeie algoritmes. Daar is reeds algoritmes wat ons wil bekyk, daar is data, ons weet hoe om daarmee te werk.
- metadata. Ons het baie dienste, hulle verander met verloop van tyd, sowel as die mense wat daarmee werk. Om rekords met die hand te hou is nie 'n opsie nie. Daarom is metadata nou in ons mikrodienste ingebed. Dit sê wie dit ontwikkel het, die tale waarmee dit in wisselwerking is, SLA-vereistes, waar en aan wie om kennisgewings te stuur. Wanneer 'n diens ontplooi word, word alle entiteitdata onafhanklik geskep. Gevolglik kry jy twee skakels – een vir snellers, die ander vir dashboards in Grafana.
- Monitering in elke huis. Ons glo dat alle ontwikkelaars so 'n stelsel moet gebruik. In hierdie geval verstaan jy altyd waar jou verkeer is, wat daarmee gebeur, waar dit val, waar dit swak punte het. As, byvoorbeeld, iets kom en jou diens ineenstort, sal jy nie daarvan uitvind tydens 'n oproep van die bestuurder nie, maar uit 'n waarskuwing, en jy kan dadelik nuwe logs oopmaak en sien wat daar gebeur het.
- Hoë werkverrigting. Ons projek groei voortdurend, en vandag verwerk dit ongeveer 2 metrieke waardes per minuut. 'n Jaar gelede was hierdie syfer 000 000. En die groei gaan voort, en dit beteken dat Graphite (fluister) na 'n rukkie die skyfsubstelsel baie swaar sal begin laai. Soos ek gesê het, is hierdie moniteringstelsel redelik veelsydig as gevolg van die uitruilbaarheid van komponente. Iemand spesifiek vir Graphite onderhou en brei voortdurend hul infrastruktuur uit, maar ons het besluit om anderpad te gaan: gebruik as 'n bewaarplek vir ons metrieke. Hierdie oorgang is amper voltooi, en baie gou sal ek jou in meer besonderhede vertel hoe dit gedoen is: wat was die probleme en hoe dit oorkom is, hoe die migrasieproses verloop het, ek sal die komponente wat as bindend gekies is en hul konfigurasies beskryf.
Dankie vir jou aandag! Vra jou vrae oor die onderwerp, ek sal probeer om hier of in die volgende plasings te beantwoord. Miskien het iemand ondervinding in die bou van 'n soortgelyke moniteringstelsel of oorskakeling na Clickhouse in 'n soortgelyke situasie - deel dit in die kommentaar.
Bron: will.com