Nykyään projektiimme kuuluu monoliittisen koodin lisäksi kymmeniä mikropalveluita. Jokaista niistä on seurattava. Tämän tekeminen tällaisessa mittakaavassa DevOps-insinöörien avulla on ongelmallista. Olemme kehittäneet seurantajärjestelmän, joka toimii kehittäjien palveluna. He voivat itsenäisesti kirjoittaa mittareita valvontajärjestelmään, käyttää niitä, rakentaa niiden pohjalta kojetauluja ja liittää niihin hälytyksiä, jotka käynnistyvät, kun kynnysarvot saavutetaan. DevOps-insinööreille vain infrastruktuuri ja dokumentaatio.
Tämä viesti on transkriptio meidän kanssamme pitämästäni puheesta osoitteessa RIT++. Monet ihmiset pyysivät meitä tekemään sieltä tekstiversioita raporteista. Jos olit konferenssissa tai katsoit videon, et löydä mitään uutta. Ja kaikki muut - tervetuloa kissaan. Kerron sinulle, kuinka päädyimme tällaiseen järjestelmään, miten se toimii ja kuinka aiomme päivittää sen.
Menneisyys: suunnitelmat ja suunnitelmat
Miten päädyimme nykyiseen valvontajärjestelmään? Jotta voit vastata tähän kysymykseen, sinun on siirryttävä vuoteen 2015. Tältä se silloin näytti:
Meillä oli noin 24 solmua, jotka vastasivat valvonnasta. On olemassa koko paketti erilaisia kruunuja, skriptejä, demoneita, jotka jollakin tavalla valvovat jotain, lähettävät viestejä ja suorittavat toimintoja. Ajattelimme, että mitä pidemmälle menemme, sitä vähemmän elinkelpoinen tällainen järjestelmä olisi. Sitä on turha kehittää: se on liian hankalaa.
Päätimme valita ne seurantaelementit, jotka säilytämme ja kehitämme, ja ne, joista hylkäämme. Niitä oli 19. Jäljelle jäi vain grafiitit, aggregaattorit ja Grafana kojelautana. Mutta miltä uusi järjestelmä näyttää? Kuten tämä:
Meillä on mittausmuisti: nämä ovat grafiitteja, jotka perustuvat nopeisiin SSD-asemiin, nämä ovat tiettyjä mittareiden aggregaattoreita. Seuraavaksi - Grafana kojetaulujen näyttämiseen ja Moira hälytykseen. Halusimme myös kehittää järjestelmän poikkeavuuksien etsimiseen.
Vakio: Valvonta 2.0
Tältä suunnitelmat näyttivät vuonna 2015. Meidän piti kuitenkin valmistella infrastruktuurin ja itse palvelun lisäksi myös sen dokumentaatio. Olemme kehittäneet itsellemme yritysstandardin, jota kutsumme seuranta 2.0:ksi. Mitkä olivat järjestelmän vaatimukset?
- jatkuva saatavuus;
- mittareiden tallennusväli = 10 sekuntia;
- Mittareiden ja kojetaulujen jäsennelty tallennus;
- Palvelusopimus > 99,99 %
- tapahtumatietojen kerääminen UDP:n kautta (!).
Tarvitsimme UDP:tä, koska meillä on suuri liikennevirta ja mittareita luovia tapahtumia. Jos kirjoitat ne kaikki kerralla grafiitille, tallennustila romahtaa. Valitsimme myös ensimmäisen tason etuliitteet kaikille mittareille.
Jokaisella etuliitteellä on jokin ominaisuus. Palvelimille, verkoille, säilöille, resursseille, sovelluksille ja niin edelleen on mittareita. Selkeä, tiukka, kirjoitettu suodatus on otettu käyttöön, jossa hyväksymme ensimmäisen tason mittarit ja hylkäämme loput. Näin suunnittelimme tämän järjestelmän vuonna 2015. Mitä nykyisyydessä on?
Esitys: kaavio valvontakomponenttien vuorovaikutuksesta
Ensinnäkin valvomme sovelluksia: PHP-koodiamme, sovelluksiamme ja mikropalvelujamme - lyhyesti sanottuna kaikkea, mitä kehittäjämme kirjoittavat. Kaikki sovellukset lähettävät mittareita UDP:n kautta Brubeck-aggregaattoriin (statsd, kirjoitettu uudelleen C-kielellä). Se osoittautui nopeimmaksi synteettisissä testeissä. Ja se lähettää jo kootut tiedot Graphitelle TCP:n kautta.
Siinä on eräänlaisia mittareita, joita kutsutaan ajastimiksi. Tämä on erittäin kätevä asia. Esimerkiksi jokaisesta palveluun liittyneestä käyttäjästä lähetät Brubeckille mittarin, jossa on vasteaika. Miljoona vastausta saapui, mutta aggregaattori palautti vain 10 mittaria. Sinulla on saapuneiden ihmisten määrä, enimmäis-, vähimmäis- ja keskimääräinen vasteaika, mediaani ja 4 prosenttipistettä. Sitten tiedot siirretään Graphitelle ja näemme sen kaiken livenä.
Meillä on myös laitteisto-, ohjelmisto-, järjestelmämittareita ja vanhaa Munin-seurantajärjestelmäämme koskeva aggregointi (se toimi meillä vuoteen 2015 asti). Keräämme kaiken tämän C-daemon CollectD:n kautta (sitä on sisäänrakennettu joukko erilaisia laajennuksia, se voi polttaa kaikki isäntäjärjestelmän resurssit, johon se on asennettu, määritä vain asetuksissa, mihin tiedot kirjoitetaan) ja kirjoittaa tiedot Graphiteen sen kautta. Se tukee myös python-laajennuksia ja komentosarjoja, joten voit kirjoittaa omia mukautettuja ratkaisujasi: CollectD kerää nämä tiedot paikalliselta tai etäisännältä (olettaen, että Curl) ja lähettää ne Graphitelle.
Sitten lähetämme kaikki keräämämme mittarit Carbon-c-releelle. Tämä on Graphiten Carbon Relay -ratkaisu, jota on muokattu C:ssä. Tämä on reititin, joka kerää kaikki mittarit, jotka lähetämme aggregaattoreistamme ja reitittää ne solmuihin. Myös reititysvaiheessa se tarkistaa mittareiden oikeellisuuden. Ensinnäkin niiden on vastattava aiemmin osoittamani etuliitekaaviota, ja toiseksi ne ovat voimassa grafiitille. Muuten ne putoavat.
Carbon-c-rele lähettää sitten mittarit grafiittiklusteriin. Käytämme Go:ssa uudelleen kirjoitettua Carbon-cachea mittareiden päävarastona. Go-carbon on monisäikeisyytensä ansiosta huomattavasti parempi kuin Carbon-cache. Se vastaanottaa tietoja ja kirjoittaa sen levyille whisper-paketin avulla (vakio, kirjoitettu pythonilla). Käytämme Graphite API:ta tietojen lukemiseen varastoistamme. Se on paljon nopeampi kuin tavallinen Graphite WEB. Mitä datalle tapahtuu seuraavaksi?
He menevät Grafanaan. Käytämme grafiittiklustereitamme pääasiallisena tietolähteenä, ja meillä on Grafana verkkokäyttöliittymänä mittareiden näyttämiseen ja kojetaulujen rakentamiseen. Kehittäjät luovat jokaiselle palvelulleen oman kojelautansa. Sitten he rakentavat niiden pohjalta kaavioita, jotka näyttävät sovelluksistaan kirjoittamansa mittarit. Grafanan lisäksi meillä on myös SLAM. Tämä on python-demoni, joka laskee SLA:n grafiitin tietojen perusteella. Kuten jo sanoin, meillä on useita kymmeniä mikropalveluita, joista jokaisella on omat vaatimuksensa. SLAMin avulla siirrymme dokumentaatioon ja vertaamme sitä Graphiten sisältöön ja vertaamme, kuinka hyvin vaatimukset vastaavat palveluidemme saatavuutta.
Mennään pidemmälle: hälytys. Se on järjestetty vahvalla järjestelmällä - Moira. Se on itsenäinen, koska siinä on oma grafiitti konepellin alla. SKB "Konturin" kaverien kehittämä, kirjoitettu pythonilla ja Golla, täysin avoimella lähdekoodilla. Moira saa saman virtauksen kuin grafiitit. Jos varastosi jostain syystä kuolee, hälytys toimii edelleen.
Otimme Moiran käyttöön Kubernetesissa; se käyttää päätietokantana Redis-palvelinklusteria. Tuloksena oli vikasietoinen järjestelmä. Se vertaa mittausvirtaa triggerien luetteloon: jos siinä ei ole mainintoja, se pudottaa mittarin. Joten se pystyy sulattamaan gigatavuja mittareita minuutissa.
Liittimme siihen myös yrityksen LDAP:n, jonka avulla jokainen yritysjärjestelmän käyttäjä voi luoda itselleen ilmoituksia olemassa olevien (tai uusien) triggereiden perusteella. Koska Moira sisältää grafiittia, se tukee kaikkia sen ominaisuuksia. Joten otat ensin linjan ja kopioit sen Grafanaan. Katso, kuinka tiedot näkyvät kaavioissa. Ja sitten otat saman rivin ja kopioit sen Moiraan. Voit ripustaa sen rajoituksin ja saat hälytyksen ulostulossa. Tehdäksesi kaiken tämän et tarvitse erityisiä tietoja. Moira voi hälyttää tekstiviestillä, sähköpostilla, Jiralla, Slackilla... Se tukee myös mukautettujen komentosarjojen suorittamista. Kun hänelle tapahtuu laukaisu ja hän on tilannut mukautetun skriptin tai binaarin, hän suorittaa sen ja lähettää JSON-tiedoston tämän binaarin stdinille. Tämän mukaisesti ohjelman on jäsennettävä se. Se, mitä teet tällä JSON:lla, on sinun. Jos haluat, lähetä se Telegramiin, jos haluat, avaa tehtäviä Jirassa, tee mitä tahansa.
Käytämme hälytyksessä myös omaa kehitystyötämme - Imagotag. Mukautimme paneelin, jota yleensä käytetään sähköisiin hintalappuihin kaupoissa, tarpeisiimme sopivaksi. Toimme siihen laukaisimia Moirasta. Se osoittaa, missä tilassa ne ovat ja milloin ne tapahtuivat. Jotkut kehitystyöntekijät hylkäsivät Slackin ilmoitukset ja sähköpostit tämän paneelin hyväksi.
No, koska olemme edistyksellinen yritys, seurasimme myös Kubernetes tässä järjestelmässä. Lisäsimme sen järjestelmään Heapsterilla, jonka asensimme klusteriin, se kerää dataa ja lähettää sen Graphitelle. Tämän seurauksena kaavio näyttää tältä:
Valvontakomponentit
Tässä on luettelo linkeistä komponentteihin, joita käytimme tässä tehtävässä. Kaikki ne ovat avoimen lähdekoodin.
Grafiitti:
- go-carbon:
- kuiskaus:
- grafiitti-api:
Hiili-c-rele:
Brubeck:
Kerätty:
Moira:
Grafana:
Heapster:
Tilastot
Ja tässä on joitain lukuja siitä, kuinka järjestelmä toimii meillä.
Aggregaattori (brubeck)
Mittareiden määrä: ~300 000/s
Mittareiden lähetysväli grafiittiin: 30 sekuntia
Palvelinresurssien käyttö: ~ 6% CPU (puhumme täysimittaisista palvelimista); ~ 1 Gt RAM-muistia; ~3 Mbps LAN
Grafiitti (go-hiili)
Mittareiden lukumäärä: ~ 1 600 000 / min
Mittareiden päivitysväli: 30 sekuntia
Mittareiden tallennuskaavio: 30 s 35 d, 5 min 90 d, 10 min 365 d (antaa käsityksen siitä, mitä palvelulle tapahtuu pitkän ajan kuluessa)
Palvelinresurssien käyttö: ~10 % CPU; ~ 20 Gt RAM-muistia; ~30 Mbps LAN
joustavuus
Me Avitolla arvostamme todella joustavuutta valvontapalvelussamme. Miksi hänestä tuli oikeasti tällainen? Ensinnäkin sen komponentit ovat keskenään vaihdettavissa: sekä itse komponentit että niiden versiot. Toiseksi tuettavuus. Koska koko projekti on avoimen lähdekoodin, voit muokata koodia itse, tehdä muutoksia ja toteuttaa toimintoja, jotka eivät ole heti saatavilla. Käytetään melko yleisiä pinoja, pääasiassa Go ja Python, joten tämä tehdään yksinkertaisesti.
Tässä on esimerkki todellisesta ongelmasta. Grafiitin mittari on tiedosto. Sillä on nimi. Tiedoston nimi = mittarin nimi. Ja sinne on tapa päästä. Linuxissa tiedostonimien pituus on rajoitettu 255 merkkiin. Ja meillä on ("sisäisinä asiakkaina") kavereita tietokantaosastolta. He kertovat meille: "Haluamme valvoa SQL-kyselyiämme. Ja ne eivät ole 255 merkkiä, vaan 8 Mt kukin. Haluamme näyttää ne Grafanassa, nähdä tämän pyynnön parametrit, ja mikä vielä parempaa, haluamme nähdä tällaisten pyyntöjen yläosan. On hienoa, jos se näytetään reaaliajassa. Olisi todella siistiä laittaa heidät hälytystilaan."
Esimerkki SQL-kyselystä on otettu esimerkkinä kohteesta
Asennamme Redis-palvelimen ja käytämme Collectd-laajennuksiamme, jotka menevät Postgresiin ja ottavat sieltä kaikki tiedot lähettäen mittareita Graphitelle. Mutta korvaamme mittarin nimen tiivisteillä. Samanaikaisesti lähetämme saman hashin Redikselle avaimena ja koko SQL-kyselyn arvona. Meidän tarvitsee vain varmistaa, että Grafana voi mennä Redikseen ja ottaa nämä tiedot. Avaamme Graphite APIn, koska... tämä on päärajapinta kaikkien valvontakomponenttien vuorovaikutukselle grafiitin kanssa, ja syötämme sinne uuden funktion nimeltä aliasByHash() - Grafanasta saamme metriikan nimen ja käytämme sitä Redis-pyynnössä avaimena. vastauksena saamme avaimen arvon, joka on "SQL-kyselymme" " Näin ollen näytimme Grafanassa SQL-kyselyn näytön, jota teoriassa oli mahdotonta näyttää siellä, sekä sen tilastot (puhelut, rivit, total_time, ...).
Tulokset
Saatavuus. Valvontapalvelumme on käytettävissä 24/7 mistä tahansa sovelluksesta ja mistä tahansa koodista. Jos sinulla on pääsy varastotiloihin, voit kirjoittaa tietoja palveluun. Kieli ei ole tärkeä, päätökset eivät ole tärkeitä. Sinun tarvitsee vain osata avata pistorasia, laittaa siihen mittari ja sulkea pistorasia.
Luotettavuutta. Kaikki komponentit ovat vikasietoisia ja kestävät kuormamme hyvin.
Matala pääsyn este. Jotta voit käyttää tätä järjestelmää, sinun ei tarvitse opetella ohjelmointikieliä ja kyselyitä Grafanassa. Avaa vain sovelluksesi, syötä siihen pistorasia, joka lähettää mittareita Graphitelle, sulje se, avaa Grafana, luo siellä koontinäyttöjä ja katso mittareidesi käyttäytymistä ja vastaanottaa ilmoituksia Moiran kautta.
Itsenäisyys. Voit tehdä kaiken tämän itse ilman DevOps-insinöörien apua. Ja tämä on etu, koska voit seurata projektiasi juuri nyt, sinun ei tarvitse pyytää ketään - joko aloittamaan töitä tai tekemään muutoksia.
Mihin pyrimme?
Kaikki alla lueteltu ei ole vain abstrakteja ajatuksia, vaan jotain, jota kohti ainakin ensimmäiset askeleet on otettu.
- Anomalian ilmaisin. Haluamme luoda palvelun, joka menee grafiittivarastoihimme ja tarkistaa jokaisen mittarin eri algoritmeilla. On jo olemassa algoritmeja, joita haluamme tarkastella, on dataa, osaamme työskennellä sen kanssa.
- Metatiedot. Meillä on monia palveluita, ne muuttuvat ajan myötä, samoin kuin niiden parissa työskentelevät ihmiset. Asiakirjojen jatkuva ylläpito manuaalisesti ei ole vaihtoehto. Siksi upotamme nyt metatietoja mikropalveluihimme. Siinä kerrotaan, kuka sen on kehittänyt, kielet, joiden kanssa se on vuorovaikutuksessa, SLA-vaatimukset, minne ja kenelle ilmoitukset tulee lähettää. Kun palvelu otetaan käyttöön, kaikki entiteettitiedot luodaan itsenäisesti. Tuloksena saat kaksi linkkiä - yhden laukaisimiin ja toisen hallintapaneeleihin Grafanassa.
- Valvonta jokaisessa kodissa. Uskomme, että kaikkien kehittäjien tulisi käyttää tällaista järjestelmää. Tässä tapauksessa ymmärrät aina, missä liikenne on, mitä sille tapahtuu, mihin se putoaa, missä sen heikkoudet ovat. Jos esimerkiksi jotain tulee ja kaataa palvelusi, niin saat tietää siitä ei esimiehen puhelun aikana, vaan hälytyksestä, ja voit heti avata uusimmat lokit ja katsoa mitä siellä tapahtui.
- Korkea suorituskyky. Projektimme kasvaa jatkuvasti, ja nykyään se käsittelee noin 2 000 000 metriarvoa minuutissa. Vuosi sitten tämä luku oli 500 000. Ja kasvu jatkuu, mikä tarkoittaa, että jonkin ajan kuluttua Graphite (kuiskaus) alkaa rasittaa levyalijärjestelmää voimakkaasti. Kuten jo sanoin, tämä valvontajärjestelmä on melko yleinen komponenttien vaihdettavuuden vuoksi. Joku ylläpitää ja laajentaa jatkuvasti infrastruktuuriaan nimenomaan grafiittia varten, mutta päätimme valita toisen reitin: käytön mittareidemme varastona. Tämä siirtymä on melkein valmis, ja pian kerron sinulle tarkemmin, kuinka tämä tehtiin: mitä vaikeuksia oli ja miten ne voitettiin, miten siirtoprosessi eteni, kuvailen sitoviksi valitut komponentit ja niiden kokoonpanot.
Kiitos huomiostasi! Esitä kysymyksiä aiheesta, yritän vastata täällä tai seuraavissa viesteissä. Ehkä jollain on kokemusta vastaavan seurantajärjestelmän rakentamisesta tai Clickhouseen vaihtamisesta vastaavassa tilanteessa - jaa se kommenteissa.
Lähde: will.com