Log mangrupikeun bagian penting tina sistem, anu ngamungkinkeun anjeun ngartos yén éta jalan (atanapi henteu tiasa dianggo) sapertos anu diharapkeun. Dina arsitéktur microservice, gawé bareng log janten disiplin misah pikeun Olimpiade husus. Sababaraha patarosan kedah direngsekeun sakaligus:
- kumaha carana nyerat log tina aplikasi;
- dimana nulis log;
- kumaha nganteurkeun log pikeun neundeun jeung ngolah;
- kumaha ngolah jeung nyimpen log.
Pamakéan téknologi containerization populér ayeuna nambihan keusik dina luhureun rake kana widang pilihan pikeun ngarengsekeun masalah.
Ieu persis naon transkrip laporan Yuri Bushmelev "Peta rake dina widang ngumpulkeun sarta nganteurkeun log" ngeunaan.
Anu paduli, mangga handapeun ucing.
Ngaran abdi Yuri Bushmelev. Abdi damel di Lazada. Dinten ieu kuring bakal ngobrol ngeunaan kumaha urang nyieun log urang, kumaha urang dikumpulkeun eta, sarta naon urang nulis di dinya.
Urang ti mana? Saha urang? Lazada mangrupikeun pangecér online nomer 1 di genep nagara di Asia Tenggara. Sadaya nagara ieu disebarkeun di antara pusat data urang. Ayeuna aya total pusat data 4. Naha ieu penting? Kusabab sababaraha kaputusan éta alatan kanyataan yén aya link pisan lemah antara puseur. Kami ngagaduhan arsitéktur microservice. Kuring reuwas pikeun manggihan yén urang geus boga 80 microservices. Nalika kuring ngamimitian tugas kalawan log, aya ngan 20. Ditambah aya sapotong rada badag tina warisan PHP, nu kuring ogé kudu hirup jeung nempatkeun up kalawan. Sadaya ieu ayeuna ngahasilkeun langkung ti 6 juta pesen per menit pikeun sistem sacara gembleng. Satuluyna kuring bakal nunjukkeun kumaha urang nyobian hirup sareng ieu, sareng naha ieu kitu.
Anjeun kudu kumaha bae hirup kalawan ieu 6 juta pesen. Naon anu kudu urang pigawé kalayan aranjeunna? 6 juta pesen anjeun peryogi:
- kirimkeun tina aplikasi
- nampi pikeun pangiriman
- nganteurkeun pikeun analisis jeung neundeun.
- nganalisis
- nyimpen eta kumaha bae.
Nalika tilu juta pesen muncul, kuring katingalina sami. Kusabab urang mimitian ku ngan sababaraha pennies. Éta jelas yén log aplikasi ditulis di dinya. Contona, kuring teu bisa nyambung ka database, kuring bisa nyambung ka database tapi teu bisa maca nanaon. Tapi sajaba ti ieu, unggal microservices urang ogé nulis log aksés. Unggal pamundut anu sumping ka microservice kacatet dina log. Naha urang ngalakukeun ieu? Pamekar hoyong tiasa ngalacak. Unggal log aksés ngandung hiji widang traceid, ngagunakeun nu panganteur husus lajeng unwinds sakabéh ranté sarta beautifully mintonkeun renik. Lacak nunjukkeun kumaha pamenta na, sareng ieu ngabantosan pamekar urang gancang nungkulan sampah anu teu dipikanyaho.
Kumaha carana hirup kalawan ieu? Ayeuna kuring sakeudeung ngajelaskeun widang pilihan - kumaha masalah ieu umumna direngsekeun. Kumaha ngabéréskeun masalah ngumpulkeun, ngirimkeun sareng nyimpen log.
Kumaha cara nyerat tina aplikasi? Ieu jelas yén aya cara béda. Dina sababaraha hal, aya prakték pangalusna, sakumaha comrades fashionable urang ngabejaan urang. Aya dua jenis sakola heubeul, sakumaha ceuk akina urang. Aya cara séjén.
Kaayaan pikeun ngumpulkeun log kira-kira sami. Henteu seueur pilihan pikeun ngarengsekeun bagian khusus ieu. Geus aya leuwih ti éta, tapi teu jadi loba acan.
Tapi kalayan pangiriman sareng analisa salajengna, jumlah variasi mimiti ngabeledug. Kuring moal ngajelaskeun unggal pilihan ayeuna. Jigana pilihan utama anu ogé dipikawanoh ka dulur anu museurkeun topik.
Kuring bakal nunjukkeun ka anjeun kumaha urang ngalakukeun éta di Lazada, sareng kumaha éta sadayana dimimitian.
Sataun ka tukang kuring sumping ka Lazada sareng dikirim ka proyék ngeunaan log. Ieu hal kawas kieu. Log aplikasi ditulis kana stdout sareng stderr. Sagalana dipigawé dina cara fashionable. Tapi teras pamekar ngaluarkeun éta tina aliran standar, teras kumaha waé para ahli infrastruktur bakal terang éta. Di antara spesialis infrastruktur sareng pamekar, aya ogé anu ngaluarkeun anu nyarios: "eh ... oke, hayu urang bungkus dina file nganggo cangkang, sareng éta." Sarta saprak kabeh ieu dina wadahna, aranjeunna mungkus eta katuhu dina wadahna sorangan, dipetakeun katalog di jero sarta nempatkeun eta aya. Jigana éta geulis atra ka dulur naon datang ti eta.
Hayu urang néangan saeutik salajengna pikeun ayeuna. Kumaha urang nganteurkeun log ieu? Batur milih td-agén, nu sabenerna fluentd, tapi teu cukup fluentd. Kuring masih teu ngarti hubungan antara dua proyék ieu, tapi aranjeunna sigana ngeunaan hal anu sarua. Jeung ieu fluentd, ditulis dina Ruby, maca file log, parsed kana JSON ngagunakeun sababaraha jenis aturanana. Saterusna kuring dikirim ka Kafka. Sumawona, di Kafka kami ngagaduhan 4 topik anu misah pikeun tiap API. Naha 4? Kusabab aya live, aya pementasan, sarta kusabab aya stdout na stderr. Pamekar nyiptakeunana, sareng pamekar infrastruktur kedah nyiptakeunana di Kafka. Leuwih ti éta, Kafka dikawasa ku departemen séjén. Ku alatan éta, perlu nyieun tikét a ambéh maranéhanana bakal nyieun 4 jejer pikeun tiap api. Sarerea poho ngeunaan eta. Sacara umum, aya runtah jeung fuss.
Naon anu urang lakukeun salajengna sareng ieu? Urang dikirim ka Kafka. Lajeng satengah tina log ti Kafka flew ka Logstash. Satengah séjén tina log dibagi. Sababaraha flew ka hiji Graylog, sababaraha ka Graylog sejen. Hasilna, sadayana ieu lebet kana hiji klaster Elasticsearch. Nyaéta, sakabéh mess ieu réngsé nepi di dinya. Ulah kitu!
Ieu kumaha sigana upami anjeun ningali ti luhur. Ulah kitu! Di dieu wewengkon masalah langsung ditandaan ku angka. Sabenerna aya seueur deui, tapi 6 mangrupikeun masalah anu leres-leres anu kedah dilakukeun. Kuring gé ngabejaan Anjeun tentang aranjeunna misah ayeuna.
Di dieu (1,2,3) urang nulis file na, sasuai, aya tilu rakes dieu sakaligus.
Kahiji (1) nyaeta urang kudu nulis aranjeunna wae. Éta moal salawasna desirable méré API kamampuhan pikeun nulis langsung ka file. Éta desirable yén API diisolasi dina wadahna, atawa malah leuwih hadé, éta bisa dibaca wungkul. Abdi pangurus sistem, janten kuring gaduh pandangan anu rada alternatif pikeun hal-hal ieu.
Titik kadua (2,3) nyaeta urang kudu loba requests datang ka API. API nyerat seueur data kana file. Berkas-berkas ngembang. Urang kudu muterkeun aranjeunna. Kusabab upami henteu, anjeun moal tiasa nyimpen kana disk anu aya. Puteran aranjeunna goréng sabab dijieun ku Mindahkeun ngaliwatan cangkang ka diréktori. Teu aya cara urang tiasa ngarévisi éta. Anjeun teu bisa ngabejaan aplikasi pikeun muka deui handles. Kusabab pamekar bakal kasampak di anjeun kawas anjeun bodo: "Naon deskriptor? Kami umumna nyerat ka stdout. Pamekar infrastruktur ngadamel copytruncate pikeun logrotate, anu ngan saukur ngadamel salinan file sareng nranskripsikeun aslina. Sasuai, antara prosés nyalin ieu spasi disk biasana béak.
(4) Kami ngagaduhan format anu béda dina API anu béda. Aranjeunna rada béda, tapi regexp kedah ditulis béda. Kusabab sakabeh ieu dikawasa ku Wayang, aya kebat badag kelas kalawan cockroaches sorangan. Tambih Deui, lolobana waktu td-agén bisa dahar memori, janten bodo, éta ngan bisa pretend yén éta téh digawé tur ngalakukeun nanaon. Ti luar teu mungkin ngartos yen anjeunna ngalakukeun nanaon. Di pangalusna, anjeunna bakal ragrag jeung batur bakal nyokot anjeunna engké. Langkung tepatna, waspada bakal sumping, sareng aya anu badé angkat sareng angkat ku pananganana.
(6) Jeung paling sampah jeung runtah éta elasticsearch. Kusabab éta versi heubeul. Kusabab urang teu boga master dedicated dina waktu éta. Kami ngagaduhan log hétérogén anu sawahna tiasa tumpang tindih. Log anu béda tina aplikasi anu béda tiasa ditulis nganggo nami lapangan anu sami, tapi tiasa aya data anu béda di jerona. Hartina, hiji log hadir kalawan Integer dina widang, contona, tingkat. log sejen hadir kalawan String dina widang tingkat. Dina henteuna pemetaan statik, ieu mangrupikeun hal anu saé. Upami, saatos puteran indéks dina elasticsearch, pesen kalayan senar sumping heula, maka urang hirup normal. Tapi upami anu pangheulana sumping ti Integer, maka sadaya pesen anu salajengna anu sumping ti String ngan saukur dipiceun. Kusabab jenis widang teu cocog.
Urang mimitian naroskeun patarosan ieu. Kami mutuskeun pikeun henteu milarian anu disalahkeun.
Tapi aya anu kedah dilakukeun! Hal anu jelas nyaéta urang kedah netepkeun standar. Kami parantos ngagaduhan sababaraha standar. Urang mimitian sababaraha saeutik engké. Untungna, format log tunggal pikeun sadaya API parantos disatujuan dina waktos éta. Ditulis langsung kana standar pikeun interaksi antara jasa. Sasuai, jalma anu hoyong nampi log kedah nyerat dina format ieu. Upami aya anu henteu nyerat log dina format ieu, maka kami henteu ngajamin nanaon.
Salajengna, abdi hoyong nyiptakeun standar anu ngahijikeun pikeun metode ngarékam, nganteurkeun sareng ngumpulkeun log. Sabenerna, dimana nulis aranjeunna, sarta kumaha carana nganteurkeun aranjeunna. Kaayaan idéal nyaéta nalika proyék nganggo perpustakaan anu sami. Aya perpustakaan logging misah pikeun Go, sarta perpustakaan misah pikeun PHP. Sarerea urang kudu ngagunakeun aranjeunna. Di momen, abdi bakal disebutkeun yen kami 80 persen suksés di ieu. Tapi sababaraha urang neruskeun dahar kaktus.
Sareng aya (dina slide) "SLA pikeun pangiriman log" bieu mimiti muncul. Teu acan aya, tapi urang nuju damel. Kusabab éta pohara merenah nalika infrastruktur nyebutkeun yen lamun nulis dina format sapertos na sapertos ka tempat sapertos na teu leuwih ti N pesen per detik, lajeng urang paling dipikaresep bakal nganteurkeun ka tempat sapertos na kitu. Ieu relieves loba headaches. Upami aya SLA, maka ieu leres pisan!
Kumaha urang ngawitan ngajawab masalah? Masalah utama éta kalayan td-agén. Teu écés kamana log urang indit. Dupi aranjeunna dikirimkeun? Dupi aranjeunna bade? Dimana wae aranjeunna? Ku alatan éta, titik kahiji ieu mutuskeun pikeun ngaganti td-agén. Kuring geus sakeudeung outlined pilihan pikeun naon ngaganti eta kalawan dieu.
Fluentd. Firstly, abdi encountered anjeunna dina pakasaban saméméhna, sarta anjeunna ogé périodik murag aya. Bréh, ieu hal anu sarua, ngan dina profil.
Filebeat. Kumaha éta merenah pikeun urang? Kusabab éta di Go, sarta kami boga loba kaahlian dina Go. Sasuai, lamun aya kajadian, urang kumaha bae bisa nambahkeun eta keur diri urang sorangan. Éta sababna urang henteu nyandak éta. Janten henteu aya godaan pikeun ngamimitian nyerat deui pikeun diri anjeun.
Solusi anu jelas pikeun administrator sistem nyaéta sagala jinis syslogs dina kuantitas ieu (syslog-ng/rsyslog/nxlog).
Atawa nulis hal anjeun sorangan, tapi urang dipiceun ieu, kitu ogé filebeat. Lamun nulis hiji hal, eta leuwih hade nulis hal mangpaat pikeun bisnis. Pikeun nganteurkeun log, langkung saé nyandak anu siap-dijieun.
Ku alatan éta, pilihan sabenerna turun ka pilihan antara syslog-ng na rsyslog. Kuring condong ka rsyslog ngan kusabab urang parantos ngagaduhan kelas pikeun rsyslog dina Wayang, sareng kuring henteu mendakan bédana anu jelas antara aranjeunna. Naon syslog, naon syslog. Sumuhun, sababaraha gaduh dokuméntasi goréng, sababaraha gaduh hadé. Anu ieu tiasa dilakukeun ku cara ieu, sareng anu sanésna tiasa dilakukeun ku cara anu béda.
Sarta saeutik ngeunaan rsyslog. Anu mimiti, éta keren sabab seueur modul. Éta gaduh RainerScript anu tiasa dibaca manusa (basa konfigurasi modern). Ieu bonus Heboh nu urang bisa emulate paripolah td-agén ngagunakeun parabot baku, jeung euweuh robah pikeun aplikasi. Hartina, urang ngarobah td-agén pikeun rsyslog, sarta ninggalkeun sagalana sejenna nyalira pikeun ayeuna. Sareng kami langsung nampi pangiriman damel. Salajengna, mmnormalize mangrupikeun hal anu saé dina rsyslog. Eta ngidinan Anjeun pikeun parse log, tapi teu make Grok na regexp. Éta ngajadikeun tangkal sintaksis abstrak. Ieu parses log dina cara nu sarua salaku compiler parses sumber. Ieu ngamungkinkeun anjeun damel gancang pisan, meakeun sakedik CPU, sareng, sacara umum, éta mangrupikeun hal anu saé. Aya sakumpulan bonus séjén. Kuring moal cicing dina aranjeunna.
rsyslog ngagaduhan seueur kalemahan anu sanés. Éta ngeunaan sarua jeung bonus. Masalah utama nyaéta yén anjeun kedah terang kumaha masak éta, sareng anjeun kedah milih versi.
Urang mutuskeun yén urang bakal nulis log kana stop kontak unix. Na teu di / dev / log, sabab aya urang gaduh mess tina sistem log, journald aya dina pipa ieu. Janten hayu urang nyerat kana stop kontak khusus. Urang bakal ngagantelkeun kana aturan anu misah. Hayu urang teu ngaganggu nanaon. Sadayana bakal transparan sareng kaharti. Éta kahayang urang ngalakukeun. Diréktori sareng sockets ieu standarisasi sareng diteruskeun ka sadaya wadah. Wadahna tiasa ningali stop kontak anu diperyogikeun, muka sareng nyerat kana éta.
Naha henteu file? Kusabab sarerea maca eta , nu nyoba neraskeun file ka docker, sarta kapanggih yén sanggeus dibalikan deui rsyslog, file descriptor robah, sarta docker leungit file ieu. Eta ngajaga hal sejenna kabuka, tapi teu stop kontak dimana aranjeunna nulis. Urang mutuskeun yén urang bakal ngungkulan masalah ieu, sarta dina waktos anu sareng, urang bakal nungkulan masalah blocking.
Rsyslog ngalakukeun tindakan anu dituduhkeun dina slide sareng ngirim log ka relay atanapi Kafka. Kafka nuturkeun cara baheula. Relay - Kuring diusahakeun make rsyslog murni pikeun nganteurkeun log. Tanpa Pesen Antrian, ngagunakeun parabot rsyslog baku. Dasarna, éta jalan.
Tapi aya nuansa kumaha nyorong kana bagian ieu (Logstash / Graylog / ES). Ieu bagian (rsyslog-rsyslog) dipaké antara puseur data. Ieu mangrupikeun tautan tcp anu dikomprés, anu ngamungkinkeun urang ngahémat rubakpita sareng, sasuai, kumaha waé ningkatkeun kamungkinan yén urang bakal nampi sababaraha log ti pusat data anu sanés nalika saluran tersumbat. Kusabab urang boga Indonesia, dimana sagalana goréng. Ieu dimana masalah konstan perenahna.
Urang panginten kumaha urang tiasa leres-leres ngawas kumaha kamungkinan yén log anu dirékam tina aplikasi bakal dugi ka tungtungna? Urang mutuskeun pikeun nyieun metrics. rsyslog boga modul kempelan statistik sorangan, nu ngandung sababaraha jenis counters. Salaku conto, éta tiasa nunjukkeun anjeun ukuran antrian, atanapi sabaraha pesen anu parantos sumping dina aksi sapertos kitu. Anjeun tos tiasa nyandak hiji hal ti aranjeunna. Tambih Deui, eta boga counters custom nu bisa ngonpigurasi, sarta eta bakal némbongkeun Anjeun, Contona, jumlah pesen nu sababaraha API dirékam. Salajengna, abdi wrote rsyslog_exporter di Python, sarta kami dikirim kabeh ka Prometheus tur diwangun grafik. Kami leres-leres hoyong métrik Graylog, tapi kami henteu acan gaduh waktos pikeun nyetélana.
Naon masalahna? Masalah timbul nalika urang mendakan (DUGA!) yén Live API urang nyerat 50k pesen per detik. Ieu ngan hiji Live API tanpa pementasan. Sareng Graylog nunjukkeun ka urang ngan ukur 12 rébu pesen per detik. Sareng patarosan anu wajar timbul: dimana sésa-sésa? Ti mana kami menyimpulkan yén Graylog saukur teu bisa Cope. Kami ningali, sareng, memang, Graylog sareng Elasticsearch henteu tiasa ngadamel aliran ieu.
Salajengna, pamanggihan séjén kami dijieun sapanjang jalan.
Nulis kana stop kontak diblokir. Kumaha éta kajantenanna? Nalika kuring ngagunakeun rsyslog pikeun pangiriman, di sawatara titik saluran antara puseur data peupeus handap. Pangiriman eureun di hiji tempat, pangiriman eureun di tempat séjén. Sadaya ieu parantos ngahontal mesin sareng API anu nyerat kana stop kontak rsyslog. Aya antrian di dinya. Lajeng antrian pikeun nulis kana stop kontak unix, nu sacara standar 128 pakét, dieusian nepi. Jeung nulis salajengna () dina aplikasi diblokir. Nalika kami ningali perpustakaan anu kami anggo dina aplikasi Go, éta ditulis yén tulisan kana stop kontak lumangsung dina modeu non-blocking. Kami yakin yén euweuh anu diblokir. Kusabab urang maca anu nulis ngeunaan eta. Tapi aya sakedapan. Aya ogé loop tanpa wates sabudeureun panggero ieu, nu aya usaha konstan nyorong pesen kana stop kontak nu. Kami henteu perhatikeun anjeunna. Kuring kungsi nulis ulang perpustakaan. Saprak harita geus robah sababaraha kali, tapi ayeuna urang geus meunang leupas tina blocking dina sakabéh subsistem. Kituna, anjeun bisa ngeureunkeun rsyslog, sarta euweuh bakal ngadat.
Perlu ngawas ukuran antrian, nu mantuan ulah stepping on rake ieu. Mimiti, urang tiasa ngawas nalika urang mimiti kaleungitan pesen. Bréh, urang tiasa ngawas yén urang gaduh masalah sareng pangiriman.
Sareng momen anu henteu pikaresepeun - amplifikasi ku 10 kali dina arsitéktur microservice pisan gampang. Urang teu boga loba requests asup, tapi kusabab grafik sapanjang nu pesen ieu ngarambat salajengna, kusabab aksés log, urang sabenerna ngaronjatkeun beban log ku ngeunaan sapuluh kali. Hanjakal, kuring teu boga waktu pikeun ngitung jumlah pasti, tapi microservices naon aranjeunna. Ieu kudu tetep dina pikiran. Tétéla ayeuna subsistem koleksi log anu paling dimuat dina Lazada.
Kumaha carana ngajawab masalah elasticsearch? Lamun perlu gancang meunangkeun log di hiji tempat, ku kituna teu ngajalankeun kira-kira ka sadaya mesin jeung ngumpulkeun eta aya, make gudang file. Ieu dijamin jalan. Éta tiasa dilakukeun tina server mana waé. Anjeun ngan perlu nempelkeun disk di dinya tur masang syslog. Saatos ieu, anjeun dijamin gaduh sadayana log dina hiji tempat. Teras anjeun lalaunan tiasa ngonpigurasikeun elasticsearch, graylog, sareng anu sanésna. Tapi anjeun bakal geus boga sagala log, sarta, komo deui, anjeun bisa nyimpen eta sajauh aya cukup arrays disk.
Dina waktu laporan kuring, skéma mimiti kasampak kawas kieu. Urang praktis dieureunkeun nulis kana file. Ayeuna, paling dipikaresep, urang bakal mareuman sésana. Dina mesin lokal ngajalankeun API, urang bakal eureun nulis kana file. Kahiji, aya gudang file, nu gawéna kacida alusna. Kadua, mesin-mesin ieu terus-terusan kaluar tina rohangan; éta kedah diawaskeun terus-terusan.
Ieu bagian kalawan Logstash na Graylog, bener nyokot kaluar. Ku alatan éta, urang kudu meunang leupas tina eta. Anjeun kudu milih hiji hal.
Urang mutuskeun buang kaluar Logstash na Kibana. Kusabab urang boga departemen kaamanan. sambungan naon? Sambungan éta Kibana tanpa X-Pack sareng tanpa Shield henteu ngamungkinkeun anjeun ngabédakeun hak aksés kana log. Éta sababna urang nyandak Graylog. Éta gaduh sadayana. Abdi henteu resep, tapi tiasa dianggo. Kami ngagaleuh hardware énggal, dipasang Graylog seger didinya sareng mindahkeun sadaya log kalayan format anu ketat ka Graylog anu misah. Kami ngarengsekeun masalah sareng sababaraha jinis widang anu sami sacara organisasi.
Naon kahayang téh kaasup kana Graylog anyar. Urang ngan nulis sagalana kana docker. Kami nyandak sakumpulan server, ngagulung tilu instansi Kafka, 7 server Graylog versi 2.3 (sabab urang hoyong versi Elasticsearch 5). Kabéh ieu ngajemput salila razia ti HDD. Urang nempo laju indexing nepi ka 100 sarébu pesen per detik. Urang nempo inohong anu 140 terabytes data per minggu.
Jeung deui rake! Kami gaduh dua penjualan anu badé. Urang dipindahkeun saluareun 6 juta pesen. Graylog teu boga waktu pikeun nyapek. Kumaha bae urang kudu salamet deui.
Ieu kumaha urang salamet. Urang ditambahkeun sababaraha server na SSDs. Di momen urang hirup cara kieu. Ayeuna urang parantos nyapek 160k pesen per detik. Kami henteu acan ngahontal watesna, janten teu jelas sabaraha urang tiasa kaluar tina ieu.
Ieu mangrupikeun rencana urang pikeun masa depan. Tina ieu, anu paling penting nyaéta kasadiaan anu luhur. Kami henteu acan gaduh. Sababaraha mobil dikonpigurasi dina cara anu sami, tapi sajauh ieu sadayana ngalangkungan hiji mobil. Butuh waktu pikeun nyetél failover antara aranjeunna.
Kumpulkeun métrik tina Graylog.
Jieun wates laju ku kituna urang boga hiji API gélo nu teu maéhan rubakpita urang jeung sagalana sejenna.
Sarta pamustunganana, asup sababaraha jenis SLA jeung pamekar ku kituna urang bisa ngawula ka ieu loba. Upami anjeun nyerat langkung seueur, hapunten.
Jeung nulis dokuméntasi.
Sakeudeung, hasil tina sagalana urang ngalaman. Kahiji, standar. Bréh, syslog nyaéta jajan. Thirdly, rsyslog jalan persis sakumaha eta ditulis dina slide. Sareng hayu urang teraskeun kana patarosan.
patarosan.
patarosan: Naha anjeun mutuskeun henteu nyandak ... (filebeat?)
jawaban: Urang kedah nyerat kana file. Nyaan teu hayang. Nalika API anjeun nyerat rébuan pesen per detik, sanaos anjeun muterkeunana sakali sajam, ieu sanés pilihan. Anjeun tiasa nyerat dina pipa. Anu pamekar naroskeun ka kuring: "Naon anu bakal kajantenan upami prosés anu urang nyerat ngadat?" Kuring ngan teu manggihan naon ngajawab aranjeunna, sarta ngomong: "Muhun, ok, hayu urang ulah ngalakukeun éta."
patarosan: Naha anjeun henteu nyerat log kana HDFS?
jawaban: Ieu tahap salajengna. Urang mikir ngeunaan eta di pisan awal, tapi saprak di momen euweuh sumberdaya pikeun ngalakukeun ieu, éta hangs dina solusi jangka panjang urang.
patarosan: Format kolom bakal leuwih cocog.
jawaban: Abdi ngartos. Kami pikeun eta kalawan duanana leungeun.
patarosan: Anjeun nulis ka rsyslog. Di dinya anjeun tiasa nganggo TCP sareng UDP. Tapi upami UDP, teras kumaha anjeun ngajamin pangiriman?
jawaban: Aya dua titik. Mimiti, kuring langsung nyarios ka sadayana yén kami henteu ngajamin pangiriman log. Kusabab nalika pamekar datang sarta ngomong: "Hayu urang mimitian nulis data finansial aya, tur anjeun bakal nempatkeun eta wae keur urang bisi aya kajadian,"Kami ngajawab aranjeunna, "Hébat! Hayu urang mimitian meungpeuk dina nulis kana stop kontak, sarta ngalakukeun ieu dina transaksi, ku kituna anjeun dijamin nempatkeun eta dina stop kontak pikeun urang jeung pastikeun yén urang narima eta ti sisi séjén. Sareng dina waktos ieu, sadayana langsung henteu peryogi deui. Upami éta henteu diperyogikeun, maka patarosan naon anu kedah urang naroskeun? Upami anjeun henteu hoyong ngajamin nyerat kana stop kontak, naha urang kedah ngajamin pangiriman? Kami ngalakukeun usaha anu pangsaéna. Kami leres-leres nyobian nganteurkeun saloba mungkin sareng ku cara anu pangsaéna, tapi kami henteu masihan garansi 100%. Ku alatan éta, aya teu kudu nulis data finansial dinya. Aya database sareng transaksi pikeun ieu.
patarosan: Nalika API dibangkitkeun sababaraha pesen dina log sarta mindahkeun kontrol ka microservices, Dupi anjeun encountered masalah nu pesen ti microservices béda datangna dina urutan salah? Ieu ngabalukarkeun kabingungan.
jawaban: Ieu normal yén maranéhna datang dina urutan béda. Anjeun kedah disiapkeun pikeun ieu. Kusabab sagala pangiriman jaringan teu ngajamin urutan, atawa anjeun kudu méakkeun sumberdaya husus dina ieu. Upami urang nyandak panyimpen file, teras unggal API nyimpen log kana filena nyalira. Atawa rada, aya rsyslog sorts kana directories. Unggal API gaduh log sorangan, dimana anjeun tiasa angkat sareng ningali, teras anjeun tiasa ngabandingkeunana nganggo timestamp dina log ieu. Upami aranjeunna milarian dina Graylog, teras aranjeunna diurutkeun ku timestamp. Sagalana bakal rupa aya.
patarosan: Timestamp bisa rupa-rupa ku milidetik.
jawaban: Timestamp dihasilkeun ku API sorangan. Ieu, kanyataanna, sakabeh titik. Kami ngagaduhan NTP. API ngahasilkeun timestamp dina suratna sorangan. rsyslog henteu nambihanana.
patarosan: Interaksi antara puseur data teu pisan jelas. Dina pusat data, jelas kumaha log dikumpulkeun sareng diolah. Kumaha interaksi antara pusat data lumangsung? Atawa unggal puseur data hirup hirup sorangan?
jawaban: Méh. Di nagara urang, unggal nagara aya dina hiji pusat data. Di momen, urang teu boga sumebar kaluar ambéh hiji nagara lokasina di puseur data béda. Ku alatan éta, teu perlu ngagabungkeun aranjeunna. Unggal puseur ngabogaan Log Relay jero. Ieu mangrupikeun server Rsyslog. Sabenerna dua mesin manajemén. Maranehna boga sikep anu sarua. Tapi pikeun ayeuna, lalulintas ngan ngaliwatan salah sahijina. Ieu aggregates sadaya log. Manehna boga antrian disk ngan bisi. Ieu ngundeur log sarta ngirimkeunana ka puseur data sentral (Singapura), dimana aranjeunna lajeng dikirim ka Graylog. Sareng unggal pusat data gaduh panyimpen file sorangan. Bisi sambungan urang leungit, urang gaduh sakabeh log aya. Aranjeunna bakal tetep aya. Éta bakal disimpen di dinya.
patarosan: Bisi kaayaan abnormal, anjeun nampi log ti dinya?
jawaban: Anjeun tiasa buka aya (ka gudang file) jeung kasampak.
patarosan: Kumaha anjeun ngawas yén anjeun teu leungit log?
jawaban: Kami sabenerna kaleungitan aranjeunna, sareng kami ngawaskeunana. Monitoring diluncurkeun sabulan katukang. Perpustakaan anu dianggo ku Go API gaduh métrik. Anjeunna tiasa ngitung sabaraha kali anjeunna henteu tiasa nyerat kana stop kontak. Ayeuna aya hiji heuristik pinter dinya. Aya panyangga di dinya. Ieu nyoba nulis pesen ti dinya ka stop kontak nu. Lamun panyangga overflows, eta dimimitian muterna aranjeunna. Sareng anjeunna ngitung sabaraha di antarana anjeunna turun. Upami méter mimiti mudun di dinya, urang bakal terang ngeunaan éta. Aranjeunna ayeuna ogé sumping ka prometheus, sareng anjeun tiasa ningali grafik dina Grafana. Anjeun tiasa nyetél panggeuing. Tapi can écés ka saha anu ngirimna.
patarosan: Dina elasticsearch Anjeun nyimpen log kalawan redundancy. Sabaraha réplika anjeun gaduh?
jawaban: Hiji garis.
patarosan: Ieu ngan hiji baris?
jawaban: Ieu master sareng replika. Data disimpen dina dua salinan.
patarosan: Dupi anjeun nyaluyukeun ukuran panyangga rsyslog kumaha bae age?
jawaban: Urang nulis datagrams kana stop kontak unix custom. Ieu langsung maksakeun wates 128 kilobyte ka urang. Urang teu bisa nulis leuwih kana eta. Kami parantos nyerat ieu kana standar. Anu hayang asup kana gudang nulis 128 kilobyte. Perpustakaan, komo deui, dipotong, sareng bandéra dipasang yén pesenna dipotong. Standar kami pikeun pesen sorangan ngagaduhan lapangan khusus anu nunjukkeun naha éta dipotong nalika ngarékam atanapi henteu. Janten urang gaduh kasempetan pikeun ngalacak waktos ieu ogé.
Patarosan: Naha anjeun nyerat JSON rusak?
jawaban: Rusak JSON bakal dipiceun boh salila relay sabab pakét badag teuing. Atawa Graylog bakal dipiceun sabab teu bisa parse JSON. Tapi aya nuances nu kudu dibenerkeun, sarta aranjeunna lolobana dihijikeun ka rsyslog. Kuring parantos ngeusian sababaraha masalah di dinya, anu masih kedah digarap.
Patarosan: Naha Kafka? Dupi anjeun nyobian RabbitMQ? Naha Graylog gagal dina beban sapertos kitu?
jawaban: Ieu teu bisa dipake kaluar pikeun kami kalawan Graylog. Sareng Graylog ngawujud pikeun urang. Anjeunna leres-leres bermasalah. Anjeunna hiji hal anu aneh. Jeung, kanyataanna, teu diperlukeun. Abdi langkung resep nyerat tina rsyslog langsung ka elasticsearch teras tingali Kibana. Tapi urang kedah ngabéréskeun masalah sareng satpam. Ieu mangrupikeun pilihan anu mungkin pikeun pangwangunan urang, nalika urang ngalungkeun Graylog sareng nganggo Kibana. Henteu aya gunana nganggo Logstash. Kusabab kuring tiasa ngalakukeun hal anu sami sareng rsyslog. Sareng gaduh modul pikeun nyerat kana elasticsearch. Urang nyobian hirup kumaha bae kalawan Graylog. Urang malah nyaluyukeun eta up saeutik. Tapi masih aya rohangan pikeun perbaikan.
Ngeunaan Kafka. Ieu kumaha kajadian sajarahna. Nalika kuring sumping, éta parantos aya, sareng log parantos diserat. Kami ngan ukur ngangkat klaster kami sareng ngalihkeun log kana éta. Kami manajemén na, urang terang kumaha perasaan anjeunna. Sedengkeun pikeun RabbitMQ ... teu dianggo kaluar pikeun urang kalawan RabbitMQ. Sareng RabbitMQ nuju ngawangun pikeun urang. Kami ngagaduhan éta dina produksi, sareng aya masalah sareng éta. Ayeuna, sateuacan dijual, aranjeunna bakal mesona anjeunna, sareng anjeunna bakal ngamimitian damel normal. Tapi sateuacan éta kuring henteu acan siap ngaleupaskeun kana produksi. Aya hiji deui titik. Graylog tiasa maca versi AMQP 0.9, sareng rsyslog tiasa nyerat versi AMQP 1.0. Sareng teu aya solusi tunggal di tengah anu tiasa ngalakukeun duanana. Ieu boh hiji atawa lianna. Ku alatan éta, dina momen ngan Kafka. Tapi ogé boga nuances sorangan. Kusabab omkafka tina versi rsyslog nu kami nganggo bisa leungit sakabéh panyangga pesen nu raked kaluar tina rsyslog. Pikeun ayeuna urang nempatkeun eta.
Patarosan: Dupi anjeun nganggo Kafka sabab anjeun parantos ngagaduhan? Henteu dianggo deui pikeun tujuan naon?
jawaban: Kafka, nu tadi, dipaké ku tim Data Science. Ieu proyek sagemblengna misah, ngeunaan nu, hanjakalna, kuring teu bisa ngomong nanaon. Abdi henteu terang. Éta dijalankeun ku tim Élmu Data. Nalika log didamel, kami mutuskeun pikeun ngagunakeunana supados henteu dipasang nyalira. Ayeuna kami parantos ngamutahirkeun Graylog, sareng kami kaleungitan kasaluyuan sabab gaduh versi Kafka anu lami. Urang kedah ngamimitian sorangan. Dina waktu nu sarua, urang meunang leupas tina opat jejer ieu pikeun tiap API. Urang nyieun hiji topik lega pikeun sakabéh hirup, hiji topik lega pikeun sakabéh pementasan sarta ngan nempatkeun sagalana aya. Graylog scrapes sadayana ieu kaluar dina paralel.
Patarosan: Naha urang peryogi dukun ieu nganggo soket? Naha anjeun nyobian nganggo supir log syslog pikeun wadah?
jawaban: Dina waktos urang naroskeun patarosan ieu, hubungan urang sareng docker éta tegang. Éta docker 1.0 atanapi 0.9. Docker sorangan aneh. Bréh, lamun ogé nyorong log kana eta ... Kuring boga kacurigaan unverified yén éta ngaliwatan sagala log ngaliwatan sorangan, ngaliwatan daemon docker. Lamun hiji API mana gélo, lajeng sesa API nyangkut dina kanyataan yén maranéhna teu bisa ngirim stdout na stderr. Kuring henteu terang dimana ieu bakal ngakibatkeun. Kuring boga kacurigaan dina tingkat rarasaan nu teu kudu make supir syslog Docker di tempat ieu. Departemén tés fungsional urang gaduh klaster Graylog sorangan sareng log. Aranjeunna nganggo supir log Docker sareng sadayana sigana aya. Tapi aranjeunna langsung nyerat GELF ka Graylog. Dina waktos urang ngamimitian sadayana ieu, urang ngan ukur peryogi éta damel. Panginten engké, nalika aya anu sumping sareng nyarios yén éta parantos damel saé salami saratus taun, urang badé nyobian.
Patarosan: Anjeun ngalakukeun pangiriman antara puseur data maké rsyslog. Naha henteu Kafka?
jawaban: Urang duaan nyatana. Pikeun dua alesan. Upami saluranna tos maot, maka sadaya log urang, bahkan dina bentuk anu dikomprés, moal ngorondang kana éta. Sareng Kafka ngamungkinkeun anjeun ngan saukur kaleungitan aranjeunna dina prosésna. Ieu kumaha urang nyingkirkeun log ieu macét. Kami ngan ukur nganggo Kafka langsung dina hal ieu. Upami urang gaduh saluran anu saé sareng hoyong ngabebaskeunana, maka kami nganggo rsyslog na. Tapi dina kanyataanana, anjeun tiasa ngonpigurasikeunana supados éta nyalira nyalira anu henteu pas. Di momen, urang ngan ngagunakeun pangiriman rsyslog langsung wae, sarta Kafka wae.
sumber: www.habr.com