Ma projektünk a monolitikus kódon kívül több tucat mikroszolgáltatást is tartalmaz. Mindegyiket ellenőrizni kell. Ezt ilyen léptékben a DevOps mérnökök segítségével megtenni problémás. Kifejlesztettünk egy felügyeleti rendszert, amely szolgáltatásként működik a fejlesztők számára. Önállóan írhatnak mérőszámokat a felügyeleti rendszerbe, használhatják azokat, ezek alapján irányítópultokat építhetnek, és riasztásokat csatolhatnak hozzájuk, amelyek a küszöbértékek elérésekor aktiválódnak. DevOps mérnökök számára csak infrastruktúra és dokumentáció.
Ez a bejegyzés a velünk tartott beszédem átirata a RIT++-nál. Sokan kérték, hogy onnan készítsünk szöveges változatokat a jelentésekből. Ha részt vett a konferencián, vagy megnézte a videót, semmi újat nem fog találni. És mindenki más – üdv a macskában. Elmondom, hogyan jutottunk el egy ilyen rendszerhez, hogyan működik, és hogyan tervezzük frissíteni.
A múlt: tervek és tervek
Hogyan jutottunk el a jelenlegi monitoring rendszerhez? A kérdés megválaszolásához 2015-ig kell elmennünk. Így nézett ki akkor:
Körülbelül 24 csomópontunk volt, amelyek a felügyeletért feleltek. Van egy egész csomag különböző koronák, szkriptek, démonok, amelyek valamilyen módon figyelnek valamit, üzeneteket küldenek és funkciókat hajtanak végre. Úgy gondoltuk, minél tovább megyünk, annál kevésbé lesz életképes egy ilyen rendszer. Nincs értelme továbbfejleszteni: túl nehézkes.
Úgy döntöttünk, hogy kiválasztjuk azokat a monitoring elemeket, amelyeket megtartunk és fejlesztünk, és azokat, amelyeket elhagyunk. 19 darab volt, csak a grafitok, aggregátorok és a Grafana mint műszerfal maradt. De milyen lesz az új rendszer? Mint ez:
Van egy metrikatárolónk: ezek grafitok, amelyek gyors SSD meghajtókra épülnek majd, ezek bizonyos aggregátorok a metrikák számára. Következő - Grafana a műszerfalak megjelenítéséhez és Moira a riasztáshoz. Emellett ki akartunk fejleszteni egy rendszert az anomáliák felkutatására.
Szabvány: Monitoring 2.0
Így néztek ki a tervek 2015-ben, de nem csak az infrastruktúrát és magát a szolgáltatást kellett elkészítenünk, hanem a dokumentációt is. Kidolgoztunk magunknak egy vállalati szabványt, amit monitoring 2.0-nak hívunk. Milyen követelmények voltak a rendszerrel szemben?
- állandó rendelkezésre állás;
- mérőszámok tárolási időköze = 10 másodperc;
- mérőszámok és műszerfalak strukturált tárolása;
- SLA > 99,99%
- eseménymutatók gyűjtése UDP-n keresztül (!).
Szükségünk volt az UDP-re, mert nagy a forgalom és az események, amelyek mutatókat generálnak. Ha mindet egyszerre grafitba írod, a tároló összeomlik. Minden metrikához első szintű előtagot is választottunk.
Mindegyik előtagnak van valamilyen tulajdonsága. Vannak mérőszámok a szerverekre, hálózatokra, tárolókra, erőforrásokra, alkalmazásokra stb. Világos, szigorú, gépelt szűrés került bevezetésre, ahol elfogadjuk az első szintű mutatókat, a többit pedig egyszerűen elhagyjuk. Így terveztük ezt a rendszert 2015-ben. Mi van a jelenben?
Jelen: a felügyeleti komponensek kölcsönhatásának diagramja
Mindenekelőtt az alkalmazásokat figyeljük: PHP kódunkat, alkalmazásainkat és mikroszolgáltatásainkat – egyszóval mindent, amit fejlesztőink írnak. Minden alkalmazás UDP-n keresztül küldi a metrikákat a Brubeck aggregátornak (statsd, átírva C-ben). Ez bizonyult a leggyorsabbnak a szintetikus teszteken. És elküldi a már összesített mérőszámokat a Graphite-nak TCP-n keresztül.
Van egyfajta mérőszáma, az úgynevezett időzítő. Ez egy nagyon kényelmes dolog. Például minden egyes felhasználói kapcsolathoz a szolgáltatáshoz küld egy metrikát válaszidővel Brubecknek. Millió válasz érkezett, de az összesítő csak 10 mérőszámot adott vissza. Megvan a megjelentek száma, a maximális, minimális és átlagos válaszidő, a medián és a 4 százalékos. Ezután az adatok átkerülnek a Graphite-ba, és mindezt élőben látjuk.
Összesítjük a hardver-, szoftver-, rendszermérőszámokat és a régi Munin-felügyeleti rendszerünket is (2015-ig működött nálunk). Mindezt a C daemon CollectD-n keresztül gyűjtjük (egy csomó különféle plugin van beleépítve, le tudja kérni annak a gazdagépnek az összes erőforrását, amelyre telepítve van, csak adja meg a konfigurációban, hogy hova írja az adatokat) és azon keresztül írjuk az adatokat a Graphite-ba. Támogatja a python beépülő modulokat és a shell szkripteket is, így saját egyéni megoldásokat írhat: A CollectD ezeket az adatokat egy helyi vagy távoli gazdagépről gyűjti össze (Curl feltételezésével), és elküldi a Graphite-nak.
Ezután az összes összegyűjtött mérőszámot elküldjük a Carbon-c-relay-nek. Ez a Graphite Carbon Relay megoldása, amelyet C-ben módosítottak. Ez egy útválasztó, amely összegyűjti az összes mérőszámot, amelyet aggregátorainktól küldünk, és a csomópontokhoz irányítja. Az útválasztási szakaszban is ellenőrzi a metrikák érvényességét. Először is meg kell felelniük a korábban bemutatott előtagsémának, másodszor pedig a grafitra érvényesek. Ellenkező esetben leesnek.
A Carbon-c-relé ezután elküldi a metrikákat a grafitfürtnek. A mérőszámok fő tárolójaként a Go-ban átírt Carbon-cache-t használjuk. A Go-carbon többszálasságának köszönhetően messze felülmúlja a Carbon-cache-t. Adatokat fogad és lemezekre írja a whisper csomag segítségével (standard, python nyelven írva). A tárolóink adatainak kiolvasásához a Graphite API-t használjuk. Sokkal gyorsabb, mint a hagyományos Graphite WEB. Mi történik ezután az adatokkal?
Grafánába mennek. A grafit klasztereinket használjuk fő adatforrásként, valamint a Grafana webes felületet a mutatók megjelenítéséhez és az irányítópultok építéséhez. A fejlesztők minden szolgáltatásukhoz saját irányítópultot készítenek. Ezután ezek alapján grafikonokat készítenek, amelyek megjelenítik az alkalmazásaikból írt metrikákat. A Grafana mellett van SLAM is. Ez egy python démon, amely a grafitból származó adatok alapján számítja ki az SLA-t. Mint már mondtam, több tucat mikroszolgáltatásunk van, amelyek mindegyikének megvannak a saját követelményei. A SLAM használatával átmegyünk a dokumentációba, és összehasonlítjuk a Graphite tartalmával, és összehasonlítjuk, hogy a követelmények mennyire egyeznek szolgáltatásaink elérhetőségével.
Menjünk tovább: riasztás. Erős rendszer – Moira – segítségével szerveződik. Független, mert saját grafitja van a motorháztető alatt. Az SKB "Kontur" srácai fejlesztették ki, python és Go nyelven írták, teljesen nyílt forráskódú. Moira ugyanazt az áramlást kapja, mint a grafit. Ha valamilyen okból kimerül a tárhely, a riasztás továbbra is működik.
A Moirát a Kubernetesben telepítettük; Redis-kiszolgálók fürtjét használja fő adatbázisként. Az eredmény egy hibatűrő rendszer lett. Összehasonlítja a metrikafolyamot a triggerek listájával: ha nincs benne említés, akkor eldobja a metrikát. Így percenként gigabájtnyi metrikát képes megemészteni.
Csatoltunk hozzá egy vállalati LDAP-t is, melynek segítségével a vállalati rendszer minden felhasználója a meglévő (vagy újonnan létrehozott) triggerek alapján értesítéseket hozhat létre magának. Mivel a Moira grafitot tartalmaz, minden funkcióját támogatja. Tehát először vedd a sort, és másold be a Grafanába. Nézze meg, hogyan jelennek meg az adatok a grafikonokon. És akkor veszi ugyanazt a sort, és bemásolja a Moira-ba. Felfüggeszted korlátokkal, és figyelmeztetést kapsz a kimeneten. Mindehhez nincs szükség speciális ismeretekre. Moira tud riasztani SMS-ben, e-mailben, Jira-n, Slack-en... Egyedi szkriptek végrehajtását is támogatja. Amikor egy trigger történik vele, és feliratkozott egy egyéni szkriptre vagy bináris fájlra, lefuttatja azt, és elküldi a JSON-t az stdin-nek ehhez a binárishoz. Ennek megfelelően a programnak elemeznie kell azt. Az Önön múlik, hogy mit kezd ezzel a JSON-nal. Ha akarod, küldd el a Telegramnak, ha akarod, nyiss feladatokat a Jira-ban, csinálj bármit.
A riasztáshoz saját fejlesztést is használunk - Imagotag. Az üzletekben általában elektronikus árcédulákra használt panelt az igényeinknek megfelelően alakítottuk. Moirától hoztunk hozzá triggereket. Azt jelzi, hogy milyen állapotban vannak és mikor történtek. A fejlesztők egy része elhagyta a Slack értesítéseit és az e-maileket ennek a panelnek a javára.
Nos, mivel progresszív cég vagyunk, a Kuberneteset is ebben a rendszerben figyeltük. A klaszterbe telepített Heapster segítségével iktattuk be a rendszerbe, az adatokat gyűjti és elküldi a Graphite-nak. Ennek eredményeként a diagram így néz ki:
Monitoring komponensek
Itt található az ehhez a feladathoz használt összetevőkre mutató hivatkozások listája. Mindegyik nyílt forráskódú.
Grafit:
- go-carbon:
- suttogás:
- grafit-api:
Carbon-c-relé:
Brubeck:
Összegyűjtve:
Moira:
Grafana:
Heapster:
Statisztika
És itt van néhány szám arról, hogyan működik nálunk a rendszer.
Aggregátor (brubeck)
Mutatók száma: ~300 000/sec
A mérőszámok Grafitba küldésének időköze: 30 mp
Szerver erőforrás felhasználás: ~ 6% CPU (teljes értékű szerverekről beszélünk); ~ 1 Gb RAM; ~3 Mbps LAN
Grafit (go-karbon)
A mutatók száma: ~ 1 600 000 / perc
A mérőszám frissítési időköze: 30 mp
Mutatótárolási séma: 30 mp 35 d, 5 perc 90 d, 10 perc 365 d (megértést ad arról, hogy mi történik a szolgáltatással hosszú időn keresztül)
Szerver erőforrás felhasználás: ~10% CPU; ~ 20 Gb RAM; ~30 Mbps LAN
rugalmasság
Mi, az Avito, nagyon fontosnak tartjuk a rugalmasságot a felügyeleti szolgáltatásunkban. Tulajdonképpen miért lett ilyen? Először is, alkatrészei felcserélhetők: maguk az alkatrészek és azok változatai is. Másodszor a támogathatóság. Mivel a teljes projekt nyílt forráskódú, saját maga szerkesztheti a kódot, módosíthatja, és olyan funkciókat valósíthat meg, amelyek nem érhetők el a dobozból. Elég gyakori veremeket használnak, főleg a Go és a Python, így ez meglehetősen egyszerűen történik.
Itt van egy példa egy valós problémára. A Graphite metrikája egy fájl. Ennek neve van. Fájlnév = metrika neve. És van mód oda eljutni. A Linux fájlnevek 255 karakterre korlátozódnak. És vannak (mint „belső ügyfeleink”) srácok az adatbázis részlegről. Azt mondják nekünk: „Figyelni akarjuk SQL-lekérdezéseinket. És nem 255 karakter, hanem egyenként 8 MB. Meg akarjuk jeleníteni őket a Grafanában, látni a kérés paramétereit, és ami még jobb, látni szeretnénk az ilyen kérések tetejét. Nagyszerű lesz, ha valós időben jelenik meg. Nagyon jó lenne riasztásba helyezni őket.”
A példa SQL-lekérdezés példája a forrásból
Beállítunk egy Redis szervert, és a Collectd beépülő moduljainkat használjuk, amelyek a Postgreshez mennek, és onnan veszik az összes adatot, és elküldik a mérőszámokat a Graphite-nak. De a metrika nevét kivonatokra cseréljük. Ugyanazt a hash-t egyszerre küldjük el a Redisnek kulcsként, és a teljes SQL-lekérdezést értékként. Csak meg kell győződnünk arról, hogy Grafana el tud menni Redishez, és átveheti ezeket az információkat. Megnyitjuk a Graphite API-t, mert... ez a fő interfész az összes megfigyelő komponens grafittal való interakciójához, és ott beírunk egy új függvényt aliasByHash() néven - a Grafana-ból megkapjuk a metrika nevét, és kulcsként használjuk a Redis-nek küldött kérésben. válaszként megkapjuk a kulcs értékét, ami a mi „SQL lekérdezésünk” Így a Grafana-ban megjelenítettük egy SQL-lekérdezés megjelenítését, amelyet elméletileg lehetetlen volt ott megjeleníteni, a rá vonatkozó statisztikákkal együtt (hívások, sorok, teljes_idő, ...).
Eredményei
Elérhetőség. Monitoring szolgáltatásunk éjjel-nappal elérhető bármely alkalmazásból és bármilyen kódból. Ha van hozzáférése tárolóeszközökhöz, akkor adatokat írhat a szolgáltatásba. Nem a nyelv a fontos, nem a döntések. Csak tudnod kell, hogyan kell kinyitni egy aljzatot, oda kell tenni egy mérőszámot és bezárni a foglalatot.
Megbízhatóságát. Minden alkatrész hibatűrő és jól bírja a terhelésünket.
Alacsony belépési akadály. A rendszer használatához nem kell programozási nyelveket és lekérdezéseket tanulnia a Grafana-ban. Csak nyissa meg az alkalmazást, írjon be egy aljzatot, amely elküldi a mérőszámokat a Graphite-nak, zárja be, nyissa meg a Grafanát, hozzon létre irányítópultokat, és nézze meg a metrikák viselkedését, értesítéseket kapva a Moirán keresztül.
Függetlenség. Mindezt saját maga is megteheti, a DevOps mérnökei segítsége nélkül. Ez pedig előny, mert már most nyomon követheti projektjét, nem kell senkit megkérdeznie – sem a munka megkezdéséhez, sem a változtatásokhoz.
Mire törekszünk?
Az alábbiakban felsorolt dolgok nem csupán elvont gondolatok, hanem valami, ami felé legalább az első lépéseket megtettük.
- Anomália detektor. Olyan szolgáltatást szeretnénk létrehozni, amely a Graphite-tárolóinkba kerül, és különböző algoritmusok segítségével ellenőrzi az egyes mérőszámokat. Már vannak algoritmusok, amiket meg akarunk nézni, vannak adatok, tudjuk, hogyan kell velük dolgozni.
- Metaadatok. Sok szolgáltatásunk van, ezek idővel változnak, akárcsak a velük dolgozók. A dokumentáció manuális folyamatos karbantartása nem lehetséges. Ezért most metaadatokat ágyazunk be mikroszolgáltatásainkba. Leírja, hogy ki fejlesztette ki, milyen nyelvekkel kommunikál, az SLA-követelményeket, hova és kinek kell küldeni az értesítéseket. Egy szolgáltatás üzembe helyezésekor az összes entitásadat függetlenül jön létre. Ennek eredményeként két linket kap – az egyiket a triggerekhez, a másikat a Grafana irányítópultjaihoz.
- Monitoring minden otthonban. Úgy gondoljuk, hogy minden fejlesztőnek ilyen rendszert kell használnia. Ilyenkor mindig megérted, hol van a forgalom, mi történik vele, hol esik, hol vannak a gyengeségei. Ha például jön valami és összeomlik a szolgáltatása, akkor erről nem a menedzser hívása során, hanem riasztásból értesül, és azonnal megnyithatja a legfrissebb naplókat, és megnézheti, mi történt ott.
- Nagy teljesítményű. Projektünk folyamatosan növekszik, és ma körülbelül 2 000 000 metrikus értéket dolgoz fel percenként. Egy évvel ezelőtt ez a szám 500 000. És a növekedés folytatódik, és ez azt jelenti, hogy egy idő után a Graphite (suttogás) elkezdi erősen terhelni a lemez alrendszerét. Mint már mondtam, ez a megfigyelő rendszer meglehetősen univerzális az alkatrészek felcserélhetősége miatt. Valaki kifejezetten a Graphite számára karbantartja és folyamatosan bővíti az infrastruktúráját, de úgy döntöttünk, hogy más utat választunk: használunk mérőszámaink tárházaként. Ez az átállás már majdnem befejeződött, és hamarosan részletesebben is elmesélem, hogy ez hogyan történt: milyen nehézségek voltak és hogyan sikerült leküzdeni őket, hogyan zajlott a migrációs folyamat, leírom a kötésként kiválasztott összetevőket és azok konfigurációit.
Köszönöm a figyelmet! Tegye fel kérdéseit a témában, igyekszem válaszolni itt vagy a következő bejegyzésekben. Esetleg valakinek van tapasztalata hasonló felügyeleti rendszer kiépítésében, vagy hasonló helyzetben Clickhouse-ra váltva - ossza meg kommentben.
Forrás: will.com