Логі - важная частка сістэмы, якая дазваляе зразумець, што яна працуе (або не працуе), як чакаецца. Ва ўмовах мікрасэрвіснай архітэктуры праца з логамі становіцца асобнай дысцыплінай спецыяльнай алімпіяды. Трэба вырашыць адразу кучу пытанняў:
- як пісаць логі з прыкладання;
- куды пісаць логі;
- як дастаўляць логі для захоўвання і апрацоўкі;
- як апрацоўваць і захоўваць логі.
Ужыванне папулярных цяпер тэхналогій кантэйнерызацыі дадае пясочка па-над граблямі на поле варыянтаў рашэння задачы.
Якраз пра гэта расшыфроўка дакладу Юрыя Бушмялёва «Карта грабляў на поле збору і дастаўкі логаў»
Каму цікава, прашу пад кат.
Мяне клічуць Юры Бушмялёў. Я працую ў Lazada. Я сёння буду расказваць пра тое, як мы рабілі нашы логі, як мы іх збіралі, і што мы туды пішам.
Адкуль мы? Хто мы такія? Lazada - гэта інтэрнэт-крама №1 у шасці краінах Паўднёва-Усходняй Азіі. Усе гэтыя краіны ў нас размеркаваны па дата-цэнтрах. Усяго дата-цэнтраў зараз 4. Чаму гэта важна? Бо некаторыя рашэнні былі абумоўлены тым, што паміж цэнтрамі ёсць вельмі слабы лінк. У нас мікрасэрвісная архітэктура. Я здзівіўся, выявіўшы, што ў нас ужо 80 мікрасэрвісаў. Калі я пачынаў задачу з логамі, іх было ўсяго 20. Плюс ёсць даволі вялікі кавалак PHP legacy, з якім таксама даводзіцца жыць і мірыцца. Усё гэта генеруе нам на дадзены момант больш за 6 мільёнаў паведамленняў у хвіліну па сістэме ў цэлым. Далей я буду паказваць, як мы з гэтым спрабуем жыць і чаму гэта так.
З гэтымі 6 мільёнамі паведамленняў трэба неяк жыць. Што мы з імі мусім зрабіць? 6 мільёнаў паведамленняў, якія трэба:
- адправіць з прыкладання
- прыняць для дастаўкі
- даставіць для аналізу і захоўвання.
- прааналізаваць
- неяк захоўваць.
Калі з'явілася тры мільёны паведамленняў, у мяне быў прыкладна такі ж выгляд. Бо мы пачыналі з нейкіх капеек. Зразумела, што туды пішуцца логі дадаткаў. Напрыклад, не змог падключыцца да базы даных, змог падключыцца да базы даных, але не змог нешта прачытаць. Але акрамя гэтага, кожны наш мікрасэрвіс піша яшчэ і access-лог. Кожны запыт, які прыляцеў на мікрасэрвіс, падае ў лог. Навошта мы гэта які робіцца? Распрацоўнікі жадаюць мець магчымасць трэйсінгу. У кожным access-логу ляжыць поле traceid, па якім далей спецыяльны інтэрфейс раскручвае ўвесь ланцужок і прыгожа паказвае трэйс. Трэйс паказвае, як праходзіў запыт, і гэта дапамагае нашым распрацоўнікам хутчэй спраўляцца са ўсякай неапазнанай бздурой.
Як з гэтым жыць? Цяпер я коратка раскажу поле варыянтаў — як увогуле гэтая праблема вырашаецца. Як рашаць задачу збору, перадачы і захоўвання логаў.
Як пісаць з прыкладання? Зразумела, ёсць розныя спосабы. У прыватнасці, ёсць best practice, як нам расказваюць модныя таварышы. Ёсць old school у двух відах, як расказвалі дзяды. Ёсць іншыя спосабы.
Са зборам логаў прыкладна такая ж сітуацыя. Варыянтаў вырашэння гэтай канкрэтнай часткі не так шмат. Іх ужо больш, але яшчэ ня так шмат.
А вось з дастаўкай і наступным аналізам - колькасць варыяцый пачынае выбухаць. Апісваць кожны варыянт зараз не буду. Думаю, асноўныя варыянты на слыху ва ўсіх, хто цікавіўся тэмай.
Я пакажу, як мы рабілі гэта ў Lazada, і як уласна ўсё гэта пачыналася.
Год таму я прыйшоў у Лазаду, і мяне адправілі на праект пра логі. Там было прыкладна вось так. Лог з прыкладання пісаўся ў stdout і stderr. Усё зрабілі па-моднаму. Але далей распрацоўшчыкі гэта выкінулі са стандартных патокаў, а далей там як-небудзь спецыялісты па інфраструктуры разбяруцца. Паміж інфраструктурнымі адмыслоўцамі і распрацоўнікамі ёсць яшчэ рэлізэры, якія сказалі: "эээ… ну добра, давайце іх у файл загорнем проста shell-ом, і ўсё". А паколькі ўсё гэта ў кантэйнеры, то загарнулі прамы ў самім кантэйнеры, прамапілі ўнутр каталог і паклалі гэта туды. Мяркую, што ўсім прыкладна відавочна, што з гэтага атрымалася.
Паглядзім пакуль крыху далей. Як мы гэтыя логі дастаўлялі. Хтосьці абраў td-agent, які насамрэч fluentd, але не зусім fluentd. Я так і не зразумеў адносіны гэтых двух праектаў, але яны, быццам бы, аб адным і тым жа. І вось гэты вось fluentd, напісаны на Ruby, чытаў файлы логаў, парсіў іх у JSON па нейкіх рэгулярках. Потым іх адпраўляў у Kafka. Прычым у Kafka на кожную API у нас было 4 асобныя топікі. Чаму 4? Таму што есць live, есць staging, і таму што есць stdout і stderr. Распрацоўнікі іх плодзяць, а інфраструктуршчыкі павінны іх ствараць у Kafka. Прычым, Kafka кантралявалася іншым аддзелам. Таму трэба было ствараць тыкет, каб яны стварылі там 4 топікі на кожны api. Усё пра гэта забываліся. Увогуле быў трэш і чад.
Што мы далей з гэтым рабілі? Мы адпраўлялі гэта ў кафку. Далей з кафкі палова логаў ляцела ў Logstash. Іншая палова логаў дзялілася. Частка ляцела ў адзін Graylog, частка у іншы Graylog. У выніку ўсё гэта ляцела ў адзін кластар Elasticsearch. Гэта значыць, увесь гэты бардак падаў у выніку туды. Дык рабіць не трэба!
Вось так гэта выглядае, калі аддалена зверху паглядзець. Ня трэба так рабіць! Тут вось лічбамі адразу адзначаны праблемныя месцы. Іх насамрэч больш, але 6 - гэта вось прамы зусім праблемныя, з якімі трэба нешта рабіць. Пра іх я зараз асобна раскажу.
Вось тут (1,2,3) у нас пішуцца файлы і, адпаведна, тут адразу тры граблі.
Першае (1) - гэта нам трэба іх кудысьці пісаць. Не заўсёды жадалася бы даваць API магчымасць пісаць прама ў файл. Пажадана, каб API была ізаляваная ў кантэйнеры, а яшчэ лепш - каб яна была read-only. Я — сісадмін, таму ў мяне крыху альтэрнатыўны погляд на гэтыя рэчы.
Другі момант (2,3) - у нас шмат запытаў прыходзіць у API. API піша шмат дадзеных у файл. Файлы растуць. Нам іх трэба ратыраваць. Бо інакш там ніякіх дыскаў не напасешся. Ратаваць іх дрэнна, таму што яны зроблены рэдырэктам праз shell у каталог. Мы ніяк не можам яго адратаваць. Нельга сказаць з дадаткам, каб яно пераадкрыла дэскрыптары. Таму што распрацоўшчыкі на цябе паглядзяць як на дурня: «Якія дэскрыптары? Мы ўвогуле ў stdout пішам». Інфраструктуршчыкі зрабілі copytruncate ў logrotate, які робіць проста копію файла і транкейтыт арыгінал. Адпаведна, паміж гэтымі працэсамі капіявання звычайна і канчаецца месца на дыску.
(4) У нас былі розныя фарматы былі ў розных API. Яны крыху адрозніваліся, але regexp трэба было пісаць розныя. Паколькі ўсё гэта кіравалася Puppet, то там была вялікая вязанка класаў са сваімі прусамі. Плюс яшчэ td-agent большую частку часу мог есці памяць, тупіць, ён мог проста рабіць выгляд, што ён працуе, і нічога не рабіць. Звонку зразумець, што ён нічога не робіць было немагчыма. У лепшым выпадку ён упадзе, і яго хто-небудзь падыме потым. Дакладней, прыляціць alert, і хто-небудзь пойдзе рукамі перападыме.
(6) І самы трэш і чад - гэта быў elasticsearch. Бо гэта была старая версія. Бо ў нас не было выдзеленых майстроў на той момант. У нас былі разнастайныя логі, у якіх палі маглі перасякацца. Розныя логі розных прыкладанняў маглі пісацца з аднолькавымі назвамі палёў, але пры гэтым усярэдзіне маглі быць розныя дадзеныя. Гэта значыць, адзін лог прыходзіць з Integer у поле, напрыклад, level. Іншы лог прыходзіць са String у поле level. У адсутнасць статычнага мапінгу атрымліваецца такая выдатная рэч. Калі пасля ратацыі індэкса ў elasticsearch першым прыляцела паведамленне з радком, то мы жывем нармальна. А калі вось першым прыляцела з Integer, то ўсе наступныя паведамленні, якія прыляцелі са String, проста адкідаюцца. Бо не супадае тып поля.
Мы пачалі задавацца вось гэтымі пытаннямі. Мы вырашылі не шукаць вінаватых.
А вось нешта рабіць трэба! Відавочная рэч - трэба завесці стандарты. Некаторыя стандарты ў нас ужо былі. Некаторыя мы завялі крыху пазней. На шчасце, адзіны фармат логаў для ўсіх API ужо зацвердзілі на той момант. Ён прапісаны проста ў стандарты ўзаемадзеяння сэрвісаў. Адпаведна, тыя, хто жадае атрымліваць логі, павінны пісаць іх у гэтым фармаце. Калі нехта не піша логі ў гэтым фармаце, значыць, мы нічога не гарантуем.
Далей, хацелася б завесці адзіны стандарт на спосабы запісу, дастаўкі і збору логаў. Уласна, куды іх пісаць, і чым іх дастаўляць. Ідэальная сітуацыя - гэта калі ў праектах выкарыстоўваецца адна і тая ж бібліятэка. Вось ёсць асобная бібліятэка лагіравання для Go, ёсць асобная бібліятэка для PHP. Усе хто ў нас ёсць - усе павінны іх выкарыстоўваць. На дадзены момант я б сказаў, што працэнтаў на 80 у нас гэта атрымліваецца. Але некаторыя працягваюць есці кактусы.
І вось тамака вось (на слайдзе) ледзь-ледзь пачынае праступаць «SLA на дастаўку логаў». Яго пакуль няма, але мы над гэтым працуем. Таму што гэта вельмі зручна, калі інфра кажа, што калі вы пішаце ў нейкім фармаце ў такое месца і не больш за N паведамленняў у секунду, то мы гэта з верагоднасцю вось такой даставім туды-то. Гэта здымае кучу галаўнога болю. Калі SLA ёсць, тое гэта прама выдатна!
Як мы пачалі рашаць праблему? Асноўная рабаўня была з td-agent. Было незразумела, куды ў нас дзяюцца логі. Ці дастаўляюцца яны? Ці збіраюцца яны? Дзе яны ўвогуле? Таму першым пунктам было вырашана замяніць td-agent. Варыянты, на што яго замяніць, сцісла я тут накідаў.
Fluentd. Па-першае, я з ім сутыкаўся на папярэдняй працы, і ён тамака таксама перыядычна падаў. Па-другое, гэта тое ж самае, толькі ў профіль.
Filebeat. Чым ён быў зручны для нас? Тым, што ен на Go, а ў нас вялікая экспертыза ў Go. Адпаведна, калі што, мы маглі яго пад сябе неяк дапісаць. Таму мы яго і не ўзялі. Каб нават спакусы ніякай не было пачынаць яго пад сябе перапісваць.
Відавочным рашэннем для сісадміна застаюцца ўсякія сіслогі вось у такой вось колькасці (syslog-ng/rsyslog/nxlog).
Альбо напісаць нешта сваё, але мы гэта адкінулі, роўна як і filebeat. Калі нешта пісаць, то лепш пісаць нешта карыснае для бізнэсу. Для дастаўкі логаў лепш узяць нешта гатовае.
Таму выбар фактычна звёўся да выбару паміж syslog-ng і rsyslog. Схіліўся ў бок rsyslog проста таму, што ў нас у Puppet ужо былі класы для rsyslog, і я не знайшоў паміж імі відавочнай розніцы. Што тамака syslog, што тут syslog. Так, у кагосьці дакументацыя горшая, у кагосьці лепшая. Той умее так, а той - па-іншаму.
І трошкі пра rsyslog. Па-першае, ён клёвы, таму што ў яго ёсць шмат модуляў. У яго чалавека-зразумелы RainerScript (сучасная мова канфігурацыі). Афігенны бонус, што мы маглі яго штатнымі сродкамі сэмуляваць паводзіны td-agent, і для прыкладанняў нічога не памянялася. Гэта значыць, мы мяняем td-agent на rsyslog, а ўсё астатак пакуль не чапаем. І адразу атрымліваем працуючую дастаўку. Далей, mmnormalize - гэта афігенная штука ў rsyslog. Яна дазваляе парсіць логі, але не з дапамогай Grok і regexp. Яна робіць abstract syntax tree. Яна парсіць логі прыкладна, як кампілятар парсіць зыходнікі. Гэта дазваляе працаваць вельмі хутка, жэрці мала CPU, і, наогул, прамы вельмі клёвая штука. Ёсць куча іншых бонусаў. Я пра іх не буду спыняцца.
У rsyslog ёсць яшчэ куча недахопаў. Яны прыкладна такія ж, як і бонусы. Асноўныя праблемы - трэба ўмець яго рыхтаваць, і трэба падбіраць версію.
Мы вырашылі што будзем пісаць лагі ў unix socket. Прычым не ў /dev/log, таму што тамака ў нас каша з сістэмных логаў, тамака journald у гэтым pipeline. Таму давайце пісаць у кастамны сокет. Мы яго прычэпім да асобнага ruleset. Не будзем нічога мяшаць. Будзе ўсё празрыста і зразумела. Так мы і зрабілі. Каталог з гэтымі сокетамі стандартызаваны і пракідваецца ва ўсе кантэйнеры. Кантэйнеры могуць бачыць патрэбны ім socket, адчыняць і пісаць яго.
Чаму не файл? Бо ўсе чыталі , якая спрабавала пракінуць файл у docker, і выяўлялася, што пасля рэстарту rsyslog мяняецца file descriptor, і docker губляе гэты файл. Ён трымае адчыненым нешта іншае, але ўжо не той сокет куды пішуць. Мы вырашылі, што мы абыдзем гэтую праблему, і, заадно, абыдзем праблему блакіроўкі.
Rsyslog робіць дзеянні паказаныя на слайдзе і адпраўляе логі альбо ў рэляў, альбо ў Kafka. Kafka адпавядае старым спосабе. Рэляў - гэта я паспрабаваў выкарыстоўваць чыста rsyslog для дастаўкі логаў. Без Message Queue, стандартнымі сродкамі rsyslog. У прынцыпе, гэта працуе.
Але ёсць нюансы з тым, як запіхваць іх потым у гэтую частку (Logstash/Graylog/ES). Гэтая частка (rsyslog-rsyslog) выкарыстоўваецца паміж датацэнтрамі. Тут compressed tcp link, які дазваляе зэканоміць bandwidth і, адпаведна, неяк павялічыць верагоднасць таго, што мы атрымаем нейкія логі з іншага датацэнтра ва ўмовах, калі канал забіты. Таму што нас ёсць Інданезія, у якой усё дрэнна. Вось там гэтая сталая праблема.
Мы задумаліся над тым як нам уласна праманіторыць, з якой верагоднасцю логі, якія мы запісалі з прыкладання, даязджаюць да таго канца? Мы вырашылі завесці метрыкі. У rsyslog ёсць свой модуль збору статыстыкі, у якім ёсць нейкія лічыльнікі. Напрыклад, ён можа паказаць вам памер чаргі, ці колькі паведамленняў прыйшло ў нейкай action. З іх ужо можна нешта ўзяць. Плюс, у яго ёсць кастамныя лічыльнікі, якія можна наладзіць, і ён будзе вам паказваць, напрыклад, колькасць паведамленняў, які запісала нейкае API. Далей я напісаў rsyslog_exporter на Python, і мы ўсё гэта адправілі ў Prometheus і пабудавалі графікі. Метрыкі Graylog вельмі жадалася, але пакуль мы не паспелі іх наладзіць.
З чым узніклі праблемы? Праблемы ўзніклі з тым, што ў нас выявілася (Раптам!), Што нашы Live API пішуць па 50к паведамленняў у секунду. Гэта толькі Live API без staging. А Graylog нам паказвае толькі 12 тысяч паведамленняў за секунду. І ўзнікла слушнае пытанне, а дзе рэшткі-то? З чаго мы прыйшлі да высновы, што Graylog проста не спраўляецца. Паглядзелі, і, сапраўды, Graylog з Elasticsearch не дужалі гэты струмень.
Далей, іншыя адкрыцці, якія мы зрабілі ў працэсе.
Запіс у socket блакуюцца. Як гэта адбылося? Калі я выкарыстаў rsyslog для дастаўкі, у нейкі момант у нас зламаўся канал паміж датацэнтрамі. Устала дастаўка ў адным месцы, устала дастаўка іншым месцы. Усё гэта дакацілася да машыны з API, якія пішуць у сокет rsyslog. Там запоўнілася чарга. Потым запоўнілася чарга на запіс у unix socket, які па змаўчанні 128 пакетаў. І наступны write() у дадатку блакуецца. Калі мы глядзелі ў бібліятэчку, якой карыстаемся ў дадатках на Go, там было напісана, што запіс у сокет адбываецца ў неблакіруемым рэжыме. Мы былі ўпэўненыя, што нічога не блакуецца. Бо мы чыталі , якая пра гэта напісала. Але ёсць момант. Вакол гэтага выкліку быў яшчэ бясконцы цыкл, у якім увесь час адбывалася спроба запіхаць паведамленне ў сокет. Вось яго мы не заўважылі. Прыйшлося перапісаць бібліятэку. З тых часоў яна некалькі разоў мянялася, але зараз мы пазбавіліся ад блакіровак ва ўсіх падсістэмах. Таму, можна спыняць rsyslog, і нічога не зваліцца.
Трэба маніторыць памер чэргаў, што дапамагае не наступіць на гэтыя граблі. Па-першае, мы можам маніторыць, калі мы пачынаем губляць паведамленні. Па-другое, можам маніторыць, што ў нас у прынцыпе праблемы з дастаўкай.
І яшчэ непрыемны момант – ампліфікацыя ў 10 разоў у мікрасэрвіснай архітэктуры – гэта вельмі лёгка. У нас уваходных запытаў не так шмат, але з-за графа, па якім бегаюць гэтыя паведамленні далей, з-за access-логаў, мы рэальна павялічваем нагрузку па логах прыкладна раз у дзесяць. Я на жаль не паспеў палічыць дакладныя лічбы, але мікрасэрвісы – яны такія. Гэта трэба мець на ўвазе. Атрымліваецца, што на дадзены момант падсістэма збору логаў самая нагружаная ў Lazada.
Як вырашыць праблему elasticsearch? Калі трэба хутка атрымаць логі ў адным месцы, каб не бегаць па ўсіх машынах, і не збіраць іх тамака, выкарыстоўвайце файлавае сховішча. Гэта гарантавана працуе. Яно робіцца з любога сервера. Трэба проста наторкаць туды дыскаў і паставіць syslog. Пасля гэтага ў вас гарантавана ў адным месцы ўсе логі ёсць. Далей ужо можна будзе павольна наладжваць elasticsearch, graylog, што-небудзь яшчэ. Але ў вас ужо будуць усе логі, і, прычым, вы іх можаце захоўваць, наколькі хапае дыскавых масіваў.
На момант майго даклада схема стала выглядаць вось так. У файл мы практычна перасталі пісаць. Цяпер, хутчэй за ўсё, адлучым рэшткі. На лакальных машынах, на якіх запушчаны API, у файлы мы пісаць перастанем. Па-першае, ёсць файлавае сховішча, якое працуе вельмі добрае. Па-другое, на гэтых машынах увесь час канчаецца месца, трэба яго ўвесь час маніторыць.
Вось гэтая частка з Logstash і Graylog, яна рэальна парыць. Таму трэба яе пазбавіцца. Трэба абраць нешта адно.
Мы вырашылі выкінуць Logstash і Kibana. Бо ў нас ёсць аддзел бяспекі. Якая сувязь? Сувязь у тым што Kibana без X-Pack і без Shield не дазваляе размежаваць правы доступу да логаў. Таму ўзялі Graylog. У ім усё гэта ёсць. Ён мне не падабаецца, але ён працуе. Мы купілі новага жалеза, паставілі там свежы Graylog і перанеслі ўсе логі са строгімі фарматамі ў асобны Graylog. Мы вырашылі праблему з рознымі тыпамі аднолькавых палёў арганізацыйна.
Што ўласна ў новы Graylog уваходзіць. Мы проста запісалі ўсё ў докер. Узялі кучу сервераў, раскаталі тры інстансу Kafka, 7 сервераў Graylog версіі 2.3 (таму што хацелася Elasticsearch версіі 5). Усё гэта на рэйдах з HDD паднялі. Убачылі indexing rate да 100 тысяч паведамленняў за секунду. Убачылі лічбу што 140 тэрабайт дадзеных у тыдзень.
І зноў граблі! У нас будуць два распродажы. Мы пераехалі за 6 мільёнаў паведамленняў. У нас Graylog не паспявае пражоўваць. Неяк трэба зноў выжываць.
Выжылі мы вось так. Дадалі яшчэ крыху сервераў і SSD. Цяпер мы жывем вось такім спосабам. Цяпер мы пражоўваем ужо 160к паведамленняў у секунду. Мы яшчэ не ўперліся ў ліміт, таму пакуль незразумела, колькі мы рэальна зможам выцягнуць з гэтага.
Вось такія ў нас планы на будучыню. З іх, рэальна, найважнейшае, мусіць, high availability. У нас яго пакуль што няма. Некалькі машын настроены аднолькава, але едзе пакуль усё праз адну машыну. Трэба патраціць час, каб наладзіць failover паміж імі.
Сабраць метрыкі з Graylog.
Зрабіць rate limit каб у нас адна, якая звар'яцела API, не забівала нам bandwidth і ўсё астатняе.
І нарэшце, падпісаць нейкі SLA c распрацоўшчыкамі, што мы можам абслужыць вось столькі. Калі вы пішаце больш, то прабачце.
І напісаць дакументацыю.
Каротка, вынікі ўсяго, што мы перажылі. Па-першае, стандарты. Па-другое, syslog – торт. Па-трэцяе, rsyslog працуе менавіта вось так, як напісана на слайдзе. І давайце пяройдзем да пытанняў.
пытанні.
Пытанне: Чаму ўсё ж такі вырашылі не браць… (filebeat?)
Адказ: Трэба пісаць у файл. Вельмі не хацелася. Калі ў цябе API піша тысячы паведамленняў у секунду, ты нават калі раз на гадзіну будзеш ратыраваць, то гэта ўсё роўна не варыянт. Можна пісаць у pipe. На што мяне распрацоўшчыкі спыталі: "А што будзе калі, працэс у які мы пішам, упадзе"? Я проста не знайшоў, што ім адказаць, і сказаў: "Ну ок, давайце мы не будзем так рабіць".
Пытанне: Чаму вы не пішаце логі проста ў HDFS?
Адказ: Гэта наступны этап. Мы пра яго падумалі самым пачатку, але, паколькі, у дадзены момант няма рэсурсаў гэтым займацца, то ён у нас вісіць у long term solution.
Пытанне: Калонкавы фармат быў бы больш прыдатны.
Адказ: Я ўсё разумею. Мы "за" абедзвюма рукамі.
Пытанне: Вы пішыце ў rsyslog. Тамака можна і TCP, і UDP. Але калі UDP, дык тады як вы гарантуеце дастаўку?
Адказ: Ёсць два моманты. Першы, я адразу ўсім кажу, што мы не гарантуем дастаўку логаў. Таму што, калі распрацоўшчыкі прыходзяць і кажуць: "А давайце мы туды пачнем пісаць фінансавыя дадзеныя, а вы будзеце іх нам кудысьці складаць на выпадак, калі нешта здарыцца", мы ім адказваем "Выдатна! Давайце вы пачняце блакавацца на запісы ў сокет, і рабіць гэта ў транзакцыях, каб гарантавана вы нам гэта ў сокет паклалі і пераканаліся, што мы з таго боку гэта атрымалі.» І ў гэты момант усім адразу робіцца не трэба. А раз не трэба, дык якія да нас пытанні? Калі вы не жадаеце гарантаваць запіс у сокет, то навошта нам гарантаваць дастаўку? Мы робім best effort. Мы рэальна імкнемся даставіць як мага больш і як мага лепш, але мы не даем 100% гарантыі. Таму ня трэба пісаць туды фінансавыя дадзеныя. Для гэтага ёсць базы даных з транзакцыямі.
Пытанне: Калі API генеруе нейкае паведамленне ў лог і перадае кіраванне мікрасэрвісам, то ці не сутыкаліся вы з праблемай, што паведамленні ад розных мікрасэрвісаў прыходзяць у няправільным парадку? З-за гэтага ўзнікае блытаніна.
Адказ: Гэта нармальна, што яны прыходзяць у розным парадку. Да гэтага трэба быць гатовым. Таму што любая сеткавая дастаўка вам не гарантуе парадак, ці трэба марнаваць спецыяльна рэсурсы на гэта. Калі возьмем файлавыя сховішчы, то кожная API захоўвае логі ў свой файл. Дакладней тамака rsyslog раскладваецца іх па каталогах. У кожнага API там ёсць свае логі, куды можна пайсці і паглядзець, і потым па timestamp у гэтым логу можна іх супастаўляць. Калі яны ідуць глядзець у Graylog, то там яны адсартуецца па timestamp. Там усё будзе добра.
Пытанне: Timestamp можа адрознівацца на мілісекунды.
Адказ: Timestamp генеруе сама API. У гэтым, уласна, уся фішка. У нас ёсць NTP. API генеруе timestamp ужо ў самім паведамленні. Яго не rsyslog дадае.
Пытанне: Не вельмі зразумелае ўзаемадзеянне паміж датацэнтрамі. У рамках датацэнтра зразумела як логі сабралі, апрацавалі. Як адбываецца ўзаемадзеянне паміж датацэнтрамі? Ці кожны датацэнтр жыве сваім жыццём?
Адказ: Амаль. У нас кожная краіна знаходзіцца ў нейкім адным датацэнтры. У нас няма на дадзены момант размазвання, каб адна краіна была размешчана па розных датацэнтрах. Таму не трэба іх аб'ядноўваць. Унутры кожнага цэнтра ёсць Log Relay. Гэта Rsyslog сервер. Насамрэч дзве менеджмент машыны. Яны аднолькава настроены. Але пакуль проста трафік ідзе праз адну з іх. Яна логі ўсё агрэгуе. У яе ёсць дыскавая чарга на ўсялякі выпадак. Яна цісне логі, і адпраўляе іх у цэнтральны датацэнтр (сінгапурскі), дзе далей яны ўжо атручваюцца ў Graylog. І ў кожным датацэнтры ёсць свой файлавы storage. У выпадку, калі ў нас знікла сувязь, мы маем усе логі там. Яны там застануцца. Яны там будуць захаваны.
Пытанне: Пры няштатных сітацыях адтуль вы атрымліваеце логі?
Адказ: Можна пайсці туды (у файлавае сховішча) і паглядзець.
Пытанне: Як вы маніторыце тое, што вы не губляеце логі?
Адказ: Мы іх губляем насамрэч, і мы гэта маніторым. Маніторынг запусцілі месяц таму. У бібліятэцы, якую выкарыстоўваюць Go API, ёсць метрыкі. Яна ўмее лічыць, колькі разоў яна не змагла запісаць у socket. Там зараз ёсць хітрая эўрыстыка. Тамака ёсць буфер. Ён спрабуе запісваць зь яго паведамленьне ў socket. Калі буфер перапоўніцца, ён пачынае іх дрыпаць. І лічыць колькі ён іх падрапаў. Калі там пачынае перапаўняцца лічыльнікі, мы пра гэта даведаемся. Яны зараз прыязджаюць таксама ў prometheus, і ў Grafana можна паглядзець графікі. Можна наладзіць абвесткі. Але пакуль незразумела, каму іх адпраўляць.
Пытанне: У elasticsearch вы з рэзерваваннем захоўваеце логі. Колькі ў вас рэплік?
Адказ: Адна рэпліка.
Пытанне: Гэта ўсяго адна рэпліка?
Адказ: Гэта майстар і рэпліка. У двух экзэмплярах дадзеныя захоўваюцца.
Пытанне: Памер буфера rsyslog вы неяк падкручвалі?
Адказ: Мы пішам дэйтаграмы ў кастамны unix socket. Гэта нам адразу ж накладвае абмежаванне 128 кілабайт. Мы не можам запісаць у яго больш. Мы прапісалі гэта ў стандарт. Хто хоча трапляць у старэджы, тыя пішуць 128 кілабайт. Бібліятэкі, прычым, абразаюць, і ставяць сцяг, што паведамленне абрэзана. У нас стандарце самога паведамлення ёсць спецыяльныя поле, якое паказвае было яно абрэзана пры запісе ці не. Так што мы маем магчымасьць адсачыць і гэты момант.
Пытанне: Ці пішаце вы бітыя JSON?
Адказ: Біты JSON будзе адкінуты альбо падчас relay, таму што занадта вялікі пакет. Або будзе адкінуты Graylog, таму што не зможа JSON распарсіць. Але тут ёсць нюансы, якія трэба фіксаваць, і яны большай часткай завязаны на rsyslog. Я ўжо запоўніў туды некалькі issue, над якімі трэба яшчэ працаваць.
Пытанне: Чаму Kafka? Ці спрабавалі RabbitMQ? Ці не складаецца Graylog пры такіх нагрузках?
Адказ: У нас з Graylog не складаецца. А Graylog у нас складаецца. З ім рэальна праблемна. Ён своеасаблівая штука. І, насамрэч, ён не патрэбен. Я хацеў бы пісаць з rsyslog напрамую ў elasticsearch і глядзець потым Kibana. Але трэба ўтрасці пытанне з бяспечнікамі. Гэта магчымы варыянт нашага развіцця, калі мы выкінем Graylog і будзем выкарыстоўваць Kibana. Logstash выкарыстоўваць сэнсу не будзе. Таму што, я магу ўсё гэта ж зрабіць rsyslog. І ў яго есць модуль для запісу ў elasticsearch. З Graylog мы спрабуем неяк жыць. Мы яго нават крыху пацюнілі. Але тамака ёсць яшчэ прастора для паляпшэнняў.
Наконт Kafka. Так склалася гістарычна. Калі я прыйшоў, яна ўжо была, і ў яе ўжо пісалі логі. Мы проста паднялі наш кластар і пераехалі ў яго логамі. Мы яго мянядзім, мы ведаем, як ён сябе адчувае. Наконт RabbitMQ… у нас не складаецца з RabbitMQ. А RabbitMQ у нас складаецца. У нас прадакшне ён ёсць, і з ім былі праблемы. Цяпер бы перад распродажам яго зашаманілі, і ён стаў нармальна працаваць. Але да гэтага я быў не гатовы яго выпускаць у прадакшн. Ёсць яшчэ адзін момант. Graylog умее чытаць версію AMQP 0.9, а rsyslog умее пісаць версію AMQP 1.0. І няма ніводнага рашэння, якое пасярэдзіне ўмее і тое, і другое. Ёсць альбо тое ці іншае. Таму на дадзены момант толькі Kafka. Але тамака таксама свае нюансы. Таму што omkafka той версіі rsyslog, якой мы выкарыстоўваем, можа страціць вось увесь буфер паведамленняў, якое яна выграбла з rsyslog. Пакуль мы з гэтым мірымся.
Пытанне: Вы карыстаецеся Kafka таму, што яна ў вас у была? Больш ні для якіх мэт не выкарыстоўваецца?
Адказ: Kafka, якая была, выкарыстоўваецца камандай Data Sсience. Гэта зусім асобны праект, пра які я, нажаль, нічога сказаць не магу. Я не ў курсе. Яна была ў падпарадкаванні каманды Data Sсience. Калі логі заводзілі вырашылі скарыстаць яе, каб не ставіць яшчэ і сваю. Цяпер мы абнавілі Graylog, і ў нас згубілася сумяшчальнасць, таму што тамака старая версія Kafka. Нам прыйшлося завесці сваю. Заадно мы пазбавіліся ад гэтых чатырох топікаў на кожны API. Мы зрабілі адзін шырокі топік на ўсе live, адзін шырокі шырокі топік на ўсе staging і проста ўсё туды куляем. Graylog усё гэта раўналежна выграбае.
Пытанне: Навошта трэба вось гэтае шаманства з сокетамі? Ці спрабавалі выкарыстоўваць log-драйвер syslog для кантэйнераў.
Адказ: На той момант, калі мы гэтым пытаннем задаваліся, з докерам у нас адносіны былі напружаныя. Гэта быў docker 1.0 ці 0.9. Docker сам па сабе быў дзіўны. Па-другое, калі ў яго яшчэ і логі штурхаць… У мяне ёсць неправеранае падазрэнне, што ён прапускае ўсе логі праз сябе, праз дэман докера. Калі ў нас адно API сходзіць з розуму, то астатнія API абаткнецца ў тое, што яны не могуць адправіць stdout і stderr. Я не ведаю, да чаго гэта прывядзе. У мяне ёсць падазрэнне на ўзроўні адчування, што не трэба syslog-драйвер докера вось у гэтым месцы выкарыстоўваць. У нашага аддзела функцыянальнага тэсціраванне ёсць свой уласны кластарачак Graylog з логамі. Яны выкарыстоўваюць log-драйверы докера і ў іх там быццам бы нават усё добра. Але яны GELF адразу пішуць у Graylog. Мы на той момант, калі ўсё гэта ладзілі, нам трэба было каб яно проста працавала. Магчыма потым, калі нехта прыйдзе і скажа, што яно ўжо сто гадоў працуе нармальна, мы паспрабуем.
Пытанне: Вы дастаўку паміж датацэнтрамі робіце на rsyslog. Чаму не на Kafka?
Адказ: Мы робім і так, і так на самой справе. Па двух прычынах. Калі канал зусім забіты, то ў нас усе логі нават у сціснутым выглядзе не пралазяць яго. А кафка дазваляе іх проста губляць у працэсе. Мы гэтым спосабам пазбаўляемся ад заліпання вось гэтых логаў. Мы проста выкарыстоўваем Kafka у гэтым выпадку напрамую. Калі ў нас канал добры і жадаецца вызваліць яго, то мы выкарыстоўваем іх rsyslog. Але насамрэч можна яго наладзіць яго так, каб ён сам дрыпаў тое, што не пралезла. На дадзены момант мы проста недзе выкарыстоўваем дастаўку rsyslog напрамую, недзе Kafka.
Крыніца: habr.com