Tegenwoordig omvat ons project naast monolithische code tientallen microservices. Elk van hen moet worden gecontroleerd. Dit op een dergelijke schaal doen met behulp van DevOps-ingenieurs is problematisch. We hebben een monitoringsysteem ontwikkeld dat werkt als een service voor ontwikkelaars. Ze kunnen zelfstandig statistieken in het monitoringsysteem schrijven, gebruiken, op basis daarvan dashboards bouwen en er waarschuwingen aan koppelen die worden geactiveerd wanneer drempelwaarden worden bereikt. Voor DevOps-ingenieurs: alleen infrastructuur en documentatie.
Dit bericht is een transcriptie van mijn toespraak met onze bij RIT++. Veel mensen vroegen ons om van daaruit tekstversies van rapporten te maken. Als je op de conferentie was of de video hebt bekeken, zul je niets nieuws vinden. En alle anderen - welkom bij de kat. Ik zal je vertellen hoe we tot zo’n systeem zijn gekomen, hoe het werkt en hoe we het willen updaten.
Het verleden: schema's en plannen
Hoe zijn we tot het huidige monitoringsysteem gekomen? Om deze vraag te beantwoorden, moeten we naar 2015 gaan. Zo zag het er toen uit:
We hadden ongeveer 24 knooppunten die verantwoordelijk waren voor de monitoring. Er is een heel pakket aan verschillende kronen, scripts en daemons die op de een of andere manier iets monitoren, berichten verzenden en functies uitvoeren. We dachten dat hoe verder we gingen, hoe minder levensvatbaar een dergelijk systeem zou zijn. Het heeft geen zin om het te ontwikkelen: het is te omslachtig.
We hebben besloten de monitoringelementen te kiezen die we zullen behouden en ontwikkelen, en de elementen die we zullen laten varen. Het waren er 19. Alleen graphites, aggregators en Grafana als dashboard bleven over. Maar hoe gaat het nieuwe systeem er uit zien? Soortgelijk:
We hebben een opslag voor statistieken: dit zijn grafieten, die gebaseerd zullen zijn op snelle SSD-schijven, dit zijn bepaalde aggregators voor statistieken. Volgende - Grafana voor het weergeven van dashboards en Moira voor waarschuwingen. We wilden ook een systeem ontwikkelen voor het zoeken naar afwijkingen.
Standaard: Monitoring 2.0
Zo zagen de plannen er in 2015 uit. Maar we moesten niet alleen de infrastructuur en de dienst zelf voorbereiden, maar ook de documentatie daarvoor. Wij hebben voor onszelf een bedrijfsstandaard ontwikkeld, die wij monitoring 2.0 noemen. Wat waren de vereisten voor het systeem?
- constante beschikbaarheid;
- opslaginterval voor metrische gegevens = 10 seconden;
- gestructureerde opslag van statistieken en dashboards;
- SLA > 99,99%
- verzameling van gebeurtenisstatistieken via UDP (!).
We hadden UDP nodig omdat we een grote stroom verkeer en gebeurtenissen hebben die statistieken genereren. Als je ze allemaal tegelijk in grafiet schrijft, stort de opslag in. We hebben ook voorvoegsels op het eerste niveau gekozen voor alle statistieken.
Elk van de voorvoegsels heeft een eigenschap. Er zijn statistieken voor servers, netwerken, containers, bronnen, applicaties, enzovoort. Er is een duidelijke, strikte, getypte filtering geïmplementeerd, waarbij we statistieken op het eerste niveau accepteren en de rest eenvoudigweg laten vallen. Zo hebben we dit systeem in 2015 gepland. Wat zit er in het heden?
Aanwezig: diagram van interactie van monitoringcomponenten
Allereerst monitoren we applicaties: onze PHP-code, applicaties en microservices - kortom alles wat onze ontwikkelaars schrijven. Alle applicaties sturen statistieken via UDP naar de Brubeck-aggregator (statsd, herschreven in C). Bij synthetische tests bleek het de snelste. En het stuurt de reeds verzamelde statistieken via TCP naar Graphite.
Het heeft een soort statistieken die timers worden genoemd. Dit is een heel handig ding. Voor elke gebruikersverbinding met de dienst stuurt u bijvoorbeeld een statistiek met responstijd naar Brubeck. Er kwamen een miljoen reacties binnen, maar de aggregator retourneerde slechts tien statistieken. Je hebt het aantal mensen dat is gekomen, de maximale, minimale en gemiddelde responstijd, de mediaan en 10 percentielen. Vervolgens worden de gegevens overgebracht naar Graphite en zien we het allemaal live.
We hebben ook aggregatie voor statistieken over hardware, software, systeemstatistieken en ons oude Munin-monitoringsysteem (het werkte voor ons tot 2015). We verzamelen dit allemaal via de C-daemon CollectD (er zijn een hele reeks verschillende plug-ins in ingebouwd, het kan alle bronnen van het hostsysteem waarop het is geïnstalleerd opvragen, specificeer gewoon in de configuratie waar de gegevens moeten worden geschreven) en schrijf de gegevens er doorheen naar Graphite. Het ondersteunt ook Python-plug-ins en shell-scripts, zodat u uw eigen oplossingen op maat kunt schrijven: CollectD verzamelt deze gegevens van een lokale of externe host (uitgaande van Curl) en stuurt deze naar Graphite.
Vervolgens sturen we alle statistieken die we hebben verzameld naar Carbon-c-relay. Dit is de Carbon Relay-oplossing van Graphite, aangepast in C. Dit is een router die alle statistieken verzamelt die we vanuit onze aggregators verzenden en deze naar knooppunten stuurt. Ook tijdens de routeringsfase controleert het de geldigheid van de statistieken. Ten eerste moeten ze overeenkomen met het voorvoegselschema dat ik eerder heb laten zien, en ten tweede zijn ze geldig voor grafiet. Anders zullen ze vallen.
Carbon-c-relay verzendt vervolgens de statistieken naar het grafietcluster. We gebruiken Carbon-cache, herschreven in Go, als de belangrijkste opslag van statistieken. Go-carbon presteert dankzij zijn multithreading veel beter dan Carbon-cache. Het ontvangt gegevens en schrijft deze naar schijven met behulp van het Whisper-pakket (standaard, geschreven in Python). Om gegevens uit onze opslag te lezen, gebruiken we de Graphite API. Het is veel sneller dan standaard Graphite WEB. Wat gebeurt er vervolgens met de gegevens?
Ze gaan naar Grafana. We gebruiken onze grafietclusters als de belangrijkste gegevensbron, plus Grafana als webinterface voor het weergeven van statistieken en het bouwen van dashboards. Voor elk van hun services maken ontwikkelaars hun eigen dashboard. Vervolgens bouwen ze op basis daarvan grafieken, die de statistieken weergeven die ze vanuit hun applicaties schrijven. Naast Grafana hebben we ook SLAM. Dit is een python-demon die SLA berekent op basis van gegevens uit grafiet. Zoals ik al zei, hebben we enkele tientallen microservices, die elk hun eigen vereisten hebben. Met SLAM gaan we naar de documentatie en vergelijken deze met wat er in Graphite staat en vergelijken we hoe goed de vereisten aansluiten bij de beschikbaarheid van onze diensten.
Laten we verder gaan: alarmeren. Het wordt georganiseerd met behulp van een sterk systeem: Moira. Het is onafhankelijk omdat het zijn eigen grafiet onder de motorkap heeft. Ontwikkeld door de jongens van SKB "Kontur", geschreven in Python en Go, volledig open source. Moira ontvangt dezelfde stroom als grafiet. Als uw opslag om de een of andere reden leegraakt, werken uw waarschuwingen nog steeds.
We hebben Moira in Kubernetes geïmplementeerd; het gebruikt een cluster Redis-servers als hoofddatabase. Het resultaat was een fouttolerant systeem. Het vergelijkt de stroom metrieken met de lijst met triggers: als er geen vermeldingen in voorkomen, wordt de metriek verwijderd. Het is dus in staat gigabytes aan statistieken per minuut te verwerken.
We hebben er ook een bedrijfs-LDAP aan gekoppeld, met behulp waarvan elke gebruiker van het bedrijfssysteem voor zichzelf meldingen kan maken op basis van bestaande (of nieuw aangemaakte) triggers. Omdat Moira grafiet bevat, ondersteunt het al zijn functies. Dus je neemt eerst de regel en kopieert deze naar Grafana. Bekijk hoe de gegevens in de grafieken worden weergegeven. En dan neem je dezelfde regel en kopieer je deze naar Moira. Je hangt hem op met limieten en krijgt een waarschuwing bij de uitgang. Om dit allemaal te doen, heb je geen specifieke kennis nodig. Moira kan waarschuwen via sms, e-mail, Jira, Slack... Het ondersteunt ook de uitvoering van aangepaste scripts. Wanneer haar een trigger overkomt en ze is geabonneerd op een aangepast script of binair bestand, voert ze het uit en stuurt JSON naar stdin voor dit binaire bestand. Dienovereenkomstig moet uw programma het parseren. Wat u met deze JSON gaat doen, is aan u. Als je wilt, stuur het dan naar Telegram, als je wilt, open taken in Jira, doe wat dan ook.
Voor het alarmeren gebruiken wij ook onze eigen ontwikkeling: Imagotag. Het paneel, dat doorgaans wordt gebruikt voor elektronische prijskaartjes in winkels, hebben we aangepast aan onze wensen. We hebben triggers van Moira meegenomen. Het geeft aan in welke staat ze zich bevinden en wanneer ze zich hebben voorgedaan. Sommige ontwikkelaars hebben meldingen in Slack en e-mail achterwege gelaten ten gunste van dit paneel.
Omdat we een vooruitstrevend bedrijf zijn, hebben we Kubernetes ook in dit systeem gemonitord. We hebben het in het systeem opgenomen met behulp van Heapster, dat we in het cluster hebben geïnstalleerd. Het verzamelt gegevens en stuurt deze naar Graphite. Het resultaat is dat het diagram er als volgt uitziet:
Bewakingscomponenten
Hier is een lijst met links naar de componenten die we voor deze taak hebben gebruikt. Ze zijn allemaal open source.
Grafiet:
- go-koolstof:
- fluisteren:
- grafiet-api:
Koolstof-c-relais:
Brubeck:
Verzameld:
Moira:
Grafana:
Heapster:
statistiek
En hier zijn enkele cijfers over hoe het systeem voor ons werkt.
Aggregator (brubeck)
Aantal statistieken: ~300/sec
Interval voor het verzenden van statistieken naar Graphite: 30 sec
Gebruik van serverbronnen: ~ 6% CPU (we hebben het over volwaardige servers); ~ 1 GB RAM; ~3Mbps LAN
Grafiet (go-carbon)
Aantal statistieken: ~ 1 / min
Update-interval statistieken: 30 sec
Opslagschema voor statistieken: 30sec 35d, 5min 90d, 10min 365d (geeft u inzicht in wat er gedurende een lange periode met de service gebeurt)
Gebruik van serverbronnen: ~10% CPU; ~ 20 GB RAM; ~30Mbps LAN
flexibiliteit
Bij Avito hechten wij veel waarde aan flexibiliteit in onze monitoringservice. Waarom is hij eigenlijk zo geworden? Ten eerste zijn de componenten uitwisselbaar: zowel de componenten zelf als hun versies. In de tweede plaats: draagbaarheid. Omdat het hele project open source is, kunt u de code zelf bewerken, wijzigingen aanbrengen en functies implementeren die niet kant-en-klaar beschikbaar zijn. Er worden vrij gebruikelijke stapels gebruikt, voornamelijk Go en Python, dus dit gebeurt vrij eenvoudig.
Hier is een voorbeeld van een echt probleem. Een metriek in Graphite is een bestand. Het heeft een naam. Bestandsnaam = statistieknaam. En er is een manier om daar te komen. Bestandsnamen in Linux zijn beperkt tot 255 tekens. En we hebben (als “interne klanten”) jongens van de databaseafdeling. Ze vertellen ons: “We willen onze SQL-query’s monitoren. En ze zijn geen 255 tekens, maar elk 8 MB. We willen ze weergeven in Grafana, de parameters voor dit verzoek bekijken, en nog beter, we willen de bovenkant van dergelijke verzoeken zien. Het zou geweldig zijn als het in realtime wordt weergegeven. Het zou echt gaaf zijn om ze in de alert te zetten.”
De voorbeeld-SQL-query is als voorbeeld genomen
We hebben een Redis-server opgezet en onze Collectd-plug-ins gebruikt, die naar Postgres gaan en daar alle gegevens vandaan halen en statistieken naar Graphite sturen. Maar we vervangen de statistieknaam door hashes. We sturen tegelijkertijd dezelfde hash als sleutel naar Redis en de volledige SQL-query als waarde. Het enige wat we moeten doen is ervoor zorgen dat Grafana naar Redis kan gaan en deze informatie kan ophalen. We openen de Graphite API omdat... dit is de hoofdinterface voor de interactie van alle monitoringcomponenten met grafiet, en we voeren daar een nieuwe functie in genaamd aliasByHash() - van Grafana krijgen we de naam van de metriek en gebruiken deze in een verzoek aan Redis als sleutel, in antwoord krijgen we de waarde van de sleutel, wat onze “SQL-query” is " Zo hebben we in Grafana een weergave van een SQL-query weergegeven, die daar in theorie onmogelijk kon worden weergegeven, samen met statistieken daarover (oproepen, rijen, totale_tijd, ...).
Resultaten van
Beschikbaarheid. Onze monitoringservice is 24/7 beschikbaar vanuit elke applicatie en elke code. Als u toegang heeft tot opslagfaciliteiten, kunt u gegevens naar de service schrijven. De taal is niet belangrijk, de beslissingen zijn niet belangrijk. Je hoeft alleen maar te weten hoe je een socket opent, daar een metriek plaatst en de socket sluit.
Betrouwbaarheid. Alle componenten zijn fouttolerant en kunnen onze ladingen goed aan.
Lage instapdrempel. Om dit systeem te kunnen gebruiken, hoef je geen programmeertalen en queries in Grafana te leren. Open gewoon uw applicatie, voer er een socket in in die statistieken naar Graphite verzendt, sluit deze, open Grafana, maak daar dashboards en bekijk het gedrag van uw statistieken, waarbij u meldingen ontvangt via Moira.
Onafhankelijkheid. Dit kun je allemaal zelf doen, zonder hulp van DevOps engineers. En dit is een voordeel, omdat u uw project nu kunt volgen, u niemand hoeft te vragen - om aan het werk te gaan of om wijzigingen aan te brengen.
Waar streven we naar?
Alles wat hieronder staat zijn niet zomaar abstracte gedachten, maar iets waar in ieder geval de eerste stappen in zijn gezet.
- Anomaliedetector. We willen een service creëren die naar onze grafietopslag gaat en elke metriek controleert met behulp van verschillende algoritmen. Er zijn al algoritmen die we willen bekijken, er zijn data, we weten hoe we ermee moeten werken.
- Metagegevens. We hebben veel diensten, ze veranderen in de loop van de tijd, net als de mensen die ermee werken. Het voortdurend handmatig bijhouden van documentatie is geen optie. Daarom integreren we nu metadata in onze microservices. Er staat in wie het heeft ontwikkeld, met welke talen het communiceert, SLA-vereisten, waar en naar wie meldingen moeten worden verzonden. Bij het inzetten van een dienst worden alle entiteitsgegevens onafhankelijk aangemaakt. Als resultaat krijg je twee links: één naar triggers, de andere naar dashboards in Grafana.
- Bewaking in elk huis. Wij zijn van mening dat alle ontwikkelaars een dergelijk systeem zouden moeten gebruiken. In dit geval begrijpt u altijd waar uw verkeer zich bevindt, wat ermee gebeurt, waar het terechtkomt en waar de zwakke punten zitten. Als er bijvoorbeeld iets komt en uw service crasht, dan leert u dit niet tijdens een telefoontje van de manager, maar via een waarschuwing, en kunt u onmiddellijk de nieuwste logboeken openen en zien wat daar is gebeurd.
- Hoge performantie. Ons project groeit voortdurend en verwerkt tegenwoordig ongeveer 2 metrische waarden per minuut. Een jaar geleden was dit cijfer 000. En de groei zet zich voort, en dit betekent dat na enige tijd grafiet (gefluister) het schijfsubsysteem zwaar zal gaan belasten. Zoals ik al zei, is dit monitoringsysteem vrij universeel vanwege de uitwisselbaarheid van componenten. Iemand onderhoudt en breidt zijn infrastructuur voortdurend uit, specifiek voor Grafiet, maar wij hebben besloten een andere weg in te slaan: gebruik als opslagplaats voor onze statistieken. Deze transitie is bijna voltooid en binnenkort zal ik je in meer detail vertellen hoe dit is gebeurd: welke moeilijkheden er waren en hoe ze zijn overwonnen, hoe het migratieproces is verlopen, ik zal de componenten beschrijven die als bindend zijn gekozen en hun configuraties.
Bedankt voor uw aandacht! Stel uw vragen over het onderwerp, ik zal proberen hier of in de volgende berichten te antwoorden. Misschien heeft iemand ervaring met het bouwen van een soortgelijk monitoringsysteem of het overstappen naar Clickhouse in een vergelijkbare situatie - deel het in de reacties.
Bron: www.habr.com