Kumusta sa lahat, ang pangalan ko ay Alexander, nagtatrabaho ako sa CIAN bilang isang inhinyero at ako ay kasangkot sa pangangasiwa ng sistema at automation ng mga proseso ng imprastraktura. Sa mga komento sa isa sa mga nakaraang artikulo, hiniling sa amin na sabihin kung saan kami nakakakuha ng 4 na TB ng mga log bawat araw at kung ano ang ginagawa namin sa kanila. Oo, marami kaming mga log, at isang hiwalay na cluster ng imprastraktura ang ginawa upang iproseso ang mga ito, na nagbibigay-daan sa aming mabilis na malutas ang mga problema. Sa artikulong ito ay pag-uusapan ko kung paano namin ito inangkop sa loob ng isang taon upang gumana sa patuloy na lumalagong daloy ng data.
Saan tayo nagsimula?
Sa nakalipas na ilang taon, napakabilis na lumaki ang load sa cian.ru, at sa ikatlong quarter ng 2018, ang trapiko ng mapagkukunan ay umabot sa 11.2 milyong natatanging user bawat buwan. Sa oras na iyon, sa mga kritikal na sandali nawalan kami ng hanggang 40% ng mga log, kaya hindi namin mabilis na harapin ang mga insidente at gumugol ng maraming oras at pagsisikap sa paglutas ng mga ito. Madalas din naming hindi mahanap ang sanhi ng problema, at mauulit ito pagkatapos ng ilang panahon. Ito ay impiyerno at may dapat gawin tungkol dito.
Noong panahong iyon, gumamit kami ng cluster ng 10 data node na may ElasticSearch na bersyon 5.5.2 na may karaniwang mga setting ng index upang mag-imbak ng mga log. Ipinakilala ito higit sa isang taon na ang nakalilipas bilang isang tanyag at abot-kayang solusyon: kung gayon ang daloy ng mga log ay hindi masyadong malaki, walang punto sa pagbuo ng mga hindi pamantayang pagsasaayos.
Ang pagproseso ng mga papasok na log ay ibinigay ng Logstash sa iba't ibang port sa limang ElasticSearch coordinator. Ang isang index, anuman ang laki, ay binubuo ng limang shards. Isang oras-oras at pang-araw-araw na pag-ikot ang naayos, bilang resulta, humigit-kumulang 100 bagong shards ang lumitaw sa kumpol bawat oras. Bagama't walang masyadong mga log, ang kumpol ay nakayanan nang maayos at walang sinuman ang nagbigay pansin sa mga setting nito.
Ang mga hamon ng mabilis na paglago
Ang dami ng nabuong mga log ay mabilis na lumaki, dahil dalawang proseso ang nag-overlap sa isa't isa. Sa isang banda, ang bilang ng mga gumagamit ng serbisyo ay lumago. Sa kabilang banda, nagsimula kaming aktibong lumipat sa isang arkitektura ng microservice, sa paglalagari ng aming mga lumang monolith sa C# at Python. Ilang dosenang bagong microservice na pumalit sa mga bahagi ng monolith ay nakabuo ng mas maraming log para sa cluster ng imprastraktura.
Ito ay scaling na humantong sa amin sa punto kung saan ang cluster ay naging halos hindi mapangasiwaan. Nang magsimulang dumating ang mga log sa rate na 20 libong mga mensahe bawat segundo, ang madalas na walang silbi na pag-ikot ay nadagdagan ang bilang ng mga shards sa 6 na libo, at mayroong higit sa 600 shards bawat node.
Ito ay humantong sa mga problema sa paglalaan ng RAM, at kapag ang isang node ay nag-crash, ang lahat ng mga shards ay nagsimulang lumipat nang sabay-sabay, na nagpaparami ng trapiko at naglo-load ng iba pang mga node, na naging halos imposible na magsulat ng data sa cluster. At sa panahong ito kami ay naiwan na walang mga tala. At kung may problema sa server, nawalan kami ng 1/10 ng cluster. Nagdagdag ng pagiging kumplikado ang malaking bilang ng maliliit na index.
Kung walang mga log, hindi namin naiintindihan ang mga dahilan para sa insidente at maaga o huli ay maaaring tumapak muli sa parehong rake, at sa ideolohiya ng aming koponan ito ay hindi katanggap-tanggap, dahil ang lahat ng aming mga mekanismo sa trabaho ay idinisenyo upang gawin ang kabaligtaran - hindi na ulitin ang parehong mga problema. Para magawa ito, kailangan namin ang buong dami ng mga log at ang paghahatid ng mga ito nang halos real time, dahil sinusubaybayan ng isang pangkat ng mga on-duty na inhinyero ang mga alerto hindi lamang mula sa mga sukatan, kundi pati na rin mula sa mga log. Upang maunawaan ang laki ng problema, sa oras na iyon ang kabuuang dami ng mga log ay humigit-kumulang 2 TB bawat araw.
Nagtakda kami ng layunin na ganap na maalis ang pagkawala ng mga log at bawasan ang oras ng paghahatid ng mga ito sa cluster ng ELK sa maximum na 15 minuto sa panahon ng force majeure (sa kalaunan ay umasa kami sa figure na ito bilang isang panloob na KPI).
Bagong mekanismo ng pag-ikot at mainit-init na mga node
Sinimulan namin ang cluster conversion sa pamamagitan ng pag-update ng ElasticSearch na bersyon mula 5.5.2 hanggang 6.4.3. Muli ay namatay ang aming bersyon 5 cluster, at nagpasya kaming i-off ito at ganap na i-update ito - wala pa ring mga log. Kaya ginawa namin ang paglipat na ito sa loob lang ng ilang oras.
Ang pinaka-malakihang pagbabago sa yugtong ito ay ang pagpapatupad ng Apache Kafka sa tatlong node na may isang coordinator bilang isang intermediate buffer. Iniligtas kami ng broker ng mensahe mula sa pagkawala ng mga log sa panahon ng mga problema sa ElasticSearch. Kasabay nito, nagdagdag kami ng 2 node sa cluster at lumipat sa isang mainit-init na arkitektura na may tatlong "mainit" na node na matatagpuan sa iba't ibang mga rack sa data center. Nag-redirect kami ng mga log sa kanila gamit ang isang maskara na hindi dapat mawala sa anumang pagkakataon - nginx, pati na rin ang mga log ng error sa application. Ang mga menor de edad na log ay ipinadala sa natitirang mga node - debug, babala, atbp., at pagkatapos ng 24 na oras, ang mga "mahalaga" na log mula sa "mainit" na mga node ay inilipat.
Upang hindi madagdagan ang bilang ng mga maliliit na index, lumipat kami mula sa pag-ikot ng oras patungo sa mekanismo ng rollover. Mayroong maraming impormasyon sa mga forum na ang pag-ikot ayon sa laki ng index ay napaka hindi maaasahan, kaya nagpasya kaming gumamit ng pag-ikot ayon sa bilang ng mga dokumento sa index. Sinuri namin ang bawat index at naitala ang bilang ng mga dokumento pagkatapos kung saan dapat gumana ang pag-ikot. Kaya, naabot namin ang pinakamainam na laki ng shard - hindi hihigit sa 50 GB.
Pag-optimize ng cluster
Gayunpaman, hindi namin ganap na naalis ang mga problema. Sa kasamaang palad, lumitaw pa rin ang maliliit na index: hindi naabot ng mga ito ang tinukoy na volume, hindi na-rotate, at tinanggal sa pamamagitan ng pandaigdigang paglilinis ng mga index na mas matanda sa tatlong araw, dahil inalis namin ang pag-ikot ayon sa petsa. Ito ay humantong sa pagkawala ng data dahil sa ang katunayan na ang index mula sa cluster ay ganap na nawala, at isang pagtatangka na sumulat sa isang hindi umiiral na index ay sinira ang lohika ng curator na ginamit namin para sa pamamahala. Ang alyas para sa pagsulat ay na-convert sa isang index at sinira ang rollover logic, na nagdulot ng hindi makontrol na paglaki ng ilang mga index hanggang sa 600 GB.
Halimbawa, para sa rotation config:
Ρurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Kung walang rollover alias, nagkaroon ng error:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Iniwan namin ang solusyon sa problemang ito para sa susunod na pag-ulit at kumuha ng isa pang isyu: lumipat kami sa pull logic ng Logstash, na nagpoproseso ng mga papasok na log (pag-aalis ng hindi kinakailangang impormasyon at pagpapayaman). Inilagay namin ito sa docker, na inilunsad namin sa pamamagitan ng docker-compose, at naglagay din kami ng logstash-exporter doon, na nagpapadala ng mga sukatan sa Prometheus para sa operational monitoring ng log stream. Sa ganitong paraan, binigyan namin ang aming sarili ng pagkakataon na maayos na baguhin ang bilang ng mga instance ng logstash na responsable para sa pagproseso ng bawat uri ng log.
Habang pinapabuti namin ang cluster, tumaas ang trapiko ng cian.ru sa 12,8 milyong natatanging user bawat buwan. Bilang isang resulta, lumabas na ang aming mga pagbabago ay medyo nasa likod ng mga pagbabago sa produksyon, at nahaharap kami sa katotohanan na ang "mainit" na mga node ay hindi makayanan ang pagkarga at pinabagal ang buong paghahatid ng mga log. Nakatanggap kami ng "mainit" na data nang walang mga pagkabigo, ngunit kinailangan naming makialam sa paghahatid ng iba pa at gumawa ng manu-manong rollover upang pantay na maipamahagi ang mga index.
Kasabay nito, ang pag-scale at pagbabago ng mga setting ng mga instance ng logstash sa cluster ay kumplikado sa katotohanan na ito ay isang lokal na docker-compose, at lahat ng mga aksyon ay ginanap nang manu-mano (upang magdagdag ng mga bagong dulo, kinakailangan na manu-manong dumaan sa lahat ang mga server at docker-compose up -d sa lahat ng dako).
Muling pamamahagi ng log
Noong Setyembre ng taong ito, pinuputol pa rin namin ang monolith, ang pagkarga sa kumpol ay tumataas, at ang daloy ng mga log ay papalapit sa 30 libong mga mensahe bawat segundo.
Sinimulan namin ang susunod na pag-ulit sa isang pag-update ng hardware. Lumipat kami mula sa limang coordinator sa tatlo, pinalitan ang mga node ng data at nanalo sa mga tuntunin ng pera at espasyo sa imbakan. Para sa mga node gumagamit kami ng dalawang configuration:
- Para sa mga "mainit" na node: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 para sa Hot1 at 3 para sa Hot2).
- Para sa mga "mainit" na node: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Sa pag-ulit na ito, inilipat namin ang index na may mga access log ng mga microservice, na tumatagal ng parehong espasyo tulad ng mga front-line nginx log, sa pangalawang pangkat ng tatlong "mainit" na node. Nag-iimbak na kami ngayon ng data sa "mainit" na mga node sa loob ng 20 oras, at pagkatapos ay ilipat ang mga ito sa "mainit" na mga node sa iba pang mga log.
Nalutas namin ang problema ng mga maliliit na index na nawawala sa pamamagitan ng muling pagsasaayos ng kanilang pag-ikot. Ngayon ang mga index ay iniikot tuwing 23 oras sa anumang kaso, kahit na mayroong maliit na data doon. Ito ay bahagyang nadagdagan ang bilang ng mga shards (mayroong mga 800 sa kanila), ngunit mula sa punto ng view ng pagganap ng kumpol ito ay matitiis.
Bilang resulta, mayroong anim na "mainit" at apat na "mainit" na node lamang sa kumpol. Nagdudulot ito ng bahagyang pagkaantala sa mga kahilingan sa mahabang panahon, ngunit ang pagdaragdag ng bilang ng mga node sa hinaharap ay malulutas ang problemang ito.
Inayos din ng pag-ulit na ito ang problema ng kakulangan ng semi-awtomatikong pag-scale. Para magawa ito, nag-deploy kami ng isang cluster ng imprastraktura ng Nomad - katulad ng na-deploy na namin sa produksyon. Sa ngayon, ang halaga ng Logstash ay hindi awtomatikong nagbabago depende sa pagkarga, ngunit darating tayo dito.
ΠΠ»Π°Π½Ρ Π½Π° Π±ΡΠ΄ΡΡΠ΅Π΅
Ang ipinatupad na configuration scale ay perpekto, at ngayon ay nag-iimbak kami ng 13,3 TB ng data - lahat ng mga log sa loob ng 4 na araw, na kinakailangan para sa emergency na pagsusuri ng mga alerto. Kino-convert namin ang ilan sa mga log sa mga sukatan, na idinaragdag namin sa Graphite. Upang gawing mas madali ang gawain ng mga inhinyero, mayroon kaming mga sukatan para sa cluster ng imprastraktura at mga script para sa semi-awtomatikong pag-aayos ng mga karaniwang problema. Pagkatapos madagdagan ang bilang ng mga node ng data, na pinlano para sa susunod na taon, lilipat kami sa imbakan ng data mula 4 hanggang 7 araw. Sapat na ito para sa gawaing pagpapatakbo, dahil palagi naming sinisikap na siyasatin ang mga insidente sa lalong madaling panahon, at para sa pangmatagalang pagsisiyasat ay mayroong data ng telemetry.
Noong Oktubre 2019, tumaas ang trapiko ng cian.ru sa 15,3 milyong natatanging user bawat buwan. Ito ay naging isang seryosong pagsubok ng solusyon sa arkitektura para sa paghahatid ng mga log.
Ngayon ay naghahanda kaming i-update ang ElasticSearch sa bersyon 7. Gayunpaman, para dito kailangan naming i-update ang pagmamapa ng maraming mga index sa ElasticSearch, dahil lumipat sila mula sa bersyon 5.5 at idineklara bilang hindi na ginagamit sa bersyon 6 (wala lang sila sa bersyon 7). Nangangahulugan ito na sa panahon ng proseso ng pag-update ay tiyak na magkakaroon ng ilang uri ng force majeure, na mag-iiwan sa amin na walang mga log habang naresolba ang isyu. Sa bersyon 7, pinakahihintay namin ang Kibana na may pinahusay na interface at mga bagong filter.
Naabot namin ang aming pangunahing layunin: huminto kami sa pagkawala ng mga log at binawasan ang downtime ng cluster ng imprastraktura mula 2-3 pag-crash bawat linggo hanggang sa ilang oras ng maintenance work bawat buwan. Ang lahat ng gawaing ito sa produksyon ay halos hindi nakikita. Gayunpaman, ngayon ay matutukoy na namin kung ano mismo ang nangyayari sa aming serbisyo, mabilis naming magagawa ito sa isang tahimik na mode at huwag mag-alala na ang mga log ay mawawala. Sa pangkalahatan, kami ay nasisiyahan, masaya at naghahanda para sa mga bagong pagsasamantala, na pag-uusapan natin mamaya.
Pinagmulan: www.habr.com