a Badushka cikket,<\/a><\/noindex>, amely err\u0151l \u00edrt. De van egy dolog. Ez a h\u00edv\u00e1s k\u00f6r\u00fcl egy v\u00e9gtelen ciklus is volt, amely folyamatosan megpr\u00f3b\u00e1lta a \u00fczenetet besz\u00farni a socketbe. Ezt mi nem \u00e9szlelt\u00fck. \u00dajra kellett \u00edrni a k\u00f6nyvt\u00e1rat. Az\u00f3ta t\u00f6bbsz\u00f6r is v\u00e1ltozott, de most m\u00e1r megszabadultunk a blokkokt\u00f3l minden alrendszerben. Ez\u00e9rt le lehet \u00e1ll\u00edtani az rsyslogot, \u00e9s semmi nem fog le\u00e1llni.<\/p>\n<\/p>\n
Figyelni kell a sorok m\u00e9ret\u00e9t, ami seg\u00edt elker\u00fclni ezeket a buktat\u00f3kat. El\u0151sz\u00f6r is, monitorozhatjuk, amikor elkezd\u00fcnk \u00fczeneteket elvesz\u00edteni. M\u00e1sodszor, figyelhetj\u00fck, hogy alapvet\u0151en probl\u00e9m\u00e1ink vannak a k\u00e9zbes\u00edt\u00e9ssel.<\/p>\n
<\/p>\n
\u00c9s egy m\u00e9g kellemetlenebb dolog \u2014 a mikroszolg\u00e1ltat\u00e1sos architekt\u00far\u00e1ban a 10-szeres amplifik\u00e1ci\u00f3 nagyon k\u00f6nnyen megval\u00f3s\u00edthat\u00f3. N\u00e1lunk nem sok bej\u00f6v\u0151 k\u00e9r\u00e9s \u00e9rkezik, de a graf alapj\u00e1n, amin ezek az \u00fczenetek futnak, az access napl\u00f3k miatt val\u00f3ban k\u00f6r\u00fclbel\u00fcl t\u00edzszeres\u00e9re n\u00f6velj\u00fck a napl\u00f3k terhel\u00e9s\u00e9t. Sajnos nem volt id\u0151m pontos sz\u00e1mokat sz\u00e1m\u00edtani, de a mikroszolg\u00e1ltat\u00e1sok ilyenek. Ezt figyelembe kell venni. Jelenleg a naplogy\u0171jt\u0151 alrendszer a legterheltebb a Lazad\u00e1n\u00e1l. <\/p>\n
<\/p>\n
<\/p>\n
Hogyan lehet megoldani az elasticsearch probl\u00e9m\u00e1t? Ha gyorsan szeretn\u00e9 megkapni a napl\u00f3kat egy helyen, hogy ne kelljen k\u00f3dol\u00e1s k\u00f6zben az \u00f6sszes g\u00e9pen keresni, haszn\u00e1ljon f\u00e1jlt\u00e1rol\u00f3t. Ez garant\u00e1ltan m\u0171k\u00f6dik. B\u00e1rmely szerverb\u0151l elk\u00e9sz\u00edthet\u0151. Csak le kell valahogy ter\u00edteni a lemezeket \u00e9s be\u00e1ll\u00edtani a syslogot. Ut\u00e1na garant\u00e1ltan minden napl\u00f3 egy helyen lesz. Azt\u00e1n nyugodtan be\u00e1ll\u00edthatja az elasticsearch-t, graylog-ot, valami m\u00e1st. De m\u00e1r meg lesznek az \u00f6sszes napl\u00f3ja, \u00e9s t\u00e1rolhatja \u0151ket annyira, ameddig a lemezmeghajt\u00f3k engedik.<\/p>\n
<\/p>\n
<\/p>\n
El\u0151ad\u00e1som id\u0151pontj\u00e1ban a s\u00e9ma \u00edgy n\u00e9zett ki. Szinte teljesen abbahagytuk a f\u00e1jlok \u00edr\u00e1s\u00e1t. Jelenleg val\u00f3sz\u00edn\u0171leg lekapcsoljuk a marad\u00e9kokat. A lok\u00e1lis g\u00e9peken, ahol az API fut, nem lesz\u00fcnk k\u00e9pesek f\u00e1jlokat \u00edrni. Egyr\u00e9szt van egy f\u00e1jlt\u00e1rol\u00f3, ami nagyon j\u00f3l m\u0171k\u00f6dik. M\u00e1sr\u00e9szt, ezeken a g\u00e9peken folyamatosan elfogy a hely, azt folyamatosan figyelni kell.<\/p>\n
<\/p>\n
Ez a r\u00e9sz a Logstash-sal \u00e9s Graylog-gal egy kicsit zavar\u00f3. Teh\u00e1t meg kell szabadulnunk t\u0151le. V\u00e1lasszunk ki valami egyet.<\/p>\n
<\/p>\n
<\/p>\n
\u00dagy d\u00f6nt\u00f6tt\u00fcnk, hogy elhagyjuk a Logstash-t \u00e9s a Kibana-t. Mert van biztons\u00e1gi oszt\u00e1lyunk. Mi a kapcsolat? A kapcsolat az, hogy a Kibana X-Pack \u00e9s Shield n\u00e9lk\u00fcl nem teszi lehet\u0151v\u00e9 a napl\u00f3khoz val\u00f3 hozz\u00e1f\u00e9r\u00e9si jogok elk\u00fcl\u00f6n\u00edt\u00e9s\u00e9t. Ez\u00e9rt v\u00e1lasztottuk a Graylog-ot. Minden benne van. Nekem nem tetszik, de m\u0171k\u00f6dik. \u00daj hardvert v\u00e1s\u00e1roltunk, friss Graylog-ot \u00e1ll\u00edtottunk be r\u00e1, \u00e9s az \u00f6sszes szigor\u00fa form\u00e1tum\u00fa napl\u00f3t k\u00fcl\u00f6n Graylog-ba helyezt\u00fck \u00e1t. Megoldottuk a probl\u00e9m\u00e1t az azonos mez\u0151k k\u00fcl\u00f6nb\u00f6z\u0151 t\u00edpusaival szervezetileg.<\/p>\n
<\/p>\n
<\/p>\n
Mit is tartalmaz a new Graylog? Egyszer\u0171en csak mindent meg\u00edrtunk Dockerbe. Sok szervert vett\u00fcnk, h\u00e1rom Kafka p\u00e9ld\u00e1nyt telep\u00edtett\u00fcnk, 7 Graylog szervert 2.3-as verzi\u00f3val (mivel az Elasticsearch 5-\u00f6t akartunk). Az eg\u00e9szet HDD RAID-re telep\u00edtett\u00fck. 100 ezer \u00fczenet\/m\u00e1sodperces indexing rate-et l\u00e1ttunk. L\u00e1ttunk egy sz\u00e1mot, ami 140 terabyte adatot jelentett hetente. <\/p>\n
<\/p>\n
<\/p>\n
\u00c9s megint a buktat\u00f3k! K\u00e9t le\u00e9rt\u00e9kel\u00e9s k\u00f6zel\u00edt. \u00c1tk\u00f6lt\u00f6zt\u00fcnk 6 milli\u00f3 \u00fczenethez. A Graylog-unk nem b\u00edrt vele. Valahogy megint t\u00fal kell \u00e9ln\u00fcnk. <\/p>\n
<\/p>\n
<\/p>\n
\u00cdgy t\u00fal\u00e9lt\u00fcnk. M\u00e9g n\u00e9h\u00e1ny szervert \u00e9s SSD-t adtunk hozz\u00e1. Jelenleg \u00edgy \u00e9l\u00fcnk. Most m\u00e1r 160 ezer \u00fczenetet dolgozunk fel m\u00e1sodpercenk\u00e9nt. M\u00e9g nem \u00fctk\u00f6zt\u00fcnk a hat\u00e1rba, ez\u00e9rt egyel\u0151re nem vil\u00e1gos, hogy val\u00f3j\u00e1ban mennyit tudunk kih\u00fazni ebb\u0151l. <\/p>\n
<\/p>\n
<\/p>\n
Ilyenek a j\u00f6v\u0151beli terveink. Ezek k\u00f6z\u00fcl tal\u00e1n a legfontosabb a magas rendelkez\u00e9sre \u00e1ll\u00e1s. Jelenleg nincs. N\u00e9h\u00e1ny g\u00e9pet azonosan \u00e1ll\u00edtottunk be, de az \u00f6sszes adat egy g\u00e9pen kereszt\u00fcl megy. Id\u0151t kellene sz\u00e1nni arra, hogy be\u00e1ll\u00edtsuk a failover-t k\u00f6z\u00f6tt\u00fck.<\/p>\n
<\/p>\n
Metrik\u00e1k gy\u0171jt\u00e9se a Graylogb\u00f3l.<\/p>\n
<\/p>\n
Rate limit be\u00e1ll\u00edt\u00e1sa, hogy egy, meg\u0151r\u00fclt API ne \u00f6lj\u00f6n meg minket s\u00e1vsz\u00e9less\u00e9gben \u00e9s minden egy\u00e9bben.<\/p>\n
<\/p>\n
\u00c9s v\u00e9g\u00fcl, al\u00e1\u00edrni valamilyen SLA-t a fejleszt\u0151kkel, hogy mennyit tudunk kezelni. Ha t\u00f6bbet \u00edrtok, akkor sajn\u00e1lom.<\/p>\n
<\/p>\n
\u00c9s dokument\u00e1ci\u00f3t \u00edrni.<\/p>\n
<\/p>\n
<\/p>\n
R\u00f6viden \u00f6sszefoglalva mindent, amit \u00e1t\u00e9lt\u00fcnk. El\u0151sz\u00f6r is, szabv\u00e1nyok. M\u00e1sodszor, a syslog \u2014 egy torta. Harmadszor, az rsyslog pontosan \u00fagy m\u0171k\u00f6dik, ahogy a di\u00e1n van \u00edrva. \u00c9s most t\u00e9rj\u00fcnk \u00e1t a k\u00e9rd\u00e9sekre.<\/p>\n
<\/p>\n
K\u00e9rd\u00e9sek<\/strong>.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Mi\u00e9rt d\u00f6nt\u00f6tt\u00fcnk \u00fagy, hogy m\u00e9gsem haszn\u00e1ljuk... (filebeat?)<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: F\u00e1jlt kell \u00edrni. Nagyon nem akartam. Amikor az API-d m\u00e1sodpercenk\u00e9nt ezer \u00fczenetet \u00edr, m\u00e9g ha \u00f3r\u00e1nk\u00e9nt forgatsz is, az m\u00e9g mindig nem megold\u00e1s. \u00cdrhatunk pipe-ba is. Amire a fejleszt\u0151k megk\u00e9rdezt\u00e9k t\u0151lem: \u201eMi t\u00f6rt\u00e9nik, ha a folyamat, ahov\u00e1 \u00edrunk, \u00f6sszeomlik?\u201d Egyszer\u0171en nem tudtam mit v\u00e1laszolni, \u00e9s azt mondtam: \u201eH\u00e1t rendben, akkor ne csin\u00e1ljuk \u00edgy.\u201d<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Mi\u00e9rt nem \u00edrj\u00e1tok a napl\u00f3kat egyszer\u0171en HDFS-be?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Ez a k\u00f6vetkez\u0151 l\u00e9p\u00e9s. Gondoltunk r\u00e1 a legels\u0151 pillanatt\u00f3l kezdve, de mivel jelenleg nincsenek er\u0151forr\u00e1saink ezzel foglalkozni, emiatt hossz\u00fa t\u00e1v\u00fa megold\u00e1sk\u00e9nt l\u00f3g a leveg\u0151ben.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Az oszlopform\u00e1tum jobban megfelelne.<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Minden \u00e9rtek. Mi mindk\u00e9t kez\u00fcnkkel \u201emellett\u201d \u00e1llunk. <\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: A rsyslog-ba \u00edrtok. Ott haszn\u00e1lhat\u00f3 TCP \u00e9s UDP is. De ha UDP-t haszn\u00e1ltok, hogyan garant\u00e1lj\u00e1tok a k\u00e9zbes\u00edt\u00e9st?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: K\u00e9t dolog van. El\u0151sz\u00f6r is, azonnal mindenkinek mondom, hogy nem garant\u00e1ljuk a napl\u00f3k k\u00e9zbes\u00edt\u00e9s\u00e9t. Mert amikor a fejleszt\u0151k j\u00f6nnek \u00e9s azt mondj\u00e1k: \u201eHogyha elkezd\u00fcnk p\u00e9nz\u00fcgyi adatokat \u00edrni, akkor ti ezeket valahogy t\u00e1rolj\u00e1tok, ha t\u00f6rt\u00e9nik valami\u201d, mi azt mondjuk: \u201eRemek! Akkor kezdj\u00e9tek el blokkolni a socketbe \u00edr\u00e1st, \u00e9s csin\u00e1lj\u00e1tok ezt tranzakci\u00f3kban, hogy biztos legyetek benne, hogy megkaptuk a socket-en, \u00e9s megbizonyosodtok r\u00f3la, hogy azt \u00e1tvett\u00fck.\u201d \u00c9s ebben a pillanatban mindenkinek azonnal nem lesz sz\u00fcks\u00e9ge r\u00e1. Ha pedig nem sz\u00fcks\u00e9ges, akkor mi\u00e9rt k\u00e9rdez\u0151sk\u00f6dnek? Ha nem akarj\u00e1tok garant\u00e1lni a socket \u00edr\u00e1st, mi\u00e9rt garant\u00e1ljuk a k\u00e9zbes\u00edt\u00e9st? Mi \u201ebest effort\u201d-ot csin\u00e1lunk. Val\u00f3ban pr\u00f3b\u00e1ljuk meg min\u00e9l t\u00f6bbet \u00e9s min\u00e9l jobban eljuttatni, de nem adunk 100%-os garanci\u00e1t. Ez\u00e9rt p\u00e9nz\u00fcgyi adatokat nem kell oda \u00edrni. Erre ott vannak a tranzakci\u00f3s adatb\u00e1zisok.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Amikor az API gener\u00e1l egy \u00fczenetet a napl\u00f3ban \u00e9s \u00e1tadja a vez\u00e9rl\u00e9st a mikroszolg\u00e1ltat\u00e1soknak, tal\u00e1lkoztatok-e m\u00e1r azzal a probl\u00e9m\u00e1val, hogy a k\u00fcl\u00f6nb\u00f6z\u0151 mikroszolg\u00e1ltat\u00e1sokb\u00f3l \u00e9rkez\u0151 \u00fczenetek nem a megfelel\u0151 sorrendben \u00e9rkeznek? Ebb\u0151l z\u0171rzavar ad\u00f3dik.<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Norm\u00e1lis, hogy k\u00fcl\u00f6nb\u00f6z\u0151 sorrendben \u00e9rkeznek. Ezzel sz\u00e1molni kell. Mert b\u00e1rmilyen h\u00e1l\u00f3zati k\u00e9zbes\u00edt\u00e9s nem garant\u00e1lja a sorrendet, vagy k\u00fcl\u00f6n er\u0151forr\u00e1sokat kell r\u00e1ford\u00edtani. Ha a f\u00e1jlt\u00e1rol\u00f3kat n\u00e9zz\u00fck, minden API a saj\u00e1t f\u00e1jlj\u00e1ba menti a napl\u00f3kat. Helyesebben a rsyslog ott rendszerezi \u0151ket mapp\u00e1kba. Minden API-nak megvan a saj\u00e1t napl\u00f3ja, ahov\u00e1 el lehet menni \u00e9s megn\u00e9zni, majd a timestamp alapj\u00e1n p\u00e1ros\u00edtani \u0151ket. Ha a Graylog-ba mennek, akkor ott id\u0151rendben lesznek rendezve. Ott minden rendben lesz.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: A timestamp milliszekundumos elt\u00e9r\u00e9seket mutathat.<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: A timestamp-ot mag\u00e1nak az API-nak kell gener\u00e1lnia. Ez igaz\u00e1b\u00f3l az eg\u00e9sz l\u00e9nyeg. Van NTP-\u00fcnk. Az API m\u00e1r mag\u00e1ban az \u00fczenetben gener\u00e1lja a timestamp-ot. A rsyslog nem ad hozz\u00e1.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Nem nagyon \u00e9rthet\u0151, hogyan m\u0171k\u00f6dik az interakci\u00f3 az adatk\u00f6zpontok k\u00f6z\u00f6tt. Az adatk\u00f6zponton bel\u00fcl vil\u00e1gos, hogyan gy\u0171jtik \u00e9s dolgozz\u00e1k fel a napl\u00f3kat. Hogyan t\u00f6rt\u00e9nik az interakci\u00f3 az adatk\u00f6zpontok k\u00f6z\u00f6tt? Vagy minden adatk\u00f6zpont a saj\u00e1t \u00e9let\u00e9t \u00e9li?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Majdnem. Minden orsz\u00e1gunk egy adott adatk\u00f6zpontban tal\u00e1lhat\u00f3. Jelenleg nincs arra p\u00e9lda, hogy egy orsz\u00e1g k\u00fcl\u00f6nb\u00f6z\u0151 adatk\u00f6zpontokban legyen elhelyezve. Ez\u00e9rt nincs sz\u00fcks\u00e9g az egyes\u00edt\u00e9s\u00fckre. Minden k\u00f6zpontban van Log Relay. Ez egy Rsyslog szerver. Val\u00f3j\u00e1ban k\u00e9t menedzsment g\u00e9p van. Mindkett\u0151 ugyan\u00fagy van be\u00e1ll\u00edtva. De egyel\u0151re a forgalom csak az egyiken megy kereszt\u00fcl. Ez aggreg\u00e1lja a napl\u00f3kat. Van egy lemezes sor a biztons\u00e1g kedv\u00e9\u00e9rt. \u00d6sszenyomja a napl\u00f3kat, \u00e9s elk\u00fcldi \u0151ket a k\u00f6zponti adatk\u00f6zpontba (Szingap\u00farba), ahol m\u00e1r Graylogba jutnak. Minden adatk\u00f6zpontban van saj\u00e1t f\u00e1jlt\u00e1rol\u00f3ja. Ha megsz\u0171nik a kapcsolatunk, minden napl\u00f3t ott tartunk. Azok ott maradnak. Azok ott lesznek mentve.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: V\u00e9szhelyzetekben onnan kaptok napl\u00f3kat?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: El lehet menni oda (a f\u00e1jlt\u00e1rol\u00f3hoz) \u00e9s megn\u00e9zni.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Hogyan ellen\u0151rizz\u00e9tek, hogy nem vesz\u00edtettek el napl\u00f3kat?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Val\u00f3j\u00e1ban vesz\u00edt\u00fcnk el napl\u00f3kat, \u00e9s ezt figyelj\u00fck. A monitoroz\u00e1s egy h\u00f3napja indult el. A Go API \u00e1ltal haszn\u00e1lt k\u00f6nyvt\u00e1rban vannak metrik\u00e1k. K\u00e9pes sz\u00e1molni, h\u00e1nyszor nem tudott \u00edrni a socketbe. Jelenleg van egy okos heurisztika. Van egy puffer. Pr\u00f3b\u00e1l \u00fczenetet \u00edrni a socketbe a pufferb\u0151l. Ha a puffer megtelik, elkezdi eldobni \u0151ket. \u00c9s sz\u00e1molja, hogy mennyit dobott el. Ha elkezdik t\u00fall\u00e9pni a sz\u00e1ml\u00e1l\u00f3kat, akkor tudunk r\u00f3la. Ezek most a Prometheusba is ell\u00e1togatnak, \u00e9s a Grafan\u00e1ban meg lehet n\u00e9zni a grafikonokat. Be lehet \u00e1ll\u00edtani a figyelmeztet\u00e9seket. De egyel\u0151re nem vil\u00e1gos, kinek k\u00fcldj\u00fck azokat.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Az Elasticsearch-ben tartotok napl\u00f3kat replik\u00e1ci\u00f3val. H\u00e1ny replik\u00e1tok van?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Egy replika.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Ez csak egy replika?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Ez a mester \u00e9s replika. K\u00e9t p\u00e9ld\u00e1nyban t\u00e1rolj\u00e1k az adatokat.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: A rsyslog puffer\u00e9nek m\u00e9ret\u00e9t valahogy \u00e1ll\u00edtott\u00e1tok? <\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Egyedi unix socketbe \u00edrjuk a datagramokat. Ez azonnal 128 kilob\u00e1jt korl\u00e1tot szab sz\u00e1munkra. Nem tudunk t\u00f6bbet \u00edrni bel\u0151le. Ezt a szabv\u00e1nyban r\u00f6gz\u00edtett\u00fck. Akik a t\u00e1rol\u00f3khoz akarnak jutni, azok 128 kilob\u00e1jtot \u00edrnak. A k\u00f6nyvt\u00e1rak egy\u00e9bk\u00e9nt lev\u00e1gj\u00e1k, \u00e9s jelzik, hogy az \u00fczenet lev\u00e1g\u00e1sra ker\u00fclt. Az \u00fczenet szabv\u00e1ny\u00e1ban van egy speci\u00e1lis mez\u0151, amely megmutatja, hogy az \u00edr\u00e1s k\u00f6zben lev\u00e1g\u00e1sra ker\u00fclt-e vagy sem. Teh\u00e1t van lehet\u0151s\u00e9g\u00fcnk ezt a pontot nyomon k\u00f6vetni.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: \u00cdr-e t\u00f6r\u00f6tt JSON-t? <\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: A t\u00f6r\u00f6tt JSON-t vagy a relay sor\u00e1n, mert t\u00fal nagy csomag, dobj\u00e1k el. Vagy a Graylog dobja el, mert nem tudja a JSON-t elemezni. De itt vannak olyan \u00e1rnyalatok, amelyeket jav\u00edtani kell, \u00e9s ezek d\u00f6nt\u0151en az rsyslog-hoz kapcsol\u00f3dnak. M\u00e1r kit\u00f6lt\u00f6ttem n\u00e9h\u00e1ny probl\u00e9m\u00e1t, amelyeken m\u00e9g dolgozni kell.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Mi\u00e9rt a Kafka? Pr\u00f3b\u00e1lt\u00e1k m\u00e1r a RabbitMQ-t? A Graylog nem m\u0171k\u00f6dik ilyen terhel\u00e9sek mellett?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: N\u00e1lunk a Graylog nem m\u0171k\u00f6dik j\u00f3l. A Graylogunk m\u0171k\u00f6dik, de vele val\u00f3ban probl\u00e9m\u00e1s. Egy k\u00fcl\u00f6n\u00f6s dolog. Igaz\u00e1b\u00f3l nincs is sz\u00fcks\u00e9g r\u00e1. Ink\u00e1bb a rsyslog-b\u00f3l k\u00f6zvetlen\u00fcl az elasticsearch-ba \u00edrn\u00e1m, \u00e9s ut\u00e1na a Kibana-t n\u00e9zn\u00e9m. De el kell rendezni a k\u00e9rd\u00e9st a biztons\u00e1giakkal. Ez egy lehets\u00e9ges fejleszt\u00e9si ir\u00e1nyunk, amikor kidobjuk a Graylogot, \u00e9s csak a Kibana-t haszn\u00e1ljuk. A Logstash haszn\u00e1lat\u00e1nak nincs \u00e9rtelme, mert ugyanazt meg tudom csin\u00e1lni az rsyslog-gal. \u00c9s van modulja az elasticsearch-ba val\u00f3 \u00edr\u00e1sra. A Graylog-gal pr\u00f3b\u00e1lunk valahogy egy\u00fctt \u00e9lni. M\u00e9g kicsit tuningoltuk is. De ott van m\u00e9g tere a fejleszt\u00e9seknek.<\/p>\n<\/p>\n
A Kafka kapcs\u00e1n. \u00cdgy alakult ez t\u00f6rt\u00e9netileg. Amikor \u00e9rkeztem, m\u00e1r l\u00e9tezett, \u00e9s logokat m\u00e1r \u00edrtak bele. Csak fel\u00e1ll\u00edtottuk a klasztert, \u00e9s a logokat \u00e1tk\u00f6lt\u00f6ztett\u00fck. Mi menedzselj\u00fck, tudjuk, hogy \u00e1ll. A RabbitMQ-val kapcsolatban\u2026 nem j\u00f6n \u00f6ssze a RabbitMQ. De a RabbitMQ-unk m\u0171k\u00f6dik. Van a produkci\u00f3s k\u00f6rnyezet\u00fcnkben, \u00e9s voltak vele probl\u00e9m\u00e1k. Mostanra, a le\u00e1raz\u00e1s el\u0151tt, \u00fcgyesebb\u00e9 tett\u00fck, \u00e9s j\u00f3l m\u0171k\u00f6dik. De addig nem voltam felk\u00e9sz\u00fclve, hogy kiadjam a produkci\u00f3s k\u00f6rnyezetbe. Van m\u00e9g egy szempont. A Graylog tudja olvasni az AMQP 0.9 verzi\u00f3t, m\u00edg az rsyslog tudja \u00edrni az AMQP 1.0 verzi\u00f3t. Nincs egy megold\u00e1s sem, ami mindkett\u0151t tudja. Csak az egyik vagy a m\u00e1sik. \u00cdgy jelenleg csak a Kafka m\u0171k\u00f6dik. De ott is vannak saj\u00e1t \u00e1rnyoldalai. Mert az omkafka, amely az rsyslog azon verzi\u00f3j\u00e1t haszn\u00e1lja, amit mi haszn\u00e1lunk, elvesz\u00edtheti az \u00f6sszes \u00fczenetbuffer\u00e9t, amelyet kiszedett az rsyslog-b\u00f3l. Egyel\u0151re megbar\u00e1tkoztunk ezzel. <\/p>\n
<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Azt haszn\u00e1lj\u00e1tok, mert m\u00e1r volt nektek? M\u00e1s c\u00e9lra nem haszn\u00e1lj\u00e1tok?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Az a Kafka, ami volt, a Data Science csapat \u00e1ltal van haszn\u00e1lva. Ez egy teljesen k\u00fcl\u00f6n projekt, amir\u0151l sajnos nem tudok nyilatkozni. Nem vagyok tiszt\u00e1ban vele. A Data Science csapat ir\u00e1ny\u00edt\u00e1sa alatt volt. Amikor a logokat beind\u00edtott\u00e1k, \u00fagy d\u00f6nt\u00f6ttek, hogy azt haszn\u00e1lj\u00e1k, hogy ne kelljen m\u00e9g egy saj\u00e1tot fel\u00e1ll\u00edtani. Most friss\u00edtett\u00fck a Graylog-ot, \u00e9s elvesz\u00edtett\u00fck a kompatibilit\u00e1st, mert ott egy r\u00e9gi Kafka verzi\u00f3 van. Musz\u00e1j volt egy saj\u00e1tot bevezetn\u00fcnk. R\u00e1ad\u00e1sul megszabadultunk a n\u00e9gy t\u00e9mt\u0151l minden API-ra. K\u00e9sz\u00edtett\u00fcnk egy sz\u00e9les t\u00e9m\u00e1t minden \u00e9l\u0151 rendszerhez, \u00e9s egy sz\u00e9les t\u00e9m\u00e1t az \u00f6sszes staging-hez, \u00e9s csak mindent oda k\u00fcld\u00fcnk. A Graylog mindezt p\u00e1rhuzamosan kigy\u0171jti.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: Mi\u00e9rt sz\u00fcks\u00e9ges ez a var\u00e1zsl\u00e1s a socketekkel? Pr\u00f3b\u00e1lt\u00e1tok a syslog log driver haszn\u00e1lat\u00e1t a kont\u00e9nerekhez?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: Abban az id\u0151szakban, amikor ezzel a k\u00e9rd\u00e9ssel foglalkoztunk, a Dockerrel val\u00f3 kapcsoltunk fesz\u00fcltt\u00e9 v\u00e1lt. Ez a Docker 1.0 vagy 0.9 volt. A Docker \u00f6nmag\u00e1ban furcsa volt. M\u00e1sr\u00e9szt, ha a napl\u00f3kat is bele kell tenni... Van egy ellen\u0151rizetlen gyan\u00fam, hogy minden napl\u00f3t \u00e1tenged a kapcsolati d\u00e9monj\u00e1n. Ha van egy API, ami meg\u0151r\u00fcl, akkor a t\u00f6bbi API bele\u00fctk\u00f6zik abba, hogy nem tudja elk\u00fcldeni a stdout-ot \u00e9s stderr-t. Nem tudom, hogy ez hov\u00e1 vezet. Van egy \u00e9rz\u00e9sem, hogy ebben a helyzetben nem kellene haszn\u00e1lni a Docker syslog-illeszt\u0151j\u00e9t. A funkcion\u00e1lis tesztel\u0151 oszt\u00e1lyunknak van egy saj\u00e1t kis Graylog klasztere a napl\u00f3kkal. \u0150k haszn\u00e1lj\u00e1k a Docker napl\u00f3-illeszt\u0151it, \u00e9s \u00fagy t\u0171nik, hogy n\u00e1luk minden rendben van. De \u0151k k\u00f6zvetlen\u00fcl a GELF-t \u00edrj\u00e1k a Graylogba. Abban az id\u0151szakban, amikor mindez elkezd\u0151d\u00f6tt, csak azt akartuk, hogy m\u0171k\u00f6dj\u00f6n. Lehet, hogy k\u00e9s\u0151bb, amikor valaki azt mondja, hogy ez m\u00e1r r\u00e9g\u00f3ta j\u00f3l m\u0171k\u00f6dik, akkor megpr\u00f3b\u00e1ljuk.<\/p>\n<\/p>\n
K\u00e9rd\u00e9s<\/strong>: A sz\u00e1ll\u00edt\u00e1st a datacenter-ek k\u00f6z\u00f6tt rsyslog-on v\u00e9gezz\u00fck. Mi\u00e9rt nem Kafka-val?<\/p>\n<\/p>\n
V\u00e1lasz<\/strong>: T\u00e9nyleg mindk\u00e9t m\u00f3dot haszn\u00e1ljuk. K\u00e9t okb\u00f3l. Ha a csatorna teljesen megvan gyilkolva, akkor m\u00e9g t\u00f6m\u00f6r\u00edtett form\u00e1ban sem mennek \u00e1t a napl\u00f3k. A Kafka azonban lehet\u0151v\u00e9 teszi, hogy egyszer\u0171en elvesz\u00edtj\u00fck \u0151ket a folyamat sor\u00e1n. Ezzel a m\u00f3dszerrel elker\u00fclj\u00fck a napl\u00f3k elakad\u00e1s\u00e1t. Ilyen esetben egyszer\u0171en k\u00f6zvetlen\u00fcl haszn\u00e1ljuk a Kafka-t. Ha a csatorn\u00e1nk j\u00f3, \u00e9s szeretn\u00e9nk felszabad\u00edtani, akkor rsyslog-ot haszn\u00e1lunk. De val\u00f3j\u00e1ban be lehet \u00e1ll\u00edtani, hogy automatikusan dobja ki azt, ami nem ment \u00e1t. Jelenleg valahol k\u00f6zvetlen\u00fcl az rsyslog sz\u00e1ll\u00edt\u00e1st haszn\u00e1ljuk, valahol pedig Kafka-t.<\/p>\nForr\u00e1s: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041b\u043e\u0433\u0438 \u2014 \u0432\u0430\u0436\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u043e\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 (\u043b\u0438\u0431\u043e \u043d\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u043a\u0430\u043a \u043e\u0436\u0438\u0434\u0430\u0435\u0442\u0441\u044f. \u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043b\u043e\u0433\u0430\u043c\u0438 \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u043e\u0439 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u043e\u043b\u0438\u043c\u043f\u0438\u0430\u0434\u044b. \u041d\u0443\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u0441\u0440\u0430\u0437\u0443 \u043a\u0443\u0447\u0443 \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u0432: \u043a\u0430\u043a \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438 \u0438\u0437 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f; \u043a\u0443\u0434\u0430 \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438; \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u043b\u043e\u0433\u0438 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438; \u043a\u0430\u043a \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u0438 \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438. \u041f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043d\u044b\u043d\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Vide\u00f3](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n