A naplók a rendszer fontos részét képezik, lehetővé téve annak megértését, hogy a rendszer megfelelően működik (vagy nem működik). A mikroszolgáltatási architektúrában a naplókkal való munka egy külön tudományág lesz egy speciális olimpián. Egy csomó kérdést kell egyszerre megválaszolni:
- hogyan írjunk naplókat egy alkalmazásból;
- hol kell naplókat írni;
- hogyan kell a rönköket tárolásra és feldolgozásra szállítani;
- hogyan kell feldolgozni és tárolni a naplókat.
A jelenleg elterjedt konténerezési technológiák alkalmazása homokot ad a gereblye tetejére a probléma megoldási lehetőségeinek körébe.
Pontosan erről szól Jurij Bushmelev „A gereblyék térképe a rönkgyűjtés és -szállítás terén” című jelentésének átirata.
Akit érdekel, kérem a macska alá.
A nevem Jurij Bushmelev. A Lazadánál dolgozom. Ma arról fogok beszélni, hogyan készítettük a rönköket, hogyan gyűjtöttük, és mit írunk oda.
Honnan jöttünk? Kik vagyunk mi? A Lazada az első számú online kiskereskedő Délkelet-Ázsia hat országában. Mindezek az országok adatközpontjaink között vannak elosztva. Jelenleg összesen 1 adatközpont működik. Miért fontos ez? Mert bizonyos döntések azért születtek, mert nagyon gyenge a kapcsolat a központok között. Mikroszolgáltatási architektúrával rendelkezünk. Meglepődve tapasztaltam, hogy már 4 mikroszolgáltatásunk van. Amikor elkezdtem a naplókkal a feladatot, még csak 80. Plusz van egy elég nagy darab PHP-hagyaték is, amivel nekem is együtt kell élnem és el kell viselnem. Mindez jelenleg több mint 20 millió üzenetet generál percenként a rendszer egészére nézve. A továbbiakban megmutatom, hogyan próbálunk ezzel együtt élni, és miért van ez így.
Valahogy együtt kell élni ezzel a 6 millió üzenettel. Mit tegyünk velük? 6 millió üzenetre van szüksége:
- küldje el az alkalmazásból
- átvételre fogadni
- elemzésre és tárolásra szállítjuk.
- elemezni
- tárolja valahogy.
Amikor hárommillió üzenet jelent meg, nagyjából ugyanúgy néztem ki. Mert alig néhány fillérrel kezdtük. Nyilvánvaló, hogy az alkalmazásnaplók oda vannak írva. Például nem tudtam csatlakozni az adatbázishoz, tudtam csatlakozni az adatbázishoz, de nem tudtam olvasni semmit. De ezen kívül minden mikroszolgáltatásunk hozzáférési naplót is ír. Minden, a mikroszolgáltatáshoz érkező kérés rögzítésre kerül a naplóban. Miért csináljuk ezt? A fejlesztők szeretnének nyomon követni. Minden hozzáférési napló tartalmaz egy nyomkövetési mezőt, amelynek segítségével egy speciális felület az egész láncot letekerheti, és gyönyörűen megjeleníti a nyomkövetést. A nyomkövetés megmutatja, hogyan sikerült a kérés, és ez segít fejlesztőinknek az azonosítatlan szemét gyors kezelésében.
Hogyan lehet ezzel együtt élni? Most röviden leírom a lehetőségek területét - hogyan lehet általában megoldani ezt a problémát. Hogyan lehet megoldani a naplók gyűjtésének, továbbításának és tárolásának problémáját.
Hogyan írjunk egy alkalmazásból? Nyilvánvaló, hogy különféle módok léteznek. Különösen a legjobb gyakorlat van, ahogy a divatos elvtársak mondják. Kétféle old school létezik, ahogy a nagypapák mondták. Vannak más módok is.
Körülbelül hasonló a helyzet a rönkgyűjtéssel. Ennek a résznek a megoldására nincs sok lehetőség. Már több is van belőlük, de még nem annyi.
Ám a szállítással és az azt követő elemzéssel a változatok száma robbanásszerűen megnő. Most nem írok le minden lehetőséget. Szerintem a főbb lehetőségeket mindenki ismeri, akit érdekel a téma.
Megmutatom, hogyan csináltuk a Lazadánál, és hogyan is kezdődött valójában.
Egy éve jöttem Lazadába, és elküldtek egy rönkökről szóló projekthez. Valami ilyesmi volt. Az alkalmazásnaplót az stdout és az stderr fájlokhoz írták. Minden divatos módon történt. De aztán a fejlesztők kidobták a szabványos áramlásokból, majd valahogy az infrastrukturális szakemberek kitalálják. Az infrastrukturális szakemberek és a fejlesztők között vannak olyan kiadók is, akik azt mondták: "na... nos, csomagoljuk be őket egy shell-el ellátott fájlba, és ennyi." És mivel mindez egy konténerben volt, pontosan becsomagolták magába a konténerbe, feltérképezték a benne lévő katalógust és odarakták. Szerintem mindenki számára nyilvánvaló, hogy mi lett belőle.
Nézzünk most egy kicsit tovább. Hogyan szállítottuk ki ezeket a naplókat? Valaki a td-agentet választotta, ami valójában fluentd, de nem egészen fluentd. Még mindig nem értem a két projekt kapcsolatát, de úgy tűnik, hogy ugyanarról szólnak. És ez a fluentd, Ruby nyelven írva, naplófájlokat olvasott, és valamilyen szabályossággal elemezte őket JSON-ba. Aztán elküldtem őket Kafkához. Ráadásul a Kafkában minden API-hoz 4 külön téma volt. Miért 4? Mert van élő, van staging, és mert van stdout és stderr. A fejlesztők gyártják őket, az infrastruktúra dolgozóinak pedig Kafkában kell létrehozniuk őket. Ráadásul Kafkát egy másik osztály irányította. Ezért kellett létrehozni egy jegyet, hogy ott minden api-hoz 4 témát hoztak létre. Mindenki megfeledkezett róla. Általában volt szemét és felhajtás.
Mit csináltunk ezután ezzel? Elküldtük Kafkának. Aztán Kafkától a rönkök fele Logstashba repült. A rönkök másik felét felosztották. Néhányan az egyik Graylogba repültek, mások egy másik Graylogba. Ennek eredményeként mindez egyetlen Elasticsearch klaszterbe került. Vagyis ez az egész zűrzavar ott kötött ki. Ne tedd ezt!
Így néz ki, ha felülről nézzük. Ne tedd ezt! Itt a problémás területek azonnal számokkal vannak jelölve. Valójában több is van belőlük, de 6 valóban problémás, amivel tenni kell valamit. Most külön mesélek róluk.
Itt (1,2,3) fájlokat írunk, és ennek megfelelően három rake van itt egyszerre.
Az első (1) az, hogy fel kell írnunk őket valahova. Nem mindig lenne kívánatos, hogy az API-t közvetlenül fájlba írjuk. Kívánatos, hogy az API egy tárolóban legyen elkülönítve, vagy még jobb, ha csak olvasható legyen. Rendszergazda vagyok, ezért kicsit másképp látom ezeket a dolgokat.
A második pont (2,3), hogy nagyon sok kérés érkezik az API-hoz. Az API sok adatot ír egy fájlba. A fájlok bővülnek. Forgatnunk kell őket. Mert különben nem tud majd ott semmilyen lemezt felhalmozni. Elforgatásuk rossz, mert a parancsértelmezőn keresztül a könyvtárba való átirányítással készülnek. Semmiképpen nem tudjuk felülvizsgálni. Nem mondhatja meg az alkalmazásnak, hogy nyissa meg újra a fogantyúkat. Mert a fejlesztők úgy néznek majd rád, mint egy bolondra: „Milyen leírók? Általában az stdout-nak írunk.” Az infrastruktúra-fejlesztők a copytruncate-t logrotate-ra tették, ami egyszerűen másolatot készít a fájlról, és átírja az eredetit. Ennek megfelelően ezen másolási folyamatok között általában elfogy a lemezterület.
(4) Különböző formátumaink voltak a különböző API-kban. Kicsit különböztek, de a reguláris kifejezést másképp kellett írni. Mivel mindezt a Puppet irányította, volt egy csomó osztály saját csótányokkal. Ráadásul a td-agent legtöbbször meg tudta enni a memóriát, buta lehet, csak úgy tett, mintha működik, és nem csinálna semmit. Kívülről nem lehetett megérteni, hogy nem csinál semmit. Legjobb esetben elesik, és később valaki felveszi. Pontosabban riasztás érkezik, és valaki elmegy és felemeli a kezével.
(6) A legtöbb szemét és hulladék pedig az elaszticsearch volt. Mert ez egy régi verzió volt. Mert akkor még nem voltak elhivatott mestereink. Heterogén rönkök voltak, amelyek mezői átfedhetik egymást. Különböző alkalmazásokból származó naplók írhatók ugyanazzal a mezőnévvel, de különböző adatok lehetnek benne. Vagyis egy napló egész számmal érkezik a mezőben, például szinten. Egy másik naplóban a String szerepel a szintmezőben. Statikus leképezés hiányában ez olyan csodálatos dolog. Ha az index elforgatása után az elaszticsearchben először egy stringet tartalmazó üzenet érkezik, akkor normálisan élünk. De ha az első Integerből érkezett, akkor a Stringből érkező összes további üzenetet egyszerűen eldobjuk. Mivel a mező típusa nem egyezik.
Ezeket a kérdéseket kezdtük el feltenni. Úgy döntöttünk, hogy nem keressük a hibáztatókat.
De valamit tenni kell! Nyilvánvaló, hogy szabványokat kell kialakítanunk. Volt már néhány szabványunk. Néhányat kicsit később hoztunk. Szerencsére ekkor már jóváhagyták az összes API-hoz egyetlen naplóformátumot. Közvetlenül a szolgáltatási interakciós szabványokba van beírva. Ennek megfelelően azoknak, akik naplókat szeretnének kapni, ebben a formátumban kell írniuk. Ha valaki nem ebben a formátumban ír naplót, akkor semmi garanciát nem vállalunk.
Ezt követően egységes szabványt szeretnék alkotni a naplók rögzítésének, kiszállításának és gyűjtésének módszereire vonatkozóan. Valójában hova kell írni, és hogyan kell kézbesíteni. Az ideális helyzet az, ha a projektek ugyanazt a könyvtárat használják. Külön naplózási könyvtár van a Go-hoz, és külön könyvtár a PHP-hez. Mindenkinek használnia kell őket. Jelen pillanatban azt mondanám, hogy 80 százalékos sikerrel járunk. De néhányan továbbra is kaktuszt esznek.
És ott (a dián) alig kezd megjelenni az „SLA a rönkszállításhoz”. Még nem létezik, de dolgozunk rajta. Mert nagyon kényelmes, amikor az infrastruktúra azt mondja, hogy ha ilyen-olyan formátumban írsz ilyen-olyan helyre és legfeljebb N üzenetet másodpercenként, akkor nagy valószínűséggel eljuttatjuk ilyen-olyan helyre. Ez sok fejfájást enyhít. Ha van SLA, akkor ez teljesen csodálatos!
Hogyan kezdtük el megoldani a problémát? A fő probléma a td-agenttel volt. Nem volt világos, hová tűntek a naplóink. Kiszállítják? Mennek? Egyébként hol vannak? Ezért az első pont a td-agent cseréje mellett döntött. Itt röviden felvázoltam a lehetőségeket, hogy mivel lehet helyettesíteni.
Fluentd. Először egy korábbi munkahelyemen találkoztam vele, és ott is időnként elesett. Másodszor, ez ugyanaz, csak profilban.
Filebeat. Mennyire volt jó nekünk? Mert a Go-ban van, és nagy szakértelemmel rendelkezünk a Go terén. Ennek megfelelően, ha bármi történne, valahogy hozzátehetnénk magunknak. Ezért nem vettük. Hogy ne legyen kísértés, hogy elkezdje átírni magának.
A rendszergazda számára kézenfekvő megoldás a mindenféle syslog ilyen mennyiségben (syslog-ng/rsyslog/nxlog).
Vagy írjon valami sajátot, de ezt elvetettük, ahogy a filebeat-et is. Ha írsz valamit, jobb, ha írsz valami hasznosat az üzleti életben. A rönkök szállításához jobb, ha valami készet vesz.
Ezért a választás valójában a syslog-ng és az rsyslog közötti választás volt. Egyszerűen azért hajlottam az rsyslog felé, mert már voltak rsyslog osztályaink a Puppetben, és nem találtam nyilvánvaló különbséget köztük. Mi a syslog, mi a syslog. Igen, van akinek rosszabb a dokumentációja, van akinek jobb. Ő tudja ezt az utat, és másként csinálja.
És egy kicsit az rsyslogról. Először is menő, mert sok modul van benne. Ember által olvasható RainerScripttel (egy modern konfigurációs nyelv) rendelkezik. Félelmetes bónusz, hogy szabványos eszközökkel emulálhatjuk a td-agent viselkedését, és semmi sem változott az alkalmazásoknál. Vagyis a td-agentet rsyslog-ra cseréljük, minden mást pedig egyelőre békén hagyunk. És azonnal megkapjuk a működő szállítást. Ezután az mmnormalize egy fantasztikus dolog az rsyslogban. Lehetővé teszi a naplók elemzését, de nem a Grok és a regexp segítségével. Absztrakt szintaxisfát készít. A naplókat nagyjából ugyanúgy elemzi, mint a fordító a forrásokat. Ez lehetővé teszi, hogy nagyon gyorsan dolgozzon, kevés CPU-t fogyaszt, és általában nagyon klassz dolog. Van egy csomó más bónusz. Nem foglalkozom velük.
Az rsyslognak sok más hátránya is van. Ezek nagyjából megegyeznek a bónuszokkal. A fő problémák az, hogy tudni kell főzni, és ki kell választani a verziót.
Úgy döntöttünk, hogy a naplókat egy unix foglalatba írjuk. És nem a /dev/logban, mert ott rendetlenség van a rendszernaplókban, a naplód ebben a folyamatban van. Tehát írjunk egy egyedi aljzatba. Külön szabályzathoz csatoljuk. Ne avatkozzunk bele semmibe. Minden átlátható és érthető lesz. Pontosan ezt tettük. Az ezekkel a socketekkel rendelkező könyvtár szabványosított, és minden konténerhez továbbítva van. A konténerek láthatják a szükséges aljzatot, kinyithatják és írhatnak rá.
Miért nem fájl? Mert mindenki olvasta , amely megpróbált egy fájlt továbbítani a dockernek, és kiderült, hogy az rsyslog újraindítása után a fájlleíró megváltozott, és a docker elvesztette ezt a fájlt. Valami mást nyitva tart, de nem azt a foglalatot, ahová írnak. Úgy döntöttünk, hogy megkerüljük ezt a problémát, ugyanakkor megkerüljük a blokkolási problémát.
Az Rsyslog végrehajtja a dián jelzett műveleteket, és naplókat küld a közvetítőnek vagy a Kafkának. Kafka a régi utat követi. Relay – Megpróbáltam tiszta rsyslogot használni a naplók kézbesítésére. Üzenetsor nélkül, szabványos rsyslog eszközökkel. Alapvetően működik.
De vannak árnyalatok, hogyan lehet őket ebbe a részbe tolni (Logstash/Graylog/ES). Ez a rész (rsyslog-rsyslog) adatközpontok között használatos. Itt van egy tömörített tcp link, amivel sávszélességet takaríthatunk meg, és ennek megfelelően valahogy növeljük annak valószínűségét, hogy egy másik adatközpontból kapunk naplókat, ha a csatorna eltömődött. Mert van Indonéziánk, ahol minden rossz. Itt van az állandó probléma.
Elgondolkodtunk azon, hogyan tudjuk ténylegesen nyomon követni, mennyire valószínű, hogy az alkalmazásból rögzített naplók elérik a végét? Úgy döntöttünk, hogy mérőszámokat hozunk létre. Az rsyslog saját statisztikagyűjtő modullal rendelkezik, amely valamilyen számlálót tartalmaz. Megmutathatja például a sor méretét, vagy azt, hogy hány üzenet érkezett ilyen és ehhez hasonló műveletben. Már el lehet venni tőlük valamit. Ráadásul egyedi számlálók is vannak, amelyek konfigurálhatók, és megmutatja például, hogy egyes API-k hány üzenetet rögzítettek. Ezután megírtam az rsyslog_exporter-t Pythonban, és elküldtük a Prometheusnak, és grafikonokat építettünk. Nagyon szerettük volna a Graylog mérőszámokat, de még nem volt időnk beállítani őket.
Mik voltak a problémák? Problémák merültek fel, amikor felfedeztük (HIRTELEN!), hogy élő API-jaink másodpercenként 50 ezer üzenetet írnak. Ez csak egy élő API, állomásozás nélkül. A Graylog pedig mindössze 12 ezer üzenetet mutat meg másodpercenként. És felmerült egy ésszerű kérdés: hol vannak a maradványok? Ebből arra a következtetésre jutottunk, hogy a Graylog egyszerűen nem tud megbirkózni. Megnéztük, és valóban, Graylog és Elasticsearch nem tudta kezelni ezt az áramlást.
Ezután további felfedezéseket tettünk az út során.
Az aljzatba történő írás blokkolva van. Hogy történt? Amikor az rsyslogot használtam a kézbesítéshez, egy ponton megszakadt az adatközpontok közötti csatorna. A szállítás egy helyen leállt, a szállítás egy másik helyen. Mindez az rsyslog socketbe író API-kkal jutott el a géphez. Ott sorban állt. Ekkor megtelt a unix socketbe való írási sor, amely alapértelmezés szerint 128 csomag. És a következő write() az alkalmazásban le van tiltva. Amikor megnéztük a könyvtárat, amit a Go alkalmazásokban használunk, ott azt írták, hogy a socketbe írás nem blokkoló módban történik. Biztosak voltunk benne, hogy semmi sincs blokkolva. Mert olvasunk aki írt róla. De van egy pillanat. E hívás körül is volt egy végtelen hurok, amelyben folyamatosan próbáltak üzenetet betolni a foglalatba. Nem vettük őt észre. Át kellett írnom a könyvtárat. Azóta többször változott, de mostanra minden alrendszerben megszabadultunk a blokkolástól. Ezért leállíthatja az rsyslogot, és semmi sem fog összeomlani.
Figyelni kell a sorok méretét, ami segít elkerülni, hogy rálépjünk erre a gereblyére. Először is figyelemmel kísérhetjük, mikor kezdünk elveszni az üzenetek. Másodszor, figyelemmel kísérhetjük, hogy problémáink vannak a szállítással.
És még egy kellemetlen pillanat - a 10-szeres erősítés egy mikroszolgáltatási architektúrában nagyon egyszerű. Nem sok bejövő kérésünk van, de a grafikon miatt, amelyen ezek az üzenetek továbbhaladnak, a hozzáférési naplók miatt valójában körülbelül tízszeresére növeljük a naplóterhelést. Sajnos nem volt időm kiszámolni a pontos számokat, de a mikroszolgáltatások olyanok, amilyenek. Ezt szem előtt kell tartani. Kiderült, hogy jelenleg a naplógyűjtő alrendszer a legterheltebb Lazadában.
Hogyan lehet megoldani az elaszticsearch problémát? Ha gyorsan egy helyre kell gyűjtenie a naplókat, hogy ne rohanjon az összes géphez és ne gyűjtse ott azokat, használja a fájltárolót. Ez garantáltan működik. Bármilyen szerverről elvégezhető. Csak rögzítenie kell a lemezeket, és telepítenie kell a syslog-ot. Ezek után garantáltan minden rönk egy helyen lesz. Aztán lassan beállíthatod az elasticsearch-et, a graylog-ot és még valami mást. De máris meglesz az összes napló, és ráadásul tárolhatod is, amennyire van elegendő lemeztömb.
Jelentésem idején a rendszer így kezdett kinézni. Gyakorlatilag abbahagytuk a fájlba írást. Most valószínűleg kikapcsoljuk a többit. Az API-t futtató helyi gépeken leállítjuk a fájlok írását. Először is van fájltároló, ami nagyon jól működik. Másodszor, ezekben a gépekben folyamatosan fogy a hely, folyamatosan figyelni kell.
Ez a Logstash-val és Graylog-al ellátott rész nagyon beindul. Ezért meg kell szabadulnunk tőle. Egy dolgot kell választanod.
Úgy döntöttünk, hogy elhagyjuk a Logstash-t és a Kibanát. Mert van egy biztonsági osztályunk. Milyen kapcsolat? Az összefüggés az, hogy a Kibana X-Pack és Shield nélkül nem teszi lehetővé a naplókhoz való hozzáférési jogok megkülönböztetését. Ezért vettük a Graylogot. Minden benne van. Nem szeretem, de működik. Új hardvert vásároltunk, friss Graylogot telepítettünk oda, és minden szigorú formátumú naplót átvittünk egy külön Graylogba. Szervezetileg ugyanazon területek különböző típusaival oldottuk meg a problémát.
Pontosan mit tartalmaz az új Graylog. Mindent beírtunk a dockerbe. Fogtunk egy csomó szervert, kivezettünk három Kafka-példányt, 7 Graylog-szerver 2.3-as verzióját (mert az Elasticsearch 5-ös verzióját akartuk). Mindezt razziák során vették fel a HDD-ről. Akár 100 ezer üzenet indexelési arányát is láthattuk másodpercenként. Azt a számot láttuk, hogy 140 terabájt adat hetente.
És megint egy gereblye! Két eladásunk van. Túlléptünk a 6 millió üzeneten. Graylognak nincs ideje rágni. Valahogy újra túl kell élnünk.
Így éltük túl. Hozzáadtunk még néhány szervert és SSD-t. Jelenleg így élünk. Most már 160 XNUMX üzenetet rágunk át másodpercenként. Még nem értük el a határt, így nem világos, hogy valójában mennyit tudunk kihozni ebből.
Ezek a terveink a jövőre nézve. Ezek közül a legfontosabb valószínűleg a magas rendelkezésre állás. Még nincs meg. Több autó ugyanígy van beállítva, de eddig minden egy autón keresztül megy. Időbe telik a feladatátvétel beállítása közöttük.
Gyűjtse össze a mérőszámokat a Graylogból.
Határozzon meg sebességkorlátozást, hogy egyetlen őrült API-val rendelkezzünk, amely nem öli meg a sávszélességünket és minden mást.
És végül kössünk valami SLA-t a fejlesztőkkel, hogy ennyit kiszolgálhassunk. Ha többet írsz, akkor bocsi.
És írj dokumentációt.
Röviden mindannak az eredménye, amit tapasztaltunk. Először is a szabványok. Másodszor, a syslog egy torta. Harmadszor, az rsyslog pontosan úgy működik, ahogy a diára van írva. És térjünk át a kérdésekre.
kérdések.
Kérdés: Miért döntöttél úgy, hogy nem veszed... (filebeat?)
Válasz: Fájlba kell írnunk. nagyon nem akartam. Amikor az API több ezer üzenetet ír másodpercenként, még akkor sem, ha óránként egyszer forgatja, ez továbbra sem választható. Írhatsz csövön. Mire a fejlesztők megkérdezték tőlem: „Mi történik, ha a folyamat, amelyre írunk, összeomlik?” Csak nem találtam, mit válaszoljak nekik, és azt mondtam: "Nos, oké, ne csináljuk."
Kérdés: Miért nem írsz naplókat a HDFS-be?
VálaszV: Ez a következő szakasz. Már az elején gondolkoztunk rajta, de mivel jelenleg erre nincs forrás, ez belelóg a hosszú távú megoldásunkba.
Kérdés: Az oszlopformátum megfelelőbb lenne.
Válasz: Megértem. Két kézzel vagyunk érte.
Kérdés: Ön az rsyslogba ír. Itt használhatja a TCP-t és az UDP-t is. De ha UDP, akkor hogyan garantálja a szállítást?
Válasz: Két pont van. Először is azonnal elmondom mindenkinek, hogy nem vállalunk garanciát a rönkök szállítására. Mert amikor jönnek a fejlesztők, és azt mondják: „Kezdjük el oda írni a pénzügyi adatokat, és te elhelyezed valahova nekünk, hátha történne valami”, akkor azt válaszoljuk nekik: „Remek! Kezdjük el blokkolni a socketre írást, és tegyük ezt a tranzakciók során, így garantáltan felteszi helyettünk a socketre, és megbizonyosodjon arról, hogy a másik oldalról kapjuk meg.” És ebben a pillanatban mindenkinek azonnal nincs szüksége rá. Ha nem szükséges, akkor milyen kérdéseket tegyünk fel? Ha nem akar garanciát vállalni az aljzatba való írásért, akkor miért kell garanciát vállalnunk a kézbesítésre? Minden tőlünk telhetőt megteszünk. Tényleg igyekszünk a lehető legtöbbet és a lehető legjobb módon szállítani, de 100%-os garanciát nem vállalunk. Ezért nem kell oda pénzügyi adatokat írni. Léteznek erre vonatkozó tranzakciókat tartalmazó adatbázisok.
Kérdés: Amikor az API generál valamilyen üzenetet a naplóban, és átadja az irányítást a mikroszolgáltatásoknak, akkor találkozott azzal a problémával, hogy a különböző mikroszolgáltatásokból származó üzenetek rossz sorrendben érkeznek? Emiatt zűrzavar keletkezik.
Válasz: Normális, hogy különböző sorrendben érkeznek. Erre fel kell készülni. Mert minden hálózati szállítás nem garantálja a rendelést, vagy erre külön erőforrásokat kell fordítani. Ha fájltárolókat veszünk, akkor minden API a saját fájljába menti a naplókat. Illetve az rsyslog könyvtárakba rendezi őket. Minden API-nak megvannak a saját naplói, ahová megnézheti, majd összehasonlíthatja őket a naplóban található időbélyeg segítségével. Ha a Graylogban néznek, akkor ott időbélyeg szerint vannak rendezve. Ott minden rendben lesz.
Kérdés: Az időbélyeg ezredmásodpercenként változhat.
Válasz: Az időbélyeget maga az API hozza létre. Valójában ez az egész lényeg. NTP-nk van. Az API magában az üzenetben generál egy időbélyeget. az rsyslog nem adja hozzá.
Kérdés: Az adatközpontok közötti interakció nem túl egyértelmű. Az adatközponton belül jól látható, hogyan gyűjtötték és dolgozták fel a naplókat. Hogyan zajlik az adatközpontok közötti interakció? Vagy minden adatközpont a saját életét éli?
Válasz: Majdnem. Hazánkban minden ország egy adatközpontban található. Jelenleg nincs olyan eloszlásunk, hogy egy ország különböző adatközpontokban található. Ezért nem szükséges kombinálni őket. Mindegyik központban van egy naplórelé. Ez egy Rsyslog szerver. Valójában két kezelőgép. Ugyanaz a hozzáállásuk. De egyelőre csak az egyiken halad át a forgalom. Az összes naplót összesíti. Minden esetre van lemezsora. Letölti a naplókat, és elküldi a központi adatközpontba (Szingapúr), ahol aztán elküldik a Graylogba. És minden adatközpontnak saját fájltárolója van. Ha megszakad a kapcsolatunk, ott van az összes napló. Ott maradnak. Ott fogják tárolni.
Kérdés: Rendellenes helyzetek esetén kapsz onnan naplókat?
Válasz: Oda lehet menni (a fájltárolóba) és megnézni.
Kérdés: Hogyan figyeli, hogy ne veszítse el a naplókat?
Válasz: Valójában elveszítjük őket, és ezt figyelemmel kísérjük. A megfigyelést egy hónapja indították el. A Go API-k által használt könyvtár metrikákkal rendelkezik. Meg tudja számolni, hányszor nem tudott egy aljzatba írni. Jelenleg ott van egy okos heurisztika. Van ott egy puffer. Megpróbál üzenetet írni róla a foglalatba. Ha a puffer túlcsordul, elkezdi eldobni őket. És megszámolja, hányat ejtett el belőlük. Ha ott kezdenek túlcsordulni a mérőórák, akkor tudni fogunk róla. Most a Prometheushoz is érkeznek, a grafikonokat pedig a Grafana-ban láthatod. Beállíthat riasztásokat. De még nem világos, hogy kinek küldje el őket.
Kérdés: Az elaszticsearch-ben redundanciával tárolja a naplókat. Hány replikád van?
Válasz: Egy replika.
Kérdés: Ez csak egy sor?
Válasz: Ez a mester és a replika. Az adatokat két példányban tároljuk.
Kérdés: Beállítottad valahogy az rsyslog puffer méretét?
Válasz: Datagramokat írunk egy egyedi unix foglalatba. Ez azonnal 128 kilobyte-os korlátot szab ránk. Nem írhatunk rá többet. Ezt beírtuk a szabványba. A tárhelyre vágyók 128 kilobájtot írnak. A könyvtárakat ráadásul levágják, és zászlót helyeznek el, hogy az üzenetet levágták. Magára az üzenetre vonatkozó szabványunknak van egy speciális mezője, amely megmutatja, hogy az üzenetet levágták-e a rögzítés során vagy sem. Lehetőségünk van tehát ennek a pillanatnak a nyomon követésére is.
Kérdés: Törött JSON-t írsz?
Válasz: A törött JSON eldobásra kerül a továbbítás során, mert a csomag túl nagy. Vagy a Graylog el lesz vetve, mert nem tudja elemezni a JSON-t. De vannak olyan árnyalatok, amelyeket javítani kell, és ezek többnyire az rsysloghoz kötődnek. Ott már kitöltöttem több kérdést, amelyeken még dolgozni kell.
Kérdés: Miért Kafka? Próbáltad a RabbitMQ-t? A Graylog meghibásodik ilyen terhelés alatt?
Válasz: Grayloggal nem megy. A Graylog pedig formát ölt számunkra. Tényleg problémás. Ő egy különös dolog. És valójában nincs is rá szükség. Legszívesebben az rsyslogból közvetlenül az elasticsearch-be írnék, aztán megnézném a Kibanát. De rendeznünk kell a kérdést a biztonsági őrökkel. Ez egy lehetséges lehetőség a fejlesztésünkre, amikor kidobjuk a Graylogot és a Kibanát használjuk. A Logstash használatának semmi értelme. Mert ugyanezt meg tudom csinálni az rsysloggal is. És van egy modulja az elaszticsearch íráshoz. Megpróbálunk valahogy együtt élni Grayloggal. Még fel is tuningoltunk egy kicsit. De van még hova fejlődni.
Kafkáról. Történelmileg így történt. Amikor megérkeztem, már ott volt, és már naplókat írtak rá. Csak megemeltük a fürtünket, és rönköket helyeztünk bele. Mi irányítjuk őt, tudjuk, mit érez. Ami a RabbitMQ-t illeti... problémáink vannak a RabbitMQ-val. A RabbitMQ pedig formát ölt számunkra. Gyártásban van, és voltak vele problémák. Most, az eladás előtt, sámánizálják, és elkezdett normálisan dolgozni. De előtte nem álltam készen arra, hogy kiadjam a gyártásba. Van még egy pont. A Graylog képes olvasni az AMQP 0.9, az rsyslog pedig az AMQP 1.0 verzióját. Középen pedig nincs egyetlen olyan megoldás sem, amelyik mindkettőre képes. Vagy az egyik, vagy a másik. Ezért jelenleg csak Kafka. De ennek is megvannak a maga árnyalatai. Mert az általunk használt rsyslog verzió omkafka elveszítheti a teljes üzenetpuffert, amelyet az rsyslogból rakott ki. Egyelőre tűrjük.
Kérdés: Azért használod a Kafkát, mert már megvolt? Már nem használják semmilyen célra?
Válasz: A Data Science csapata használja a Kafkát, ami volt. Ez egy teljesen külön projekt, amiről sajnos nem tudok mit mondani. Nem tudom. A Data Science csapata működtette. Amikor a naplókat létrehoztuk, úgy döntöttünk, hogy ezt használjuk, nehogy a sajátunkat telepítsük. Most frissítettük a Graylogot, és elvesztettük a kompatibilitást, mert a Kafka régi verziója van benne. El kellett kezdenünk a sajátunkat. Ugyanakkor minden API-nál megszabadultunk ettől a négy témától. Létrehoztunk egy széles témát mindenkinek élőben, egy széles témát az összes színpadra állításhoz, és mindent odatettünk. Graylog mindezt párhuzamosan kaparja ki.
Kérdés: Miért kell ez a konnektoros sámánizmus? Próbáltad már használni a syslog log drivert tárolókhoz?
Válasz: Amikor feltettük ezt a kérdést, feszült volt a kapcsolatunk a dokkolóval. Docker 1.0 vagy 0.9 volt. Maga Docker furcsa volt. Másodszor, ha naplókat is tolsz bele... Van egy ellenőrizetlen gyanúm, hogy az összes naplót átengedi magán, a docker démonon keresztül. Ha az egyik API megőrül, akkor a többi API megragad abban a tényben, hogy nem tudják elküldeni az stdout-ot és az stderr-t. Nem tudom, hova fog ez vezetni. Olyan érzésem van, hogy ezen a helyen nincs szükség a Docker syslog illesztőprogram használatára. Funkcionális tesztelési részlegünk saját Graylog-fürttel rendelkezik naplókkal. Docker napló-illesztőprogramokat használnak, és úgy tűnik, hogy minden rendben van. De azonnal GELF-et írnak a Graylognak. Abban az időben, amikor mindezt elkezdtük, csak arra volt szükségünk, hogy működjön. Talán később, ha jön valaki és azt mondja, hogy száz éve jól működik, megpróbáljuk.
Kérdés: Az adatközpontok közötti kézbesítést rsyslog használatával végzi. Miért nem Kafka?
Válasz: Valójában mindkettőt csináljuk. Két okból. Ha a csatorna teljesen halott, akkor az összes naplónk még tömörített formában sem fog átmászni rajta. A Kafka pedig lehetővé teszi, hogy közben egyszerűen elveszítse őket. Így megszabadulunk attól, hogy ezek a rönkök elakadjanak. Ebben az esetben csak közvetlenül Kafkát használjuk. Ha van egy jó csatornánk és szeretnénk felszabadítani, akkor az ő rsyslogjukat használjuk. De valójában beállíthatja úgy, hogy maga ejtse ki azt, ami nem fért át. Jelenleg valahol csak közvetlenül rsyslog-kézbesítést használunk, valahol pedig Kafkát.
Forrás: will.com