Усім прывітанне, мяне клічуць Аляксандр, я працую ў ЦІАН інжынерам і займаюся сістэмным адміністраваннем і аўтаматызацыяй інфраструктурных працэсаў. У каментарах да адной з мінулых артыкулаў нас папыталі распавесці, адкуль мы бярэм 4 ТБ логаў у дзень і што з імі які робіцца. Так, логаў у нас шмат, і для іх апрацоўкі створаны асобны інфраструктурны кластар, які дае магчымасць нам аператыўна вырашаць праблемы. У гэтым артыкуле я распавяду пра тое, як мы за год адаптавалі яго пад працу з увесь час які расце струменем дадзеных.
З чаго мы пачыналі
Апошнія некалькі гадоў нагрузка на cian.ru расла вельмі хутка, і да трэцяга квартала 2018 года наведвальнасць рэсурсу дасягнула 11.2/40 млн унікальных карыстальнікаў у месяц. У той час у крытычныя моманты мы гублялі да XNUMX% логаў, з-за чаго не маглі аператыўна разбірацца з інцыдэнтамі і марнавалі вельмі шмат часу і сіл на іх вырашэнне. Яшчэ мы часта не маглі знайсці прычыну праблемы, і яна паўтаралася праз нейкі час. Гэта было пекла, з якім трэба было нешта рабіць.
На той момант для захоўвання логаў мы выкарыстоўвалі кластар з 10 дата-нод з ElasticSearch версіі 5.5.2 з тыпавымі наладамі індэксаў. Яго ўкаранілі больш за год таму як папулярнае і даступнае рашэнне: тады паток логаў быў не такі вялікі, сэнсу прыдумляць нестандартныя канфігурацыі не было.
Апрацоўку ўваходных логаў забяспечваў Logstash на розных партах на пяці каардынатарах ElasticSearch. Адзін індэкс, незалежна ад памеру, складаўся з пяці шардаў. Была арганізавана пагадзінная і дзённая ратацыя, у выніку кожную гадзіну ў кластары з'яўлялася каля 100 новых шардаў. Пакуль логаў было не вельмі шмат, кластар спраўляўся і на яго наладах ніхто не засяроджваў увагі.
Праблемы хуткага росту
Аб'ём згенераваных логаў рос вельмі хутка, бо сябар на сябра наклаліся два працэсу. З аднаго боку, карыстачоў у сэрвісу станавілася ўсё больш. А з другога, мы пачалі актыўна пераходзіць на мікрасэрвісную архітэктуру, распілоўваючы нашыя старыя маналіты на C# і Python. Некалькі дзясяткаў новых мікрасэрвісаў, якія замянялі часткі маналіта, генеравалі прыкметна больш логаў для інфраструктурнага кластара.
Менавіта маштабаванне і прывяло нас да таго, што кластар стаў практычна некіравальным. Калі логі пачалі паступаць з хуткасцю 20 тыс. паведамленняў у секунду, частая бескарысная ратацыя павялічыла колькасць шардаў да 6 тысяч, а на адну ноду прыпадала больш за 600 шардаў.
Гэта прыводзіла да праблем з вылучэннем аператыўнай памяці, а пры падзенні ноды пачынаўся адначасовы пераезд усіх шардаў, які памнажае трафік і нагружае астатнія ноды, што рабіла практычна немагчымай запіс дадзеных у кластар. І ў гэты перыяд мы заставаліся без логаў. А пры праблеме з серверам мы гублялі 1/10 кластара ў прынцыпе. Дадавала складанасцяў вялікая колькасць індэксаў маленькага памеру.
Без логаў мы не разумелі прычын інцыдэнту і маглі рана ці позна наступіць на тыя ж граблі зноў, а ў ідэалогіі нашай каманды гэта было недапушчальна, бо ўсе механізмы працы ў нас заточаныя якраз на адваротнае - ніколі не паўтараць адны і тыя ж праблемы. Для гэтага нам быў патрэбен поўны аб'ём логаў і дастаўка іх практычна ў рэжыме рэальнага часу, бо каманда дзяжурных інжынераў маніторыла алерты не толькі ад метрык, але і ад логаў. Для разумення маштабаў праблемы – на той момант агульны аб'ём логаў складаў каля 2 Тб у суткі.
Мы паставілі задачу - цалкам выключыць страту логаў і скараціць час іх дастаўкі ў кластар ELK максімум да 15 хвілін падчас форс-мажораў (на гэтую лічбу ў далейшым мы абапіраліся, як на ўнутраны KPI).
Новы механізм ратацыі і hot-warm ноды
Пераўтварэнне кластара мы пачалі з абнаўлення версіі ElasticSearch з 5.5.2 на 6.4.3. У нас у чарговы раз лёг кластар 5 версіі, і мы вырашылі яго пагасіць і цалкам абнавіць - логаў-то ўсё роўна няма. Так што гэты пераход мы здзейснілі ўсяго за пару гадзін.
Самым маштабным пераўтварэннем на гэтым этапе стала ўкараненне на трох нодах з каардынатарам у якасці прамежкавага буфера Apache Kafka. Брокер паведамленняў пазбавіў нас ад страты логаў падчас праблем з ElasticSearch. Адначасова мы дадалі ў кластар 2 ноды і перайшлі на hot-warm архітэктуру з трыма гарачымі нодамі, расстаўленымі ў розных стойках у дата-цэнтры. На іх мы па масцы перанакіравалі логі, якія нельга губляць ні ў якім разе - nginx, а таксама логі памылак прыкладанняў. На астатнія ноды сыходзілі мінорныя логі - debug, warning і т. п., а таксама праз 24 гадзіны пераязджалі "важныя" логі з "гарачых" нод.
Каб не павялічваць колькасць азначнікаў малога памеру, мы перайшлі з ратацыі па часе на механізм rollover. На форумах было шмат інфармацыі аб тым, што ратацыя па памеры індэкса вельмі ненадзейная, таму мы вырашылі выкарыстоўваць ратацыю па колькасці дакументаў у індэксе. Мы прааналізавалі кожны індэкс і зафіксавалі колькасць дакументаў, пасля якога мусіць спрацоўваць ратацыя. Такім чынам мы дасягнулі аптымальнага памеру шарда - не больш за 50 Гб.
Аптымізацыя кластара
Аднак цалкам праблем мы не пазбавіліся. На жаль, усё роўна з'яўляліся маленькія індэксы: яны не дасягалі зададзенага аб'ёму, не раціраваліся і выдаляліся глабальнай ачысткай індэксаў старэйшых за тры дні, так як мы прыбралі ратацыю па даце. Гэта прыводзіла да страты дадзеных з-за таго, што азначнік з кластара знікаў цалкам, а спроба запісу ў неіснуючы азначнік ламала логіку curator'а, які мы выкарысталі для кіравання. Alias для запісу пераўтвараўся ў азначнік і ламаў логіку rollover'а, выклікаючы бескантрольны рост некаторых азначнікаў да 600 Гб.
Напрыклад, для канфіга ратацыі:
с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
Пры адсутнасці rollover alias узнікала памылка:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Рашэнне гэтай праблемы мы пакінулі на наступную ітэрацыю і заняліся іншым пытаннем: перайшлі на pull логіку працы Logstash, які займаецца апрацоўкай уваходных логаў (выдаленнем лішняй інфармацыі і ўзбагачэннем). Мы змясцілі яго ў docker, які запускаем праз docker-compose, тамака жа размясцілі logstash-exporter, які аддае метрыкі ў Prometheus для аператыўнага маніторынгу струменя логаў. Так мы далі сабе магчымасць плыўна змяняць колькасць інстансаў logstash, якія адказваюць за апрацоўку кожнага віду логаў.
Пакуль мы ўдасканальвалі кластар, наведвальнасць cian.ru вырасла да 12,8 унікальных карыстальнікаў у месяц. У выніку атрымалася, што нашы пераўтварэнні крыху не паспявалі за зменамі на прадакшэне, і мы сутыкнуліся з тым, што «цёплыя» ноды не спраўляліся з нагрузкай і тармазілі ўсю дастаўку логаў. Гарачыя дадзеныя мы атрымлівалі без збояў, але ў дастаўку астатніх прыходзілася ўмешвацца і рабіць ручны rollover, каб раўнамерна размяркоўваць азначнікі.
Пры гэтым маштабаванне і змена налад інстансаў logstash у кластары ўскладнялася тым, што гэта быў лакальны docker-compose, і ўсе дзеянні выконваліся рукамі (для дадання новых канцоў неабходна было рукамі мінуць па ўсіх серверах і ўсюды зрабіць docker-compose up -d).
Пераразмеркаванне логаў
У верасні гэтага года мы ўсё яшчэ працягвалі распілоўваць маналіт, нагрузка на кластар узрастала, а струмень логаў набліжаўся да 30 тысяч паведамленняў у секунду.
Наступную ітэрацыю мы пачалі з абнаўлення жалеза. З пяці каардынатараў мы перайшлі на тры, замянілі дата-ноды і выйгралі па грошах і па аб'ёме сховішча. Для нод мы выкарыстоўваем дзве канфігурацыі:
- Для гарачых нод: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 для Hot1 і 3 для Hot2).
- Для цёплых нод: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
На гэтай ітэрацыі мы вынеслі азначнік з access-логамі мікрасэрвісаў, які займае гэтулькі ж месцы, колькі логі франтавых nginx, у другую групу з трох «гарачых» нод. Дадзеныя на "гарачых" нодах мы зараз захоўваем 20 гадзін, а затым пераносім на "цёплыя" да астатніх логаў.
Праблему знікнення маленькіх індэксаў мы вырашылі пераналадкай іх ратацыі. Цяпер індэксы раціруюцца ў любым выпадку кожныя 23 гадзіны, нават калі там мала звестак. Гэта крыху павялічыла колькасць шардов (іх стала каля 800), але з пункту гледжання прадукцыйнасці кластара гэта памяркоўна.
У выніку ў кластары атрымалася шэсць "гарачых" і ўсяго чатыры "цёплых" ноды. Гэта выклікае невялікую затрымку на запытах па вялікім інтэрвалам часу, але павелічэнне колькасці нод у будучыні вырашыць гэтую праблему.
У гэтай ітэрацыі выправілі і праблему адсутнасці паўаўтаматычнага маштабавання. Для гэтага мы разгарнулі інфраструктурны Nomad кластар аналагічны таму, што ўжо разгорнуты ў нас на прадакшэн. Пакуль колькасць Logstash аўтаматычна не змяняецца ў залежнасці ад нагрузкі, але мы прыйдзем і да гэтага.
Планы на будучыню
Рэалізаваная канфігурацыя выдатна маштабуецца, і цяпер мы захоўваем 13,3 Тб дадзеных – усе логі за 4 сутак, што неабходна для экстранага разбору алертаў. Частку логаў мы пераўтворым у метрыкі, якія складаем у Graphite. Каб аблегчыць працу інжынераў, у нас ёсць метрыкі для інфраструктурнага кластара і скрыпты для паўаўтаматычнага папраўкі тыповых праблем. Пасля павелічэння колькасці дата-нод, якое запланавана на наступны год, мы пяройдзем на захоўванне даных з 4 да 7 дзён. Гэтага будзе дастаткова для аператыўнай работы, таму што мы заўсёды стараемся расследаваць інцыдэнты як мага хутчэй, а для доўгатэрміновых расследаванняў ёсць дадзеныя тэлеметрыі.
У кастрычніку 2019 года наведвальнасць cian.ru вырасла ўжо да 15,3 унікальных карыстальнікаў у месяц. Гэта стала сур'ёзнай праверкай архітэктурнага рашэння па дастаўцы логаў.
Цяпер мы рыхтуемся абнавіць ElasticSearch да версіі 7. Праўда, для гэтага прыйдзецца абнаўляць mapping шматлікіх азначнікаў у ElasticSearch, т. да. яны пераехалі з версіі 5.5 і былі абвешчаныя як deprecated у 6 версіі (у 7 версіі іх проста няма). А гэта значыць, што ў працэсе абнаўлення абавязкова будзе які-небудзь форс-мажор, які на час вырашэння пытання пакіне нас без логаў. З 7 версіі больш за ўсё чакаем Kibana з палепшаным інтэрфейсам і новымі фільтрамі.
Асноўнай мэты мы дасягнулі: перасталі губляць логі і скарацілі час прастою інфраструктурнага кластара з 2-3 падзенняў у тыдзень да пары гадзін сэрвісных работ у месяц. Уся гэтая праца на прадакшэне амаль незаўважная. Аднак зараз мы можам дакладна вызначыць, што адбываецца з нашым сэрвісам, можам хутка рабіць гэта ў спакойным рэжыме і не перажываць, што логі згубяцца. Увогуле, мы задаволеныя, шчаслівыя і рыхтуемся да новых подзвігаў, пра якія раскажам пазней.
Крыніца: habr.com