Дневниците се важен дел од системот, што ви овозможува да разберете дека работи (или не работи) како што се очекуваше. Во архитектурата на микросервис, работата со дневници станува посебна дисциплина за посебна олимпијада. Еден куп прашања треба да се решат одеднаш:
- како да пишувате дневници од апликација;
- каде да пишувате дневници;
- како да се доставуваат дневници за складирање и обработка;
- како да се обработуваат и складираат дневниците.
Употребата на моментално популарни технологии за контејнеризација додава песок на врвот на гребло во полето на опции за решавање на проблемот.
Токму за тоа се работи за транскриптот од извештајот на Јуриј Бушмелев „Карта на гребла во областа на собирање и доставување трупци“.
Кој се грижи, ве молам под мачката.
Јас се викам Јури Бушмелев. Работам во Лазада. Денес ќе зборувам за тоа како ги направивме нашите трупци, како ги собравме и што пишуваме таму.
Од каде сме? Кои сме ние? Лазада е број 1 онлајн трговец на мало во шест земји во Југоисточна Азија. Сите овие земји се дистрибуирани меѓу нашите центри за податоци. Во моментов има вкупно 4 центри за податоци Зошто е ова важно? Затоа што некои одлуки се должат на тоа што има многу слаба врска меѓу центрите. Имаме микросервис архитектура. Бев изненаден кога открив дека веќе имаме 80 микросервиси. Кога ја започнав задачата со логови, имаше само 20. Плус има прилично големо парче PHP наследство, кое исто така морам да живеам и да го трпам. Сето ова во моментов генерира повеќе од 6 милиони пораки во минута за системот како целина. Следно ќе покажам како се обидуваме да живееме со ова, и зошто е тоа така.
Мора некако да живеете со овие 6 милиони пораки. Што да правиме со нив? Потребни ви се 6 милиони пораки:
- испрати од апликација
- прифати за испорака
- достави за анализа и складирање.
- анализира
- складирајте го некако.
Кога се појавија три милиони пораки, јас изгледав исто. Затоа што почнавме со само неколку пари. Јасно е дека таму се напишани дневници за апликации. На пример, не можев да се поврзам со базата на податоци, можев да се поврзам со базата на податоци, но не можев да прочитам ништо. Но, покрај ова, секој наш микросервис пишува и дневник за пристап. Секое барање што пристигнува до микросервисот се запишува во дневникот. Зошто го правиме ова? Програмерите сакаат да можат да трагаат. Секој дневник за пристап содржи поле за трага, со кое специјален интерфејс потоа го одмотува целиот синџир и убаво ја прикажува трагата. Трагата покажува како се одвивало барањето, а тоа им помага на нашите програмери брзо да се справат со секое неидентификувано ѓубре.
Како да се живее со ова? Сега накратко ќе го опишам полето на опции - како генерално се решава овој проблем. Како да се реши проблемот со собирање, пренесување и складирање на трупци.
Како да пишувате од апликација? Јасно е дека постојат различни начини. Конкретно, постои најдобра практика, како што ни кажуваат нашите модерни другари. Постојат два типа на стара школа, како што ни кажуваа нашите дедовци. Има и други начини.
Приближно иста е ситуацијата со собирање трупци. Нема многу опции за решавање на овој конкретен дел. Веќе ги има повеќе, но сè уште не толку многу.
Но, со испорака и последователна анализа, бројот на варијации почнува да експлодира. Сега нема да ја опишам секоја опција. Мислам дека главните опции се добро познати на сите кои се заинтересирани за темата.
Ќе ви покажам како го направивме тоа во Лазада и како всушност започна сето тоа.
Пред една година дојдов во Лазада и ме испратија на проект за трупци. Беше вакво нешто. Дневникот на апликацијата беше напишан на stdout и stderr. Сè беше направено на модерен начин. Но, тогаш програмерите го исфрлија од стандардните текови, а потоа некако специјалистите за инфраструктура ќе го сфатат. Помеѓу специјалистите за инфраструктура и програмерите, има и издавачи кои рекоа: „ух... во ред, само да ги завиткаме во датотека со школка, и тоа е тоа“. И бидејќи сето тоа беше во контејнер, тие го завиткаа право во самиот сад, го мапираа каталогот внатре и го ставија таму. Мислам дека на сите им е прилично очигледно што произлезе од тоа.
Ајде да погледнеме малку подалеку за сега. Како ги испорачавме овие логови? Некој избра td-agent, кој всушност е флуент, но не баш течен. Сè уште не ја разбирам врската помеѓу овие два проекти, но се чини дека се работи за иста работа. И ова течно, напишано во Ruby, читаше датотеки за евиденција, ги анализираше во JSON користејќи некаква регуларност. Потоа ги испратив кај Кафка. Згора на тоа, во Кафка имавме 4 посебни теми за секое API. Зошто 4? Затоа што има живо, има инсценирање, и затоа што има stdout и stderr. Програмерите ги создаваат, а развивачите на инфраструктура мора да ги креираат во Кафка. Згора на тоа, Кафка бил контролиран од друг оддел. Затоа, беше потребно да се создаде тикет така што тие ќе создадат 4 теми за секое api. Сите заборавија на тоа. Во принцип, имаше ѓубре и гужва.
Што направивме понатаму со ова? Го испративме кај Кафка. Тогаш половина од трупците од Кафка полетаа во Логсташ. Другата половина од трупците беа поделени. Некои летаа во еден Грејлог, некои во друг Грејлог. Како резултат на тоа, сето ова влезе во еден кластер Elasticsearch. Односно, целата оваа збрка заврши таму. Не правете го тоа!
Вака изгледа ако го погледнете одозгора. Не правете го тоа! Овде проблематичните области веднаш се означени со бројки. Всушност, има повеќе од нив, но 6 се навистина проблематични за кои треба нешто да се преземе. Сега ќе ви кажам за нив одделно.
Овде (1,2,3) пишуваме датотеки и, соодветно, тука има три гребла одеднаш.
Првата (1) е дека треба да ги напишеме некаде. Не секогаш би било пожелно на API да му се даде можност директно да пишува во датотека. Пожелно е API да биде изолиран во контејнер, или уште подобро, да биде само за читање. Јас сум системски администратор, па имам малку алтернативен поглед на овие работи.
Втората точка (2,3) е дека имаме многу барања кои доаѓаат до API. API запишува многу податоци во датотека. Датотеките се зголемуваат. Треба да ги ротираме. Бидејќи во спротивно нема да можете да складирате никакви дискови таму. Нивното ротирање е лошо бидејќи тие се направени со пренасочување преку школка во директориумот. Нема шанси да го ревидираме. Не можете да и кажете на апликацијата повторно да ги отвори рачките. Затоа што програмерите ќе ве гледаат како да сте будала: „Какви дескриптори? Ние обично пишуваме на stdout“. Развивачите на инфраструктура направија copytruncate за логротација, што едноставно прави копија од датотеката и го транскрибира оригиналот. Според тоа, помеѓу овие процеси на копирање, просторот на дискот обично истекува.
(4) Имавме различни формати во различни API. Тие беа малку поинакви, но regexp требаше да се напише поинаку. Бидејќи сето ова беше контролирано од Puppet, имаше голем куп часови со свои лебарки. Плус, најчесто td-agent можеше да јаде меморија, да биде глуп, може само да се преправа дека работи и да не прави ништо. Однадвор беше невозможно да се разбере дека не прави ништо. Во најдобар случај, ќе падне и некој ќе го земе подоцна. Поточно, ќе пристигне тревога, и некој ќе оди да го крене со раце.
(6) А најмногу ѓубре и отпад беше elasticsearch. Затоа што беше стара верзија. Затоа што во тоа време немавме посветени мајстори. Имавме хетерогени логови чии полиња може да се преклопуваат. Различни дневници од различни апликации може да се напишат со исти имиња на полиња, но може да има различни податоци внатре. Тоа е, еден дневник доаѓа со Цел број во полето, на пример, ниво. Друг дневник доаѓа со String во полето за ниво. Во отсуство на статичко мапирање, ова е толку прекрасна работа. Ако по ротирање на индексот во elasticsearch, прво пристигне порака со низа, тогаш живееме нормално. Но, ако првата пристигнала од Цел број, тогаш сите последователни пораки што пристигнале од Стринг едноставно се отфрлаат. Бидејќи типот на полето не се совпаѓа.
Почнавме да ги поставуваме овие прашања. Решивме да не ги бараме виновниците.
Но, нешто треба да се направи! Очигледно е дека треба да воспоставиме стандарди. Веќе имавме некои стандарди. Почнавме некои малку подоцна. За среќа, во тоа време веќе беше одобрен единствен формат на дневник за сите API. Тоа е директно запишано во стандардите за интеракција помеѓу услугите. Соодветно на тоа, оние кои сакаат да примаат дневници мора да ги напишат во овој формат. Ако некој не пишува дневници во овој формат, тогаш не гарантираме ништо.
Следно, би сакал да создадам унифициран стандард за методите на снимање, доставување и собирање логови. Всушност, каде да ги напишете и како да ги доставите. Идеалната ситуација е кога проектите користат иста библиотека. Постои посебна библиотека за логирање за Go, и посебна библиотека за PHP. Секој што го имаме треба да ги користи. Во моментов би рекол дека во ова сме успешни 80 проценти. Но, некои луѓе продолжуваат да јадат кактуси.
И таму (на слајдот) „SLA за испорака на трупци“ едвај почнува да се појавува. Сè уште не постои, но работиме на тоа. Затоа што е многу погодно кога инфраструктурата вели дека ако пишувате во таков формат на такво и такво место и не повеќе од N пораки во секунда, тогаш најверојатно ќе го доставиме до такво и такво место. Ова ублажува многу главоболки. Ако постои SLA, тогаш ова е апсолутно прекрасно!
Како почнавме да го решаваме проблемот? Главниот проблем беше со td-agent. Не беше јасно каде отидоа нашите трупци. Дали се испорачуваат? Дали одат? Каде се тие воопшто? Затоа, првата точка беше решена да се замени td-agent. Овде накратко ги наведов опциите за тоа со што да го заменам.
Течно. Прво, го сретнав на претходната работа, а и тој периодично паѓаше таму. Второ, ова е истото, само во профил.
Фајлбит. Како ни беше погодно? Затоа што е во Go, а ние имаме многу експертиза во Go. Соодветно на тоа, ако нешто се случи, ние некако би можеле да го додадеме за себе. Затоа не го зедовме. За да нема никакво искушение да почнете да го препишувате за себе.
Очигледно решение за системскиот администратор се сите видови syslogs во оваа количина (syslog-ng/rsyslog/nxlog).
Или напишете нешто свое, но ние го отфрливме ова, како и фајлбит. Ако пишувате нешто, подобро е да напишете нешто корисно за бизнисот. За да испорачате трупци, подобро е да земете нешто готово.
Затоа, изборот всушност се сведе на изборот помеѓу syslog-ng и rsyslog. Се наведнав кон rsyslog едноставно затоа што веќе имавме часови за rsyslog во Puppet и не најдов очигледна разлика меѓу нив. Што е syslog, што е syslog. Да, некои имаат полоша документација, некои имаат подобра. Овој може вака, а другиот поинаку.
И малку за rsyslog. Како прво, кул е затоа што има многу модули. Има RainerScript читлив од луѓе (модерен јазик за конфигурација). Тоа е одличен бонус што можеме да го имитираме однесувањето на td-agent користејќи стандардни алатки и ништо не се смени за апликациите. Односно, го менуваме td-agent во rsyslog, а се останато оставаме на мира засега. И веднаш добиваме работна достава. Следно, mmnormalize е одлична работа во rsyslog. Ви овозможува да ги анализирате дневниците, но не да користите Grok и regexp. Прави апстрактно синтаксно дрво. Ги анализира логовите на ист начин како што компајлерот ги анализира изворите. Ова ви овозможува да работите многу брзо, да трошите малку процесор и, генерално, тоа е навистина одлична работа. Има уште еден куп бонуси. Нема да се задржувам на нив.
rsyslog има многу други недостатоци. Тие се приближно исти како бонусите. Главните проблеми се што треба да знаете како да го готвите, а треба да ја изберете верзијата.
Решивме да пишуваме логови во приклучок за Unix. А не во /dev/log, бидејќи таму имаме хаос од системски логови, journald е во овој гасовод. Значи, ајде да пишеме на прилагоден штекер. Ќе го прикачиме на посебна група правила. Да не се мешаме со ништо. Сè ќе биде транспарентно и разбирливо. Токму тоа го направивме. Директориумот со овие приклучоци е стандардизиран и проследен до сите контејнери. Контејнерите можат да го видат штекерот што им е потребен, да го отворат и да пишуваат на него.
Зошто не датотека? Затоа што сите го читаат , кој се обиде да препрати датотека до docker, и беше откриено дека по рестартирањето на rsyslog, дескрипторот на датотеката се смени и докерот ја изгуби оваа датотека. Одржува уште нешто отворено, но не и штекерот каде што пишуваат. Решивме дека ќе работиме околу овој проблем, а во исто време ќе работиме и на проблемот со блокирање.
Rsyslog ги извршува дејствата наведени на слајдот и испраќа логови или до релето или до Кафка. Кафка оди по стариот пат. Реле - се обидов да користам чист rsyslog за да испорачам логови. Без редослед за пораки, користејќи стандардни алатки rsyslog. Во основа, тоа функционира.
Но, има нијанси како да ги туркате во овој дел (Logstash/Graylog/ES). Овој дел (rsyslog-rsyslog) се користи помеѓу центрите за податоци. Еве една компресирана tcp врска, која ни овозможува да заштедиме пропусност и, соодветно, некако да ја зголемиме веројатноста дека ќе добиеме некои дневници од друг центар за податоци кога каналот е затнат. Затоа што ја имаме Индонезија, каде што се е лошо. Тука лежи постојаниот проблем.
Размислувавме како всушност можеме да следиме колку е веројатно дека дневниците што ги снимивме од апликацијата ќе стигнат до крајот? Решивме да создадеме метрика. rsyslog има свој модул за собирање статистика, кој содржи некој вид бројачи. На пример, може да ви ја покаже големината на редот или колку пораки пристигнале во таква и таква акција. Веќе можете да земете нешто од нив. Плус, има прилагодени бројачи што може да се конфигурираат и ќе ви го покаже, на пример, бројот на пораки што некои API ги снимиле. Следно, напишав rsyslog_exporter во Python, и го испративме сето тоа до Прометеј и направивме графикони. Навистина сакавме метрика на Graylog, но сè уште немавме време да ги поставиме.
Кои беа проблемите? Проблемите настанаа кога откривме (ОДЕДНАШ!) дека нашите Live API пишуваат 50 илјади пораки во секунда. Ова е само API во живо без поставување. А Graylog ни покажува само 12 илјади пораки во секунда. И се појави разумно прашање: каде се остатоците? Од што заклучивме дека Graylog едноставно не може да се снајде. Гледавме и, навистина, Graylog и Elasticsearch не можеа да се справат со овој тек.
Следно, други откритија што ги направивме на патот.
Запишувањата во штекерот се блокирани. Како се случи тоа? Кога користев rsyslog за испорака, во одреден момент се расипа каналот помеѓу центрите за податоци. Испораката запре на едно место, испораката запре на друго место. Сето ова стигна до машината со API-и кои пишуваат во приклучокот rsyslog. Таму имаше редица. Потоа се пополни редот за запишување во приклучокот Unix, кој стандардно е 128 пакети. И следното пишување() во апликацијата е блокирано. Кога ја погледнавме библиотеката што ја користиме во апликациите Go, таму беше напишано дека пишувањето во штекерот се случува во режим без блокирање. Бевме сигурни дека ништо не е блокирано. Затоа што читаме кој пишувал за тоа. Но, постои момент. Имаше и бесконечна јамка околу овој повик, во која имаше постојан обид да се турне порака во штекерот. Не го забележавме. Морав да ја препишам библиотеката. Оттогаш се менуваше неколку пати, но сега се ослободивме од блокирањето во сите потсистеми. Затоа, можете да го запрете rsyslog, и ништо нема да се сруши.
Неопходно е да се следи големината на редиците, што помага да се избегне стапнување на ова гребло. Прво, можеме да следиме кога почнуваме да губиме пораки. Второ, можеме да следиме дека имаме проблеми со испораката.
И уште еден непријатен момент - засилувањето за 10 пати во микросервис архитектура е многу лесно. Немаме многу дојдовни барања, но поради графиконот по кој овие пораки се движат понатаму, поради дневниците за пристап, ние всушност го зголемуваме оптоварувањето на дневникот за околу десет пати. За жал, немав време да ги пресметам точните бројки, но микросервисите се она што се. Ова мора да се има на ум. Излегува дека во моментот потсистемот за собирање дневници е најоптоварен во Лазада.
Како да се реши проблемот со elasticsearch? Ако треба брзо да ги соберете дневниците на едно место, за да не трчате наоколу до сите машини и да ги соберете таму, користете складирање датотеки. Ова е загарантирано да функционира. Тоа може да се направи од кој било сервер. Треба само да залепите дискови таму и да инсталирате syslog. По ова, гарантирано ќе ги имате сите дневници на едно место. Потоа можете полека да ги конфигурирате elasticsearch, graylog и нешто друго. Но, веќе ќе ги имате сите дневници и, згора на тоа, можете да ги складирате онолку колку што има доволно низи на дискови.
Во времето на мојот извештај, шемата почна да изгледа вака. Практично престанавме да пишуваме во досието. Сега, најверојатно, ќе го исклучиме остатокот. На локалните машини што работат на API, ќе престанеме да пишуваме во датотеки. Прво, има складирање на датотеки, што работи многу добро. Второ, на овие машини постојано им снемува простор, треба постојано да се следи.
Овој дел со Logstash и Graylog, навистина полетува. Затоа, треба да се ослободиме од него. Треба да изберете една работа.
Решивме да ги исфрлиме Логсташ и Кибана. Затоа што имаме оддел за безбедност. Каква врска? Врската е што Kibana без X-Pack и без Shield не ви дозволува да ги разликувате правата за пристап до дневниците. Затоа го земавме Грејлог. Сето тоа го има. Не ми се допаѓа, но функционира. Купивме нов хардвер, инсталиравме свеж Graylog таму и ги префрливме сите дневници со строги формати во посебен Graylog. Проблемот со различни типови на идентични полиња го решивме организациски.
Што точно е вклучено во новиот Graylog. Само напишавме сè во докер. Зедовме еден куп сервери, објавивме три примероци на Кафка, 7 сервери на Graylog верзија 2.3 (бидејќи ја сакавме верзијата 5 на Elasticsearch). Сето ова беше откриено за време на рациите од HDD. Видовме стапка на индексирање до 100 илјади пораки во секунда. Видовме бројка дека 140 терабајти податоци неделно.
И повторно гребло! Ни претстојат две продажби. Се преселивме над 6 милиони пораки. Грејлог нема време за џвакање. Некако мораме повторно да преживееме.
Вака преживеавме. Додадовме уште неколку сервери и SSD дискови. Во моментов живееме на овој начин. Сега веќе џвакаме 160 илјади пораки во секунда. Сè уште не сме ја достигнале границата, така што не е јасно колку всушност можеме да излеземе од ова.
Ова се нашите планови за иднината. Од нив, најважна е веројатно високата достапност. Сè уште го немаме. Неколку автомобили се конфигурирани на ист начин, но досега сè минува низ еден автомобил. Потребно е време за да се постави фајловер меѓу нив.
Соберете метрика од Graylog.
Направете ограничување на стапката за да имаме едно лудо API што не го убива нашиот пропусен опсег и сè друго.
И, конечно, потпишете некој вид SLA со програмерите за да можеме да служиме толку многу. Ако пишуваш повеќе, тогаш се извинувам.
И напишете документација.
Накратко, резултатите од се што доживеавме. Прво, стандарди. Второ, syslog е торта. Трето, rsyslog работи точно како што е напишано на слајдот. И да преминеме на прашањата.
прашања.
Прашање: Зошто решивте да не земате... (фајлбит?)
Одговори: Треба да напишеме во датотека. Навистина не сакав. Кога вашиот API пишува илјадници пораки во секунда, дури и ако го ротирате еднаш на час, ова сè уште не е опција. Можете да пишувате во цевка. На што програмерите ме прашаа: „Што ќе се случи ако процесот на кој пишуваме падне? Едноставно не најдов што да им одговорам и реков: „Па, добро, да не го правиме тоа“.
Прашање: Зошто едноставно не пишувате дневници на HDFS?
Одговори: Ова е следната фаза. Размислувавме за тоа на самиот почеток, но бидејќи во моментов нема ресурси за да го направиме тоа, тоа виси во нашето долгорочно решение.
Прашање: Форматот на колона би бил посоодветен.
Одговори: Разбирам. Ние сме за тоа со двете раце.
Прашање: Пишувате на rsyslog. Таму можете да користите и TCP и UDP. Но, ако UDP, тогаш како гарантирате испорака?
Одговори: Има две точки. Прво, веднаш им кажувам на сите дека не гарантираме испорака на трупци. Затоа што кога ќе дојдат програмерите и ќе речат: „Да почнеме да пишуваме финансиски податоци таму, а вие ќе ни ги ставите некаде во случај да се случи нешто“, ние им одговараме: „Одлично! Ајде да почнеме да блокираме за пишување во штекерот и да го правиме тоа во трансакции, така што гарантирано ќе ни го ставите на штекерот и ќе бидете сигурни дека ќе го добиеме од другата страна. И во овој момент, на сите веднаш веќе не му треба. Ако не е потребно, тогаш кои прашања треба да ги поставиме? Ако не сакате да гарантирате пишување во штекер, тогаш зошто треба да гарантираме испорака? Ние правиме се од себе. Навистина се трудиме да испорачаме што е можно повеќе и на најдобар можен начин, но не даваме 100% гаранција. Затоа, нема потреба таму да пишувате финансиски податоци. Постојат бази на податоци со трансакции за ова.
Прашање: Кога API генерира некоја порака во дневникот и ја пренесува контролата на микросервисите, дали наидовте на проблемот што пораките од различни микросервиси пристигнуваат по погрешен редослед? Ова предизвикува конфузија.
Одговори: Нормално е дека доаѓаат во различни редоследи. Треба да бидете подготвени за ова. Бидејќи секоја мрежна испорака не гарантира нарачка, или треба да потрошите посебни ресурси за ова. Ако земеме складишта на датотеки, тогаш секое API зачувува дневници во својата датотека. Или подобро кажано, таму rsyslog ги сортира во директориуми. Секое API има свои дневници, каде што можете да отидете и да ги погледнете, а потоа можете да ги споредите користејќи го временскиот печат во овој дневник. Ако одат да бараат во Graylog, тогаш тие се подредени таму по временски печат. Сè ќе биде добро таму.
Прашање: Временскиот печат може да се разликува за милисекунди.
Одговори: Временскиот печат е генериран од самиот API. Ова е, всушност, целата поента. Имаме NTP. API генерира временски печат во самата порака. rsyslog не го додава.
Прашање: Интеракцијата помеѓу центрите за податоци не е многу јасна. Во рамките на центарот за податоци, јасно е како се собирале и обработувале дневниците. Како се одвива интеракцијата помеѓу центрите за податоци? Или секој центар за податоци живее свој живот?
Одговори: За малку. Кај нас секоја земја се наоѓа во еден центар за податоци. Во моментов, немаме распространетост, така што една земја се наоѓа во различни центри за податоци. Затоа, нема потреба да ги комбинирате. Секој центар има Log Relay внатре. Ова е сервер Rsyslog. Всушност, две управувачки машини. Тие имаат ист став. Но, засега сообраќајот се одвива само преку еден од нив. Ги собира сите логови. Таа има редица за диск за секој случај. Ги презема дневниците и ги испраќа до централниот центар за податоци (Сингапур), каде што потоа се испраќаат до Graylog. И секој центар за податоци има свое складирање на датотеки. Во случај нашата врска да се изгуби, ги имаме сите логови таму. Тие ќе останат таму. Тие ќе бидат складирани таму.
Прашање: Во случај на ненормални ситуации, дали добивате дневници од таму?
Одговори: Можете да отидете таму (во складиштето на датотеки) и да погледнете.
Прашање: Како следите дека не губите дневници?
Одговори: Ние всушност ги губиме, и тоа го следиме. Мониторингот започна пред еден месец. Библиотеката што ја користат Go API има метрика. Таа може да брои колку пати не можела да пишува на штекер. Во моментов има паметна хеуристика таму. Таму има тампон. Се обидува да напише порака од него до штекерот. Ако тампонот се прелее, тој почнува да ги испушта. И брои колку од нив испуштил. Ако таму броилата почнат да се прелеваат, ќе знаеме за тоа. Сега доаѓаат и кај прометеј, а графиконите можете да ги видите во Графана. Можете да поставите предупредувања. Но, се уште не е јасно кому да ги испратат.
Прашање: Во elasticsearch складирате дневници со вишок. Колку реплики имате?
Одговори: Еден ред.
Прашање: Дали е ова само една линија?
Одговори: Ова е мајсторот и репликата. Податоците се чуваат во две копии.
Прашање: Дали некако ја прилагодивте големината на баферот rsyslog?
Одговори: Ние пишуваме датаграми на прилагоден уникс приклучок. Ова веднаш ни наметнува лимит од 128 килобајти. Не можеме да пишуваме повеќе за тоа. Ова го запишавме во стандардот. Оние кои сакаат да влезат во складиштето пишуваат 128 килобајти. Згора на тоа, библиотеките се отсечени, а се става знаменце дека пораката е отсечена. Нашиот стандард за самата порака има посебно поле кое покажува дали е отсечено за време на снимањето или не. Така, имаме можност да го следиме и овој момент.
Прашање: Дали пишувате скршен JSON?
Одговори: Скршениот JSON ќе биде отфрлен или за време на релето бидејќи пакетот е преголем. Или Graylog ќе биде отфрлен бидејќи не може да го анализира JSON. Но, има нијанси кои треба да се поправат, а тие се главно врзани за rsyslog. Таму веќе пополнив неколку прашања на кои треба уште да се работи.
Прашање: Зошто Кафка? Дали сте пробале RabbitMQ? Дали Graylog не успева при такви оптоварувања?
Одговори: Не ни оди со Graylog. И Graylog се обликува за нас. Тој е навистина проблематичен. Тој е чудна работа. И, всушност, тоа не е потребно. Би сакал да пишувам од rsyslog директно во elasticsearch и потоа да погледнам во Kibana. Но, треба да го решиме проблемот со обезбедувањето. Ова е можна опција за нашиот развој, кога ќе го исфрлиме Graylog и ќе користиме Kibana. Нема смисла да се користи Logstash. Затоа што можам да го направам истото со rsyslog. И има модул за пишување на elasticsearch. Се обидуваме да живееме некако со Грејлог. Дури и малку го подесивме. Но, се уште има простор за подобрување.
За Кафка. Така се случувало историски. Кога стигнав, веќе беше таму, и веќе му се пишуваа дневници. Едноставно го подигнавме нашиот кластер и ги преместивме трупците во него. Ние сме негова управа, знаеме како се чувствува. Што се однесува до RabbitMQ... не ни оди со RabbitMQ. И RabbitMQ се обликува за нас. Го имаме во производство, и имаше проблеми со него. Сега пред распродажбата ќе го шармираа, а тој ќе почнеше да работи нормално. Но, пред тоа не бев подготвен да го пуштам во производство. Има уште една точка. Graylog може да ја чита верзијата AMQP 0.9, а rsyslog може да ја напише верзијата AMQP 1.0. И не постои едно решение во средината што може да ги направи и двете. Тоа е или едното или другото. Затоа, во моментов само Кафка. Но, тоа има и свои нијанси. Бидејќи omkafka од верзијата на rsyslog што ја користиме може да го изгуби целиот бафер за пораки што го извади од rsyslog. Засега го трпиме.
Прашање: Дали го користите Кафка затоа што веќе сте го имале? Веќе не се користи за каква било намена?
Одговори: Кафка, кој беше, го користи тимот на Data Science. Ова е сосема посебен проект, за кој, за жал, не можам да кажам ништо. Не знам. Беше управуван од тимот на Data Science. Кога беа креирани дневниците, решивме да ги користиме за да не инсталираме свои. Сега го ажуриравме Graylog и ја изгубивме компатибилноста бидејќи има стара верзија на Кафка. Моравме да започнеме свое. Во исто време, се ослободивме од овие четири теми за секое API. Направивме една широка тема за сите во живо, една широка широка тема за сите инсценации и само ставивме сè таму. Грејлог го гребе сето ова паралелно.
Прашање: Зошто ни е потребен овој шаманизам со штекери? Дали сте се обиделе да го користите двигателот на дневникот syslog за контејнери?
Одговори: Во времето кога го поставивме ова прашање, нашиот однос со докерот беше напнат. Беше докер 1.0 или 0.9. Самиот Докер беше чуден. Второ, ако туркаш и логови во него... имам непроверен сомнеж дека ги поминува сите логови низ себе, преку докерскиот демон. Ако еден API полуди, тогаш останатите API се заглавени во фактот дека не можат да испраќаат stdout и stderr. Не знам каде ќе води ова. Имам сомневање на ниво на чувство дека нема потреба да се користи Docker syslog драјверот на ова место. Нашиот оддел за функционално тестирање има свој Graylog кластер со логови. Тие користат драјвери за дневници на Docker и се чини дека сè е во ред таму. Но, тие веднаш пишуваат GELF на Graylog. Во времето кога го почнавме сето ова, само ни требаше за да функционира. Можеби подоцна, кога некој ќе дојде и ќе каже дека работи добро сто години, ќе се обидеме.
Прашање: вршите испорака помеѓу центрите за податоци користејќи rsyslog. Зошто не и Кафка?
Одговори: Ние и двете ги правиме всушност. Од две причини. Ако каналот е целосно мртов, тогаш сите наши логови, дури и во компресирана форма, нема да ползат низ него. А Кафка ви дозволува едноставно да ги изгубите во тој процес. Вака ќе се ослободиме од заглавувањето на овие трупци. Само директно го користиме Кафка во овој случај. Ако имаме добар канал и сакаме да го ослободиме, тогаш го користиме нивниот rsyslog. Но, всушност, можете да го конфигурирате така што самиот ќе го испушти она што не се вклопуваше. Во моментов, ние користиме достава на rsyslog директно некаде, а Кафка некаде.
Извор: www.habr.com