Ang mga log ay isang mahalagang bahagi ng system, na nagbibigay-daan sa iyong maunawaan na ito ay gumagana (o hindi gumagana) gaya ng inaasahan. Sa isang microservice architecture, ang pagtatrabaho sa mga log ay nagiging isang hiwalay na disiplina para sa isang espesyal na Olympiad. Isang grupo ng mga tanong ang kailangang malutas nang sabay-sabay:
- kung paano magsulat ng mga log mula sa isang application;
- kung saan magsulat ng mga tala;
- kung paano maghatid ng mga log para sa imbakan at pagproseso;
- paano magproseso at mag-imbak ng mga log.
Ang paggamit ng kasalukuyang popular na mga teknolohiya ng containerization ay nagdaragdag ng buhangin sa ibabaw ng rake sa larangan ng mga opsyon para sa paglutas ng problema.
Ito mismo ang tungkol sa transcript ng ulat ni Yuri Bushmelev na "Map of rake sa larangan ng pagkolekta at paghahatid ng mga log".
Para sa sinumang interesado, mangyaring tingnan ang pusa.
Ang pangalan ko ay Yuri Bushmelev. Nagtatrabaho ako sa Lazada. Ngayon ay pag-uusapan ko kung paano namin ginawa ang aming mga log, kung paano namin nakolekta ang mga ito, at kung ano ang aming isinusulat doon.
saan tayo galing? Sino tayo? Ang Lazada ay ang No. 1 online retailer sa anim na bansa sa Southeast Asia. Ang lahat ng mga bansang ito ay ipinamamahagi sa aming mga data center. Sa kasalukuyan ay may kabuuang 4 na data center. Bakit ito mahalaga? Dahil ang ilang mga desisyon ay dahil sa ang katunayan na mayroong isang mahinang ugnayan sa pagitan ng mga sentro. Mayroon kaming arkitektura ng microservice. Nagulat ako nang makitang mayroon na kaming 80 microservices. Noong sinimulan ko ang gawain gamit ang mga log, 20 lang ang mga ito. Dagdag pa, mayroong isang medyo malaking piraso ng PHP legacy, na kailangan ko ring pakisamahan at tiisin. Ang lahat ng ito ay kasalukuyang bumubuo ng higit sa 6 na milyong mensahe kada minuto para sa sistema sa kabuuan. Susunod na ipapakita ko kung paano natin sinisikap na mamuhay dito, at kung bakit ganito.
Kailangan mong mabuhay kahit papaano gamit ang 6 na milyong mensaheng ito. Ano ang dapat nating gawin sa kanila? 6 milyong mensahe ang kailangan mo:
- ipadala mula sa app
- tanggapin para sa paghahatid
- ihatid para sa pagsusuri at imbakan.
- pag-aralan
- iimbak ito kahit papaano.
Nang lumitaw ang tatlong milyong mga mensahe, tumingin ako ng halos pareho. Dahil nagsimula kami sa ilang piso lang. Malinaw na ang mga log ng aplikasyon ay nakasulat doon. Halimbawa, hindi ako makakonekta sa database, nakakonekta ako sa database ngunit wala akong mabasa. Ngunit bukod dito, ang bawat isa sa aming mga microservice ay nagsusulat din ng access log. Ang bawat kahilingan na dumarating sa microservice ay naitala sa log. Bakit natin ito ginagawa? Gusto ng mga developer na ma-trace. Ang bawat log ng pag-access ay naglalaman ng isang traceid field, kung saan ginagamit ng isang espesyal na interface ang buong chain at ipinapakita nang maganda ang bakas. Ipinapakita ng bakas kung paano napunta ang kahilingan, at nakakatulong ito sa aming mga developer na mabilis na harapin ang anumang hindi natukoy na basura.
Paano mamuhay dito? Ngayon ay ilalarawan ko nang maikli ang larangan ng mga pagpipilian - kung paano karaniwang nalutas ang problemang ito. Paano malutas ang problema sa pagkolekta, pagpapadala at pag-iimbak ng mga log.
Paano magsulat mula sa isang application? Malinaw na may iba't ibang paraan. Sa partikular, mayroong pinakamahusay na kasanayan, tulad ng sinasabi sa amin ng aming mga naka-istilong kasama. Mayroong dalawang uri ng lumang paaralan, tulad ng sinabi sa amin ng aming mga lolo. May iba pang paraan.
Ang sitwasyon sa pagkolekta ng mga log ay humigit-kumulang pareho. Walang maraming mga pagpipilian para sa paglutas ng partikular na bahaging ito. Mas marami na sila, pero hindi pa ganoon karami.
Ngunit sa paghahatid at kasunod na pagsusuri, ang bilang ng mga pagkakaiba-iba ay nagsisimulang sumabog. Hindi ko ilalarawan ang bawat opsyon ngayon. Sa palagay ko ang mga pangunahing pagpipilian ay kilala ng lahat na interesado sa paksa.
Ipapakita ko sa iyo kung paano namin ito ginawa sa Lazada, at kung paano talaga nagsimula ang lahat.
Isang taon na ang nakalilipas pumunta ako sa Lazada at ipinadala sa isang proyekto tungkol sa mga log. Ito ay isang bagay na tulad nito. Ang log ng aplikasyon ay isinulat sa stdout at stderr. Ang lahat ay ginawa sa isang naka-istilong paraan. Ngunit pagkatapos ay itinapon ito ng mga developer mula sa mga karaniwang daloy, at pagkatapos ay sa anumang paraan malalaman ito ng mga espesyalista sa imprastraktura. Sa pagitan ng mga espesyalista sa imprastraktura at mga developer, mayroon ding mga naglabas na nagsabing: "uh... okay, balutin lang natin sila sa isang file na may shell, at iyon na." At dahil ang lahat ng ito ay nasa isang lalagyan, ibinalot nila ito sa mismong lalagyan, minarkahan ang katalogo sa loob at inilagay doon. Sa tingin ko medyo halata sa lahat kung ano ang nagmula rito.
Tumingin pa tayo ng kaunti sa ngayon. Paano namin naihatid ang mga log na ito? May pumili ng td-agent, na talagang matatas, ngunit hindi masyadong matatas. Hindi ko pa rin naiintindihan ang relasyon sa pagitan ng dalawang proyektong ito, ngunit tila sila ay tungkol sa parehong bagay. At ang matatas na ito, na nakasulat sa Ruby, ay nagbasa ng mga log file, na-parse ang mga ito sa JSON gamit ang ilang uri ng regularidad. Pagkatapos ay ipinadala ko sila sa Kafka. Bukod dito, sa Kafka mayroon kaming 4 na magkakahiwalay na paksa para sa bawat API. Bakit 4? Dahil may live, may staging, at dahil may stdout at stderr. Ginagawa sila ng mga developer, at dapat silang likhain ng mga developer ng imprastraktura sa Kafka. Bukod dito, ang Kafka ay kontrolado ng ibang departamento. Samakatuwid, kinailangan na lumikha ng isang tiket upang makagawa sila ng 4 na paksa para sa bawat api. Nakalimutan ito ng lahat. Sa pangkalahatan, nagkaroon ng basura at kaguluhan.
Ano ang susunod na ginawa namin dito? Ipinadala namin ito sa Kafka. Pagkatapos ang kalahati ng mga troso mula sa Kafka ay lumipad patungong Logstash. Ang iba pang kalahati ng mga log ay hinati. Ang ilan ay lumipad sa isang Graylog, ang ilan sa isa pang Graylog. Bilang resulta, ang lahat ng ito ay napunta sa isang Elasticsearch cluster. Ibig sabihin, doon natapos ang lahat ng kaguluhang ito. Wag mong gawin yan!
Ito ang hitsura kung titingnan mo ito mula sa itaas. Wag mong gawin yan! Dito ang mga lugar ng problema ay agad na minarkahan ng mga numero. Mayroong talagang higit pa sa kanila, ngunit ang 6 ay talagang may problema na kailangang gawin tungkol sa. Sasabihin ko sa iyo ang tungkol sa kanila nang hiwalay ngayon.
Dito (1,2,3) nagsusulat kami ng mga file at, ayon dito, mayroong tatlong rake dito nang sabay-sabay.
Ang una (1) ay kailangan nating isulat ang mga ito sa isang lugar. Hindi palaging kanais-nais na bigyan ang API ng kakayahang magsulat nang direkta sa isang file. Ito ay kanais-nais na ang API ay ihiwalay sa isang lalagyan, o mas mabuti pa, na ito ay read-only. Ako ay isang tagapangasiwa ng system, kaya mayroon akong bahagyang alternatibong pananaw sa mga bagay na ito.
Ang pangalawang punto (2,3) ay marami kaming mga kahilingang dumarating sa API. Ang API ay nagsusulat ng maraming data sa isang file. Ang mga file ay lumalaki. Kailangan natin silang paikutin. Dahil kung hindi, hindi ka makakapag-stock sa anumang mga disk doon. Ang pag-rotate sa mga ito ay masama dahil ang mga ito ay ginawa sa pamamagitan ng pag-redirect sa pamamagitan ng shell sa direktoryo. Walang paraan na maaari nating baguhin ito. Hindi mo masasabi sa application na muling buksan ang mga handle. Dahil titingnan ka ng mga developer na parang tanga: “Anong mga deskriptor? Karaniwan kaming sumusulat sa stdout." Ang mga developer ng imprastraktura ay gumawa ng copytruncate upang mag-logrotate, na gumagawa lang ng kopya ng file at nag-transcribe ng orihinal. Alinsunod dito, sa pagitan ng mga proseso ng pagkopya na ito, ang puwang sa disk ay karaniwang nauubusan.
(4) Nagkaroon kami ng iba't ibang mga format sa iba't ibang mga API. Sila ay bahagyang naiiba, ngunit ang regexp ay kailangang isulat nang iba. Dahil ang lahat ng ito ay kontrolado ng Puppet, mayroong isang malaking grupo ng mga klase na may sariling mga ipis. Dagdag pa, kadalasan ang td-agent ay maaaring kumain ng memorya, maging tanga, maaari lamang itong magpanggap na ito ay gumagana at walang ginagawa. Mula sa labas ay imposibleng maunawaan na wala siyang ginagawa. At best, mahuhulog siya at may susundo sa kanya mamaya. Mas tiyak, may darating na alerto, at may pupunta at magtataas nito gamit ang kanilang mga kamay.
(6) At ang pinakamaraming basura at basura ay elasticsearch. Dahil ito ay isang lumang bersyon. Wala kasi kaming dedicated masters that time. Nagkaroon kami ng magkakaibang mga log na maaaring mag-overlap ang mga field. Ang iba't ibang mga log mula sa iba't ibang mga application ay maaaring isulat na may parehong mga pangalan ng field, ngunit maaaring may iba't ibang data sa loob. Iyon ay, ang isang log ay may kasamang Integer sa field, halimbawa, antas. Ang isa pang log ay may kasamang String sa level field. Sa kawalan ng static na pagmamapa, ito ay napakagandang bagay. Kung, pagkatapos ng pag-ikot ng index sa elasticsearch, isang mensahe na may string ang unang dumating, pagkatapos ay nabubuhay tayo nang normal. Ngunit kung ang una ay dumating mula sa Integer, ang lahat ng kasunod na mensahe na dumating mula sa String ay itatapon lamang. Dahil hindi tugma ang uri ng field.
Sinimulan naming itanong ang mga tanong na ito. Napagpasyahan naming huwag hanapin ang mga dapat sisihin.
Ngunit may kailangang gawin! Ang malinaw na bagay ay kailangan nating magtatag ng mga pamantayan. Nagkaroon na kami ng ilang pamantayan. Nagsimula kami ng ilang sandali. Sa kabutihang palad, ang isang solong format ng log para sa lahat ng mga API ay naaprubahan na sa oras na iyon. Direkta itong nakasulat sa mga pamantayan para sa pakikipag-ugnayan sa pagitan ng mga serbisyo. Alinsunod dito, ang mga nais makatanggap ng mga log ay dapat na isulat ang mga ito sa format na ito. Kung ang isang tao ay hindi sumulat ng mga log sa format na ito, hindi namin ginagarantiyahan ang anuman.
Susunod, nais kong lumikha ng isang pinag-isang pamantayan para sa mga pamamaraan ng pag-record, paghahatid at pagkolekta ng mga log. Sa totoo lang, kung saan isusulat ang mga ito, at kung paano ihahatid ang mga ito. Ang perpektong sitwasyon ay kapag ang mga proyekto ay gumagamit ng parehong library. Mayroong hiwalay na logging library para sa Go, at isang hiwalay na library para sa PHP. Dapat gamitin ng lahat ng mayroon tayo. Sa ngayon, sasabihin ko na 80 porsiyento tayong matagumpay dito. Ngunit ang ilang mga tao ay patuloy na kumakain ng cacti.
At doon (sa slide) ang "SLA para sa paghahatid ng mga log" ay halos hindi nagsisimulang lumitaw. Hindi pa ito umiiral, ngunit ginagawa namin ito. Dahil napaka-convenient kapag sinabi ng imprastraktura na kung sumulat ka sa ganito at ganoong format sa ganito at ganoong lugar at hindi hihigit sa N mensahe bawat segundo, malamang na ihahatid namin ito sa ganoon at ganoong lugar. Pinapaginhawa nito ang maraming sakit ng ulo. Kung mayroong isang SLA, kung gayon ito ay talagang kahanga-hanga!
Paano natin sinimulang lutasin ang problema? Ang pangunahing problema ay sa td-agent. Hindi malinaw kung saan napunta ang aming mga log. Hinatid ba sila? Pupunta ba sila? Nasaan na ba sila? Samakatuwid, ang unang punto ay nagpasya na palitan ang td-agent. Maikling binalangkas ko ang mga opsyon para sa kung ano ang ipapalit dito.
Fluentd. Una, na-encounter ko siya sa dating trabaho, at panaka-nakang nahulog din siya doon. Pangalawa, ito ay ang parehong bagay, lamang sa profile.
Filebeat. Paano ito naging maginhawa para sa amin? Dahil nasa Go ito, at marami kaming kadalubhasaan sa Go. Alinsunod dito, kung may nangyari, maaari nating idagdag ito para sa ating sarili. Kaya lang hindi namin kinuha. Upang wala nang anumang tukso na simulan itong muling isulat para sa iyong sarili.
Ang malinaw na solusyon para sa system administrator ay ang lahat ng uri ng syslogs sa dami na ito (syslog-ng/rsyslog/nxlog).
O magsulat ng sarili mong bagay, ngunit itinapon namin ito, pati na rin ang filebeat. Kung nagsusulat ka ng isang bagay, mas mahusay na magsulat ng isang bagay na kapaki-pakinabang para sa negosyo. Upang maghatid ng mga log, mas mahusay na kumuha ng isang bagay na handa na.
Samakatuwid, ang pagpili ay talagang bumaba sa pagpili sa pagitan ng syslog-ng at rsyslog. Sumandal ako sa rsyslog dahil lang sa mayroon na kaming mga klase para sa rsyslog sa Puppet, at wala akong nakitang pagkakaiba sa pagitan nila. Ano ang syslog, ano ang syslog. Oo, ang ilan ay may mas masahol na dokumentasyon, ang ilan ay may mas mahusay. Ang isang ito ay maaaring gawin ito sa ganitong paraan, at ang isa ay maaaring gawin ito sa ibang paraan.
At kaunti tungkol sa rsyslog. Una sa lahat, astig kasi marami itong modules. Mayroon itong RainerScript na nababasa ng tao (isang modernong configuration language). Ito ay isang kahanga-hangang bonus na maaari naming tularan ang pag-uugali ng td-agent gamit ang mga karaniwang tool, at walang nagbago para sa mga application. Iyon ay, pinapalitan namin ang td-agent sa rsyslog, at iiwan ang lahat ng iba pa sa ngayon. At agad kaming nakatanggap ng gumaganang paghahatid. Susunod, ang mmnormalize ay isang kahanga-hangang bagay sa rsyslog. Pinapayagan ka nitong mag-parse ng mga log, ngunit hindi gumagamit ng Grok at regexp. Gumagawa ito ng abstract syntax tree. Ito ay nag-parse ng mga log sa halos parehong paraan tulad ng isang compiler na nag-parse ng mga mapagkukunan. Nagbibigay-daan ito sa iyo na magtrabaho nang napakabilis, kumonsumo ng kaunting CPU, at, sa pangkalahatan, ito ay isang talagang cool na bagay. Mayroong isang bungkos ng iba pang mga bonus. Hindi na ako magtatagal sa kanila.
Ang rsyslog ay may maraming iba pang mga kawalan. Ang mga ito ay halos kapareho ng mga bonus. Ang mga pangunahing problema ay kailangan mong malaman kung paano lutuin ito, at kailangan mong piliin ang bersyon.
Napagpasyahan namin na magsusulat kami ng mga log sa isang unix socket. At hindi sa /dev/log, dahil mayroon kaming gulo ng mga log ng system, ang journald ay nasa pipeline na ito. Kaya't sumulat tayo sa isang pasadyang socket. Isasama namin ito sa isang hiwalay na ruleset. Huwag tayong makialam sa kahit ano. Ang lahat ay magiging transparent at mauunawaan. Ganyan talaga ang ginawa namin. Ang direktoryo na may mga socket na ito ay na-standardize at ipinapasa sa lahat ng mga lalagyan. Makikita ng mga lalagyan ang socket na kailangan nila, buksan at sulatan ito.
Bakit hindi isang file? Dahil binabasa ito ng lahat , na sinubukang ipasa ang isang file sa docker, at natuklasan na pagkatapos i-restart ang rsyslog, nagbago ang descriptor ng file, at nawala sa docker ang file na ito. Pinapanatili nitong bukas ang ibang bagay, ngunit hindi ang socket kung saan sila nagsusulat. Napagpasyahan namin na lutasin namin ang problemang ito, at kasabay nito, gagawin namin ang problema sa pagharang.
Ginagawa ng Rsyslog ang mga pagkilos na nakasaad sa slide at nagpapadala ng mga log sa alinman sa relay o Kafka. Sinusundan ni Kafka ang dating daan. Relay - Sinubukan kong gumamit ng purong rsyslog para maghatid ng mga log. Nang walang Message Queue, gamit ang karaniwang rsyslog tool. Talaga, ito ay gumagana.
Ngunit may mga nuances kung paano itulak ang mga ito sa bahaging ito (Logstash/Graylog/ES). Ang bahaging ito (rsyslog-rsyslog) ay ginagamit sa pagitan ng mga data center. Narito ang isang naka-compress na tcp link, na nagbibigay-daan sa amin na makatipid ng bandwidth at, nang naaayon, kahit papaano ay tumataas ang posibilidad na makatanggap kami ng ilang mga log mula sa isa pang data center kapag ang channel ay barado. Dahil mayroon tayong Indonesia, kung saan masama ang lahat. Dito nakasalalay ang patuloy na problema.
Naisip namin kung paano namin talaga masusubaybayan kung gaano kalamang na ang mga log na naitala namin mula sa application ay aabot sa dulo? Nagpasya kaming gumawa ng mga sukatan. Ang rsyslog ay may sariling module ng koleksyon ng istatistika, na naglalaman ng ilang uri ng mga counter. Halimbawa, maaari nitong ipakita sa iyo ang laki ng pila, o kung gaano karaming mga mensahe ang dumating sa ganoon at ganoong pagkilos. May makukuha ka na sa kanila. Dagdag pa, mayroon itong mga custom na counter na maaaring i-configure, at ipapakita nito sa iyo, halimbawa, ang bilang ng mga mensahe na naitala ng ilang API. Susunod, isinulat ko ang rsyslog_exporter sa Python, at ipinadala namin ang lahat sa Prometheus at gumawa ng mga graph. Talagang gusto namin ang mga sukatan ng Graylog, ngunit wala pa kaming oras upang i-set up ang mga ito.
Ano ang mga problema? Ang mga problema ay lumitaw nang matuklasan namin (BIGLANG!) na ang aming mga Live API ay nagsusulat ng 50k mensahe bawat segundo. Isa lang itong Live API na walang staging. At ang Graylog ay nagpapakita lamang sa amin ng 12 libong mga mensahe bawat segundo. At lumitaw ang isang makatwirang tanong: nasaan ang mga labi? Mula sa kung saan namin napagpasyahan na ang Graylog ay hindi maaaring makayanan. Tumingin kami, at, sa katunayan, hindi kinaya ng Graylog at Elasticsearch ang daloy na ito.
Susunod, ang iba pang mga pagtuklas na ginawa namin sa daan.
Ang mga pagsusulat sa socket ay naharang. Paano ito nangyari? Noong gumagamit ako ng rsyslog para sa paghahatid, sa isang punto ang channel sa pagitan ng mga data center ay nasira. Huminto ang paghahatid sa isang lugar, huminto ang paghahatid sa ibang lugar. Ang lahat ng ito ay umabot sa makina na may mga API na sumusulat sa rsyslog socket. May pila doon. Pagkatapos ay napuno ang pila para sa pagsusulat sa unix socket, na bilang default ay 128 packet. At ang susunod na write() sa application ay na-block. Nang tingnan namin ang library na ginagamit namin sa mga application ng Go, nakasulat doon na ang pagsusulat sa socket ay nangyayari sa non-blocking mode. Natitiyak namin na walang nakaharang. Dahil nagbabasa kami na sumulat tungkol dito. Ngunit may isang sandali. Nagkaroon din ng isang walang katapusang loop sa paligid ng tawag na ito, kung saan mayroong patuloy na pagtatangka na itulak ang isang mensahe sa socket. Hindi namin siya napansin. Kinailangan kong isulat muli ang library. Mula noon ay ilang beses na itong nagbago, ngunit ngayon ay inalis na natin ang pagharang sa lahat ng mga subsystem. Samakatuwid, maaari mong ihinto ang rsyslog, at walang mag-crash.
Kinakailangan na subaybayan ang laki ng mga pila, na tumutulong upang maiwasan ang pagtapak sa rake na ito. Una, maaari naming subaybayan kapag nagsimula kaming mawalan ng mga mensahe. Pangalawa, ma-monitor natin na may problema tayo sa delivery.
At isa pang hindi kasiya-siyang sandali - ang pagpapalakas ng 10 beses sa isang arkitektura ng microservice ay napakadali. Wala kaming maraming mga papasok na kahilingan, ngunit dahil sa graph kung saan mas lumalakbay ang mga mensaheng ito, dahil sa mga log ng pag-access, talagang tinataasan namin ang pag-load ng log nang halos sampung beses. Sa kasamaang palad, wala akong oras upang kalkulahin ang eksaktong mga numero, ngunit ang mga microservice ay kung ano sila. Ito ay dapat isaisip. Lumalabas na sa ngayon ang subsystem ng koleksyon ng log ay ang pinaka-load sa Lazada.
Paano malutas ang problema sa elasticsearch? Kung kailangan mong mabilis na makakuha ng mga log sa isang lugar, upang hindi tumakbo sa paligid sa lahat ng mga makina at mangolekta ng mga ito doon, gumamit ng imbakan ng file. Ito ay garantisadong gagana. Maaari itong gawin mula sa anumang server. Kailangan mo lang magdikit ng mga disk doon at mag-install ng syslog. Pagkatapos nito, garantisadong nasa isang lugar ang lahat ng log. Pagkatapos ay maaari mong dahan-dahang i-configure ang elasticsearch, graylog, at iba pa. Ngunit magkakaroon ka na ng lahat ng mga log, at, bukod dito, maaari mong iimbak ang mga ito hangga't mayroong sapat na mga array ng disk.
Sa oras ng aking ulat, ang scheme ay nagsimulang magmukhang ganito. Halos huminto kami sa pagsusulat sa file. Ngayon, malamang, isasara natin ang natitira. Sa mga lokal na makina na nagpapatakbo ng API, hihinto kami sa pagsusulat sa mga file. Una, mayroong imbakan ng file, na gumagana nang mahusay. Pangalawa, ang mga makinang ito ay patuloy na nauubusan ng espasyo, kailangan mong patuloy na subaybayan ito.
Ang bahaging ito na may Logstash at Graylog, talagang umaalis. Samakatuwid, kailangan nating alisin ito. Kailangan mong pumili ng isang bagay.
Nagpasya kaming itapon sina Logstash at Kibana. Kasi may security department tayo. Anong koneksyon? Ang koneksyon ay ang Kibana na walang X-Pack at walang Shield ay hindi nagpapahintulot sa iyo na ibahin ang mga karapatan sa pag-access sa mga log. Kaya naman kinuha namin ang Graylog. Mayroon itong lahat. Hindi ko gusto ito, ngunit ito ay gumagana. Bumili kami ng bagong hardware, nag-install ng sariwang Graylog doon at inilipat ang lahat ng log na may mahigpit na format sa isang hiwalay na Graylog. Nalutas namin ang problema sa iba't ibang uri ng magkaparehong mga field sa organisasyon.
Ano ang eksaktong kasama sa bagong Graylog. Isinulat lang namin ang lahat sa docker. Kumuha kami ng isang grupo ng mga server, naglunsad ng tatlong Kafka instance, 7 Graylog server na bersyon 2.3 (dahil gusto namin ang Elasticsearch na bersyon 5). Ang lahat ng ito ay kinuha sa panahon ng mga pagsalakay mula sa HDD. Nakita namin ang rate ng pag-index na hanggang 100 libong mga mensahe bawat segundo. Nakita namin ang figure na 140 terabytes ng data bawat linggo.
At muli ang kalaykay! Mayroon kaming dalawang benta na paparating. Lumampas kami sa 6 na milyong mensahe. Walang oras si Graylog para nguyain. Kahit papaano kailangan naming mabuhay muli.
Ganito kami nakaligtas. Nagdagdag kami ng ilan pang server at SSD. Sa sandaling ito ay nabubuhay tayo sa ganitong paraan. Ngayon ay ngumunguya na tayo ng 160k messages per second. Hindi pa namin naaabot ang limitasyon, kaya hindi malinaw kung magkano talaga ang makukuha namin dito.
Ito ang aming mga plano para sa hinaharap. Sa mga ito, ang pinakamahalaga ay malamang na mataas ang kakayahang magamit. Wala pa tayo. Maraming mga kotse ang na-configure sa parehong paraan, ngunit sa ngayon ang lahat ay dumadaan sa isang kotse. It takes time to set up failover between them.
Kolektahin ang mga sukatan mula sa Graylog.
Gumawa ng limitasyon sa rate para magkaroon kami ng isang nakakatuwang API na hindi pumapatay sa aming bandwidth at lahat ng iba pa.
At panghuli, pumirma ng ilang uri ng SLA kasama ang mga developer para makapaglingkod kami nang ganito kalaki. Kung magsulat ka pa, pasensya na.
At sumulat ng dokumentasyon.
Sa madaling sabi, ang mga resulta ng lahat ng aming naranasan. Una, mga pamantayan. Pangalawa, ang syslog ay cake. Pangatlo, gumagana ang rsyslog nang eksakto tulad ng nakasulat sa slide. At magpatuloy tayo sa mga tanong.
mga katanungan.
Tanong: Bakit ka nagpasya na hindi kumuha ng... (filebeat?)
Sagutin: Kailangan nating magsulat sa isang file. Hindi ko talaga ginusto. Kapag nagsusulat ang iyong API ng libu-libong mensahe kada segundo, kahit na iikot mo ito minsan sa isang oras, hindi pa rin ito isang opsyon. Maaari kang magsulat sa pipe. Kung saan tinanong ako ng mga developer: "Ano ang mangyayari kung nag-crash ang prosesong sinusulatan namin?" Hindi ko lang mahanap kung ano ang isasagot sa kanila, at sinabing: "Buweno, ok, huwag nating gawin iyon."
Tanong: Bakit hindi ka na lang magsulat ng mga log sa HDFS?
Sagutin: Ito ang susunod na yugto. Pinag-isipan namin ito sa pinakadulo simula, ngunit dahil sa ngayon ay walang mapagkukunan upang gawin ito, nakasalalay ito sa aming pangmatagalang solusyon.
Tanong: Ang format ng column ay magiging mas angkop.
Sagutin: Naiintindihan ko. Kami ay para dito sa parehong mga kamay.
Tanong: Sumulat ka sa rsyslog. Doon maaari mong gamitin ang parehong TCP at UDP. Ngunit kung UDP, kung gayon paano mo ginagarantiyahan ang paghahatid?
Sagutin: Mayroong dalawang puntos. Una, sinasabi ko kaagad sa lahat na hindi namin ginagarantiyahan ang paghahatid ng mga log. Dahil kapag dumating ang mga developer at sinabing: "Magsimula tayong magsulat ng data sa pananalapi doon, at ilalagay mo ito sa isang lugar para sa amin kung sakaling may mangyari," sagot namin sa kanila, "Magaling! Simulan natin ang pag-block sa pagsusulat sa socket, at gawin ito sa mga transaksyon, nang sa gayon ay garantisadong ilalagay mo ito sa socket para sa amin at tiyaking matatanggap namin ito mula sa kabilang panig." At sa sandaling ito, agad na hindi na ito kailangan ng lahat. Kung hindi naman kailangan, anong mga tanong ang dapat nating itanong? Kung ayaw mong garantiyahan ang pagsusulat sa isang socket, bakit kailangan naming garantiyahan ang paghahatid? Ginagawa namin ang aming makakaya. Talagang sinusubukan naming maghatid hangga't maaari at sa pinakamahusay na posibleng paraan, ngunit hindi kami nagbibigay ng 100% na garantiya. Samakatuwid, hindi na kailangang magsulat ng data sa pananalapi doon. Mayroong mga database na may mga transaksyon para dito.
Tanong: Kapag ang API ay bumuo ng ilang mensahe sa log at inilipat ang kontrol sa mga microservice, nakatagpo ka ba ng problema na ang mga mensahe mula sa iba't ibang microservice ay dumating sa maling pagkakasunud-sunod? Nagdudulot ito ng kalituhan.
Sagutin: Normal lang na magkaiba sila ng order. Kailangan mong maging handa para dito. Dahil hindi ginagarantiyahan ng anumang paghahatid ng network ang order, o kailangan mong gumastos ng mga espesyal na mapagkukunan para dito. Kung kukuha kami ng mga imbakan ng file, ang bawat API ay nagse-save ng mga log sa sarili nitong file. O sa halip, mayroong rsyslog na pinag-uuri ang mga ito sa mga direktoryo. Ang bawat API ay may sariling mga log, kung saan maaari kang pumunta at tumingin, at pagkatapos ay maaari mong ihambing ang mga ito gamit ang timestamp sa log na ito. Kung titingnan nila ang Graylog, pagkatapos ay pinagbukud-bukod sila doon ayon sa timestamp. Magiging maayos ang lahat doon.
Tanong: Maaaring mag-iba ang timestamp ayon sa millisecond.
Sagutin: Ang timestamp ay nabuo ng API mismo. Ito ay, sa katunayan, ang buong punto. Mayroon kaming NTP. Bumubuo ang API ng timestamp sa mismong mensahe. Hindi ito idinagdag ng rsyslog.
Tanong: Ang pakikipag-ugnayan sa pagitan ng mga data center ay hindi masyadong malinaw. Sa loob ng data center, malinaw kung paano nakolekta at naproseso ang mga log. Paano nagaganap ang pakikipag-ugnayan sa pagitan ng mga data center? O ang bawat data center ay nabubuhay ng sarili nitong buhay?
Sagutin: Halos. Sa ating bansa, ang bawat bansa ay matatagpuan sa isang data center. Sa ngayon, wala kaming spread out para ang isang bansa ay matatagpuan sa iba't ibang data center. Samakatuwid, hindi na kailangang pagsamahin ang mga ito. Ang bawat sentro ay may Log Relay sa loob. Ito ay isang Rsyslog server. Actually dalawang management machine. Pareho sila ng ugali. Pero sa ngayon, isa lang sa kanila ang dinadaanan ng traffic. Pinagsasama-sama nito ang lahat ng mga log. May disk queue siya kung sakali. Dina-download nito ang mga log at ipinapadala ang mga ito sa central data center (Singapore), kung saan ipinapadala ang mga ito sa Graylog. At ang bawat data center ay may sariling imbakan ng file. Kung sakaling mawala ang aming koneksyon, mayroon kaming lahat ng mga log doon. Mananatili sila doon. Doon sila itatabi.
Tanong: Sa kaso ng mga abnormal na sitwasyon, nakakatanggap ka ba ng mga log mula doon?
Sagutin: Maaari kang pumunta doon (sa imbakan ng file) at tumingin.
Tanong: Paano mo sinusubaybayan na hindi ka nawawalan ng mga log?
Sagutin: Talagang nawawala tayo sa kanila, at sinusubaybayan natin ito. Ang pagsubaybay ay inilunsad noong isang buwan. Ang library na ginagamit ng mga Go API ay may mga sukatan. Mabibilang niya kung ilang beses siyang hindi nagsulat sa isang socket. Sa kasalukuyan ay mayroong isang matalinong heuristic doon. May buffer doon. Sinusubukan nitong magsulat ng mensahe mula dito sa socket. Kung umapaw ang buffer, magsisimula itong i-drop ang mga ito. At binibilang niya kung ilan sa kanila ang nalaglag niya. Kung magsisimulang umapaw ang mga metro doon, malalaman natin ito. Darating din sila ngayon sa prometheus, at makikita mo ang mga graph sa Grafana. Maaari kang mag-set up ng mga alerto. Ngunit hindi pa malinaw kung kanino sila ipapadala.
Tanong: Sa elasticsearch nag-iimbak ka ng mga log na may redundancy. Ilang replika ang mayroon ka?
Sagutin: Isang linya.
Tanong: Isang linya lang ba ito?
Sagutin: Ito ang master at ang replika. Ang data ay naka-imbak sa dalawang kopya.
Tanong: Naayos mo ba kahit papaano ang laki ng buffer ng rsyslog?
Sagutin: Nagsusulat kami ng mga datagram sa isang custom na unix socket. Agad itong nagpapataw ng limitasyon na 128 kilobytes sa amin. Hindi na natin ito maisusulat. Isinulat namin ito sa pamantayan. Ang mga gustong makapasok sa storage ay sumulat ng 128 kilobytes. Ang mga aklatan, bukod dito, ay pinutol, at isang watawat ay inilagay na ang mensahe ay pinutol. Ang aming pamantayan para sa mensahe mismo ay may isang espesyal na field na nagpapakita kung ito ay pinutol habang nagre-record o hindi. Kaya may pagkakataon din tayong subaybayan ang sandaling ito.
Tanong: Nagsusulat ka ba ng sirang JSON?
Sagutin: Ang sirang JSON ay itatapon sa panahon ng relay dahil masyadong malaki ang packet. O itatapon ang Graylog dahil hindi nito ma-parse ang JSON. Ngunit may mga nuances na kailangang ayusin, at karamihan ay nakatali sa rsyslog. Napunan ko na ang ilang mga isyu doon, na kailangan pang pagsikapan.
Tanong: Bakit Kafka? Nasubukan mo na ba ang RabbitMQ? Nabigo ba ang Graylog sa ilalim ng gayong mga pagkarga?
Sagutin: Hindi ito gumagana para sa amin sa Graylog. At ang Graylog ay nahuhubog para sa atin. Problematiko talaga siya. Siya ay isang kakaibang bagay. At, sa katunayan, hindi ito kailangan. Mas gusto kong magsulat mula sa rsyslog nang direkta sa elasticsearch at pagkatapos ay tumingin sa Kibana. Ngunit kailangan nating ayusin ang isyu sa mga security guard. Ito ay isang posibleng opsyon para sa aming pag-unlad, kapag itinapon namin ang Graylog at ginamit ang Kibana. Walang kwenta ang paggamit ng Logstash. Dahil maaari kong gawin ang parehong bagay sa rsyslog. At mayroon itong module para sa pagsulat sa elasticsearch. Sinusubukan naming mamuhay kahit papaano kasama si Graylog. Nagtune up pa kami ng konti. Ngunit mayroon pa ring puwang para sa pagpapabuti.
Tungkol kay Kafka. Ganito ang nangyari sa kasaysayan. Pagdating ko, nandoon na ito, at may sinusulatan na rito. Itinaas lang namin ang aming cluster at inilipat ang mga log dito. Kami ang kanyang pamamahala, alam namin ang kanyang nararamdaman. Tulad ng para sa RabbitMQ... hindi ito gumagana para sa amin sa RabbitMQ. At ang RabbitMQ ay nagkakaroon ng hugis para sa atin. Mayroon kami nito sa produksyon, at may mga problema dito. Ngayon, bago ang pagbebenta, ginayuma nila siya, at magsisimula siyang magtrabaho nang normal. Ngunit bago iyon ay hindi pa ako handa na ilabas ito sa produksyon. May isa pang punto. Maaaring basahin ng Graylog ang bersyong AMQP 0.9, at ang rsyslog ay maaaring magsulat ng bersyong AMQP 1.0. At walang isang solong solusyon sa gitna na maaaring gawin pareho. Ito ay alinman sa isa o sa iba pa. Samakatuwid, sa sandaling ito lamang Kafka. Ngunit mayroon din itong sariling mga nuances. Dahil ang omkafka ng bersyon ng rsyslog na ginagamit namin ay maaaring mawala ang buong buffer ng mensahe na nakuha nito mula sa rsyslog. Sa ngayon ay tiniis namin ito.
Tanong: Ginagamit mo ba ang Kafka dahil mayroon ka na nito? Hindi na ginagamit para sa anumang layunin?
Sagutin: Ang Kafka, na dati, ay ginagamit ng pangkat ng Data Science. Ito ay isang ganap na hiwalay na proyekto, tungkol sa kung saan, sa kasamaang-palad, wala akong masabi. Hindi ko alam. Ito ay pinatakbo ng pangkat ng Data Science. Noong ginawa ang mga log, nagpasya kaming gamitin ito upang hindi mai-install ang sarili namin. Ngayon na-update namin ang Graylog, at nawalan kami ng compatibility dahil mayroon itong lumang bersyon ng Kafka. Kinailangan naming simulan ang aming sarili. Kasabay nito, inalis namin ang apat na paksang ito para sa bawat API. Gumawa kami ng isang malawak na paksa para sa lahat ng live, isang malawak na paksa para sa lahat ng pagtatanghal ng dula at ilagay lang ang lahat doon. Ang lahat ng ito ay tinatanggal ng Graylog nang magkatulad.
Tanong: Bakit kailangan natin itong shamanism na may mga saksakan? Nasubukan mo na bang gamitin ang syslog log driver para sa mga lalagyan?
Sagutin: Sa oras na itinanong namin ang tanong na ito, ang aming relasyon sa docker ay tense. Ito ay docker 1.0 o 0.9. Ang Docker mismo ay kakaiba. Pangalawa, kung itulak mo rin ang mga log dito... Mayroon akong hindi na-verify na hinala na ipinapasa nito ang lahat ng mga log sa pamamagitan ng sarili nito, sa pamamagitan ng docker daemon. Kung ang isang API ay nabaliw, ang iba pang mga API ay natigil sa katotohanang hindi sila makakapagpadala ng stdout at stderr. Hindi ko alam kung saan ito hahantong. Mayroon akong hinala sa antas ng pakiramdam na hindi na kailangang gamitin ang driver ng syslog ng Docker sa lugar na ito. Ang aming functional testing department ay may sariling Graylog cluster na may mga log. Gumagamit sila ng mga driver ng Docker log at tila maayos ang lahat doon. Ngunit agad silang sumulat ng GELF kay Graylog. Sa panahong sinimulan natin ang lahat ng ito, kailangan lang natin itong gumana. Baka mamaya, kapag may dumating at nagsabi na ito ay gumagana nang maayos sa loob ng isang daang taon, susubukan namin.
Tanong: Nagsasagawa ka ng paghahatid sa pagitan ng mga data center gamit ang rsyslog. Bakit hindi si Kafka?
Sagutin: Ginagawa naming pareho ang totoo. Sa dalawang dahilan. Kung ang channel ay ganap na patay, ang lahat ng aming mga log, kahit na sa compressed form, ay hindi mag-crawl sa pamamagitan nito. At pinapayagan ka ng Kafka na mawala ang mga ito sa proseso. Ito ay kung paano namin mapupuksa ang mga log na ito na natigil. Direkta lang naming ginagamit ang Kafka sa kasong ito. Kung mayroon kaming magandang channel at gusto naming palayain ito, gagamitin namin ang kanilang rsyslog. Ngunit sa katunayan, maaari mong i-configure ito upang ito mismo ay bumaba kung ano ang hindi magkasya. Sa ngayon, ginagamit lang namin ang paghahatid ng rsyslog nang direkta sa isang lugar, at Kafka sa isang lugar.
Pinagmulan: www.habr.com