Дневниците са важна част от системата, която ви позволява да разберете дали работи (или не работи) според очакванията. В условията на микросервизна архитектура, работата с трупи става отделна дисциплина на Специалната олимпиада. Има много проблеми, които трябва да бъдат решени:
- как да пиша логове от приложението;
- къде да пиша дневници;
- как да доставяме трупи за съхранение и обработка;
- как да обработвате и съхранявате регистрационни файлове.
Използването на популярните в момента технологии за контейнеризиране добавя пясък на върха на греблото в областта на опциите за решаване на проблеми.
Точно това е преписът на доклада на Юрий Бушмелев „Карта на гребла в областта на събирането и доставянето на трупи“
На кого му пука, моля под котката.
Казвам се Юрий Бушмелев. Работя за Lazada. Днес ще говоря за това как направихме нашите дневници, как ги събрахме и какво пишем там.
откъде сме Кои сме ние? Lazada е онлайн търговец номер 1 в шест държави в Югоизточна Азия. Всички тези страни са разпределени между центрове за данни. Вече има общо 4 центъра за данни. Защо това е важно? Защото някои решения се дължаха на факта, че има много слаба връзка между центровете. Имаме архитектура на микросервизи. Бях изненадан да открия, че вече имаме 80 микроуслуги. Когато започнах задачата с регистрационни файлове, те бяха само 20. Освен това има доста голяма част от наследството на PHP, с което също трябва да живея и да се примирявам. Всичко това генерира за нас в момента повече от 6 милиона съобщения в минута за системата като цяло. По-нататък ще покажа как се опитваме да живеем с това и защо това е така.
Трябва някак си да живееш с тези 6 милиона съобщения. Какво да правим с тях? Необходими са 6 милиона съобщения:
- изпращане от ап
- приемете за доставка
- доставят за анализ и съхранение.
- анализирам
- съхранявайте по някакъв начин.
Когато имаше три милиона съобщения, имах приблизително същия вид. Защото започнахме с едни стотинки. Ясно е, че там се записват регистрационни файлове на приложения. Например не може да се свърже с базата данни, може да се свърже с базата данни, но не може да прочете нещо. Но освен това, всяка от нашите микроуслуги също пише журнал за достъп. Всяка заявка, която пристига в микроуслугата, попада в дневника. Защо правим това? Разработчиците искат да могат да проследяват. Всеки дневник за достъп съдържа полето traceid, според което специален интерфейс след това развива цялата верига и красиво показва проследяването. Проследяването показва как е преминала заявката и това помага на нашите разработчици да се справят по-бързо с всеки неизвестен боклук.
Как да живеем с това? Сега ще опиша накратко полето от опции - как по принцип се решава този проблем. Как да решим проблема със събирането, прехвърлянето и съхранението на дневници.
Как да пиша от приложението? Ясно е, че има различни начини. По-специално, има най-добра практика, както ни казват модните другари. Има два вида стара школа, както са казвали дядовците. Има и други начини.
При събирането на трупи ситуацията е приблизително същата. Няма толкова много възможности за решаване на тази конкретна част. Има повече от тях, но все още не са толкова много.
Но с доставката и последващия анализ броят на вариациите започва да експлодира. Сега няма да описвам всеки вариант. Мисля, че основните опции са добре известни на всички, които се интересуват от темата.
Ще ви покажа как го направихме в Lazada и как започна всичко.
Преди година дойдох в Lazada и бях изпратен в проекта за дневници. Там беше така. Дневникът от приложението беше записан на stdout и stderr. Всичко беше направено по модерен начин. Но след това разработчиците го изхвърлиха от стандартните потоци и тогава специалистите по инфраструктура ще го разберат по някакъв начин. Между инфраструктурни специалисти и разработчици има и освобождаващи, които казаха: „Ъъъ... добре, нека просто ги увием във файл с обвивка и това е.“ И тъй като всичко това е в контейнер, те го опаковаха направо в самия контейнер, картографираха директорията вътре и я поставиха там. Мисля, че е доста очевидно за всички какво се е случило.
Нека погледнем малко по-нататък. Как доставихме тези трупи. Някой избра td-agent, който всъщност говори свободно, но не съвсем. Все още не разбирам връзката между тези два проекта, но изглежда, че става въпрос за едно и също нещо. И този fluentd, написан на Ruby, чете лог файлове, анализира ги в JSON, използвайки някои регулярни изрази. След това ги изпратиха при Кафка. Освен това в Kafka имахме 4 отделни теми за всеки API. Защо 4? Тъй като има живо, има постановка и тъй като има stdout и stderr. Разработчиците ги произвеждат, а инфраструктурните работници трябва да ги създават в Kafka. Освен това Кафка е бил контролиран от друг отдел. Следователно беше необходимо да се създаде билет, така че да създадат 4 теми там за всяко api. Всички го забравиха. Като цяло беше боклук и отпадъци.
Какво направихме след това с него? Изпратихме го на kafka. По-нататък от Кафка половината трупи отлетяха към Логсташ. Другата половина от трупите бяха споделени. Някои летяха към един Грейлог, други към друг Грейлог. В резултат на това всичко това отлетя в един клъстер Elasticsearch. Тоест цялата тази каша падна накрая там. Не е нужно да правите това!
Ето как изглежда, когато се гледа отгоре. Не е нужно да правите това! Тук проблемните зони веднага се маркират с цифри. Всъщност има повече от тях, но 6 са наистина проблемни, с които трябва да се направи нещо. Сега ще разкажа за тях отделно.
Тук (1,2,3) пишем файлове и съответно тук има три рейка наведнъж.
Първият (1) е, че трябва да ги напишем някъде. Не винаги е желателно да се даде възможност на API да пише директно във файл. Желателно е API-то да е изолирано в контейнер, а още по-добре да е само за четене. Аз съм системен администратор, така че имам малко алтернативен поглед върху тези неща.
Втората точка (2,3) е, че имаме много заявки, идващи към API. API записва много данни във файл. Файловете растат. Трябва да ги завъртим. Защото в противен случай няма да можете да запишете никакви дискове там. Завъртането им е лошо, защото те се пренасочват чрез обвивката към директория. Няма как да го завъртим. Не можете да кажете на приложението да отвори отново манипулаторите. Защото разработчиците ще ви гледат като глупак: „Какви дескриптори? Обикновено пишем на stdout. Направените рамки copytruncate в logrotate, което просто прави копие на файла и свързва оригинала. Съответно между тези процеси на копиране дисковото пространство обикновено свършва.
(4) Имахме различни формати в различни API. Те бяха малко по-различни, но регулярният израз трябваше да бъде написан по различен начин. Тъй като всичко се управляваше от Puppet, имаше голям куп класове със собствени хлебарки. Плюс това td-agent през повечето време можеше да изяжда паметта, да бъде глупав, можеше просто да се преструва, че работи и да не прави нищо. Външно беше невъзможно да се разбере, че той не прави нищо. В най-добрия случай той ще падне и някой ще го вдигне по-късно. По-точно, ще долети сигнал и някой ще отиде и ще го вдигне с ръце.
(6) И най-много боклук и отпадъци - това беше elasticsearch. Защото беше стара версия. Защото по това време нямахме посветени майстори. Имахме разнородни трупи, чиито полета можеха да се припокриват. Различни регистрационни файлове на различни приложения могат да бъдат записани с едни и същи имена на полета, но в същото време може да има различни данни вътре. Тоест, един журнал идва с цяло число в поле, например ниво. Друг дневник идва с низ в полето за ниво. При липса на статично картографиране се получава такова прекрасно нещо. Ако след ротация на индекса съобщение с низ пристигна първо в elasticsearch, значи живеем нормално. И ако първото пристигне с Integer, тогава всички следващи съобщения, пристигнали с String, просто се изхвърлят. Тъй като типът на полето не съвпада.
Започнахме да си задаваме тези въпроси. Решихме да не търсим виновни.
Но нещо трябва да се направи! Очевидното е, че трябва да установим стандарти. Вече имахме някои стандарти. Някои донесохме малко по-късно. За щастие единен формат на журнал за всички API вече беше одобрен по това време. Той е записан директно в стандартите за взаимодействие на услугата. Съответно тези, които искат да получават логове, трябва да ги пишат в този формат. Ако някой не пише регистрационни файлове в този формат, ние не гарантираме нищо.
Освен това бих искал да има единен стандарт за методите за записване, доставка и събиране на регистрационни файлове. Всъщност къде да ги напиша и как да ги доставя. Идеалната ситуация е, когато проектите използват една и съща библиотека. Има отделна библиотека за регистриране за Go, има отделна библиотека за PHP. Всички, които имаме, всички трябва да ги използват. В момента бих казал, че успяваме с 80 процента. Но някои продължават да ядат кактуси.
И там (на слайда) „SLA за доставка на журнали“ едва започва да се появява. Все още го няма, но работим по него. Защото е много удобно, когато инфра казва, че ако пишете в такъв и такъв формат на такова и такова място и не повече от N съобщения в секунда, тогава най-вероятно ще го доставим там. Премахва много главоболия. Ако има SLA, тогава е просто страхотно!
Как започнахме да решаваме проблема? Основният рейк беше с td-agent. Не беше ясно къде отиват нашите трупи. Доставени ли са? отиват ли Къде са те все пак? Затова беше решено да се замени td-agent с първия елемент. Варианти с какво да го заменя, накратко очертах тук.
Fluentd. Първо, срещнах го на предишна работа и той също периодично падаше там. Второ, това е същото, само в профил.
filebeat. Как беше добре за нас? Фактът, че той е в Go, а ние имаме голям опит в Go. Съответно, ако има нещо, бихме могли по някакъв начин да го добавим към себе си. Затова не го взехме. Така че дори няма да има изкушение да започнете да го пренаписвате за себе си.
Очевидното решение за sysadmin са всички видове syslogs в това количество (syslog-ng/rsyslog/nxlog).
Или напишете нещо свое, но ние го изхвърлихме, както и filebeat. Ако пишете нещо, тогава е по-добре да напишете нещо полезно за бизнеса. За да доставите трупи, е по-добре да вземете нещо готово.
Следователно изборът всъщност се сведе до избор между 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 файловият дескриптор се променя и docker губи този файл. Той държи отворено нещо друго, но не същия сокет, където пишат. Решихме, че ще заобиколим този проблем и в същото време ще заобиколим проблема с блокирането.
Rsyslog извършва действията, посочени на слайда, и изпраща регистрационни файлове към реле или Kafka. Кафка следва стария път. Rayleigh - Опитах се да използвам чист rsyslog за доставяне на регистрационни файлове. Без опашка за съобщения, използвайки стандартни инструменти за rsyslog. По принцип работи.
Но има нюанси с това как да ги пъхнете по-късно в тази част (Logstash/Graylog/ES). Тази част (rsyslog-rsyslog) се използва между центровете за данни. Ето компресирана tcp връзка, която ви позволява да спестите честотна лента и съответно по някакъв начин да увеличите вероятността да получим някои регистрационни файлове от друг център за данни, когато каналът е пълен. Защото имаме Индонезия, където всичко е лошо. Точно там се крие постоянният проблем.
Помислихме как всъщност наблюдаваме, с каква вероятност логовете, които записахме от приложението, достигат до този край? Решихме да започнем метрики. Rsyslog има свой собствен модул за събиране на статистика, който има някакъв вид броячи. Например, може да ви покаже размера на опашката или колко съобщения са дошли за такова и такова действие. Вече можете да вземете нещо от тях. Освен това има персонализирани броячи, които можете да конфигурирате, и ще ви покаже например броя на съобщенията, които някои API са записали. След това написах rsyslog_exporter на Python и изпратихме всичко на Prometheus и го начертахме. Наистина искахме метрики на Graylog, но досега не сме имали време да ги настроим.
Какви са проблемите? Проблемът възникна от факта, че разбрахме (ВНЕЗАПНО!), че нашите Live API пишат 50k съобщения в секунда. Това е само API на живо без етапи. И Graylog ни показва само 12 хиляди съобщения в секунда. И възникна резонният въпрос къде са останките? От което заключихме, че Graylog просто не може да се справи. Погледнахме и наистина Graylog с Elasticsearch не овладя този поток.
След това други открития, които сме направили по пътя.
Записите в сокет са блокирани. Как се случи това? Когато използвах rsyslog за доставка, в един момент прекъснахме канала между центровете за данни. Доставката стана на едно място, доставката стана на друго място. Всичко това се свежда до машина с API, които записват в сокета rsyslog. Имаше опашка. След това се запълни опашката за запис в unix socket, която по подразбиране е 128 пакета. И следващият write() в блоковете на приложението. Когато разгледахме библиотеката, която използваме в приложенията Go, там беше написано, че записът в сокета става в неблокиращ режим. Бяхме сигурни, че нищо не е блокирано. Защото сме чели който е писал за това. Но има момент. Имаше и безкраен цикъл около това обаждане, в който имаше постоянен опит да се вкара съобщение в сокета. Не го забелязахме. Трябваше да пренапиша библиотеката. Оттогава той се промени няколко пъти, но сега се отървахме от ключалките във всички подсистеми. Следователно можете да спрете rsyslog и нищо няма да падне.
Необходимо е да се следи размерът на опашките, което помага да не се стъпва върху този рейк. Първо, можем да наблюдаваме кога започваме да губим съобщения. Второ, можем да наблюдаваме, че основно имаме проблеми с доставката.
И още един неприятен момент - усилването с 10 пъти в микросервизна архитектура е много лесно. Нямаме толкова много входящи заявки, но поради графиката, по която тези съобщения вървят по-нататък, поради регистрационните файлове за достъп, всъщност увеличаваме натоварването на регистрационните файлове с около десет пъти. За съжаление нямах време да изчисля точните цифри, но микроуслугите са това, което са. Това трябва да се има предвид. Оказва се, че в момента подсистемата за събиране на логове е най-натоварена в Lazada.
Как да решим проблема с elasticsearch? Ако трябва бързо да получите регистрационни файлове на едно място, за да не минавате през всички машини и да ги събирате там, използвайте хранилище за файлове. Това гарантирано работи. Извършва се от всеки сървър. Просто трябва да залепите дискове там и да поставите syslog. След това гарантирано ще имате всички регистрационни файлове на едно място. Тогава ще бъде възможно бавно да конфигурирате elasticsearch, graylog или нещо друго. Но вече ще имате всички регистрационни файлове и освен това можете да ги съхранявате, доколкото има достатъчно дискови масиви.
Към момента на доклада ми схемата започна да изглежда така. На практика спряхме да пишем във файла. Сега най-вероятно ще изключим остатъците. На локални машини, работещи с API, ние ще спрем да пишем във файлове. Първо, има съхранение на файлове, което работи много добре. Второ, на тези машини постоянно им липсва място, трябва постоянно да ги наблюдавате.
Тази част с Logstash и Graylog наистина се издига. Следователно трябва да се отървете от него. Трябва да изберете един.
Решихме да изоставим Logstash и Kibana. Защото имаме отдел за сигурност. каква е връзката Връзката е, че Kibana без X-Pack и без Shield не ви позволява да разграничите правата за достъп до регистрационните файлове. Затова те взеха Грейлог. Има всичко. Не ми харесва, но работи. Купихме нов хардуер, инсталирахме нов Graylog там и преместихме всички регистрационни файлове със стриктни формати в отделен Graylog. Организационно сме решили проблема с различните видове едни и същи полета.
Какво точно е включено в новия Graylog. Току-що написахме всичко в докера. Взехме куп сървъри, внедрихме три екземпляра на Kafka, 7 Graylog сървъра версия 2.3 (защото исках Elasticsearch версия 5). Всичко това беше повдигнато при нападения от HDD. Видяхме скорост на индексиране до 100 хиляди съобщения в секунда. Видяхме цифрата, че 140 терабайта данни на седмица.
И отново рейк! Предстоят ни две продажби. Преминахме над 6 милиона публикации. Ние Graylog нямаме време да дъвчем. Някак си трябва да оцелееш отново.
Така оцеляхме. Добавени са още няколко сървъра и SSD. В момента живеем така. Сега вече дъвчем 160k съобщения в секунда. Все още не сме достигнали лимита, така че не е ясно колко реалистично можем да извлечем от него.
Това са нашите планове за бъдещето. От тях наистина най-важното вероятно е високата наличност. Все още го нямаме. Няколко коли се настройват по същия начин, но засега всичко минава през една кола. Необходимо е да отделите време за настройка на отказ между тях.
Събирайте показатели от Graylog.
Направете ограничение на скоростта, така че да имаме един луд API, който не ни убива честотната лента и всичко останало.
И накрая, подпишете някакъв вид SLA с разработчиците, за да можем да обслужваме толкова много. Ако пишеш повече, извинявай.
И напишете документация.
Накратко резултатите от всичко, което сме преживели. Първо, стандартите. Второ, syslog е торта. Трето, rsyslog работи точно както е написано на слайда. И да минем на въпросите.
Въпроси.
Въпрос: Защо решиха да не вземат ... (filebeat?)
Отговарям: Трябва да запишете във файл. Наистина не исках. Когато вашият API пише хиляди съобщения в секунда, дори ако редувате веднъж на час, това все още не е опция. Можете да пишете на тръба. На което разработчиците ме попитаха: „Какво ще стане, ако процесът, в който пишем, падне“? Просто не намерих какво да им отговоря и казах: "Е, добре, нека не правим така."
Въпрос: Защо просто не пишете регистрационни файлове в HDFS?
ОтговарямО: Това е следващата стъпка. Мислихме за това в самото начало, но тъй като в момента няма ресурси да се справим с него, то виси в нашето дългосрочно решение.
Въпрос: Формат на колона би бил по-подходящ.
Отговарям: Разбирам. Ние сме "за" с две ръце.
Въпрос: Вие пишете в rsyslog. Там са налични както TCP, така и UDP. Но ако UDP, тогава как гарантирате доставката?
ОтговарямО: Има две точки. Първо, веднага казвам на всички, че не гарантираме доставката на трупи. Защото, когато разработчиците дойдат и кажат: „Нека започнем да пишем финансови данни там и вие ще ги поставите някъде за нас, в случай че нещо се случи“, ние им отговаряме „Страхотно! Нека започнем да блокираме писането в сокета и да го направим в транзакциите, така че да гарантираме, че ще го поставите в сокета вместо нас и сме сигурни, че сме го получили от другата страна. И в този момент всички веднага стават ненужни. И ако не, тогава какви въпроси имаме? Ако не искате да гарантирате запис в сокета, тогава защо ще гарантираме доставка? Полагаме максимални усилия. Ние наистина се опитваме да доставим колкото е възможно повече и възможно най-добре, но не даваме 100% гаранция. Следователно не е необходимо да пишете финансови данни там. За това има транзакционни бази данни.
Въпрос: Когато API генерира някакво съобщение в регистрационния файл и прехвърли контрола на микроуслуги, срещали ли сте проблема, че съобщенията от различни микроуслуги пристигат в грешен ред? Поради това възниква объркване.
ОтговарямО: Нормално е да идват в различен ред. Трябва да сте готови за това. Тъй като всяка мрежова доставка не ви гарантира ред или трябва да изразходвате специални ресурси за това. Ако вземем файлови хранилища, тогава всеки API записва регистрационни файлове в свой собствен файл. По-скоро rsyslog ги разлага в директории там. Всеки API има свои собствени регистрационни файлове там, където можете да отидете и да погледнете, а след това можете да ги сравните, като използвате клеймото за време в този журнал. Ако отидат да потърсят в Graylog, тогава там ще бъдат сортирани по времево клеймо. Там всичко ще е наред.
Въпрос: Времето може да варира с милисекунди.
Отговарям: Времето се генерира от самия API. Това всъщност е целият смисъл. Имаме NTP. API генерира клеймо за време вече в самото съобщение. Не се добавя от rsyslog.
Въпрос: Взаимодействието между центровете за данни не е много ясно. В рамките на центъра за данни е ясно как са събрани и обработени регистрационните файлове. Как е взаимодействието между центровете за данни? Или всеки център за данни живее свой собствен живот?
Отговарям: Почти. Имаме всяка държава, разположена в един център за данни. Понастоящем нямаме разпръскване, така че една държава да бъде поставена в различни центрове за данни. Следователно не е необходимо да ги комбинирате. Във всеки център има лог реле. Това е Rsyslog сървър. Всъщност две машини за управление. Те са настроени по същия начин. Но засега трафикът минава само през един от тях. Тя регистрира всички агрегати. Има дискова опашка за всеки случай. Тя натиска дневниците и ги изпраща в централния център за данни (Сингапур), където по-нататък те вече са отровени в Graylog. И всеки център за данни има собствено хранилище за файлове. В случай, че загубим връзка, имаме всички регистрационни файлове там. Те ще останат там. Те ще бъдат съхранявани там.
Въпрос: Получавате ли регистрационни файлове от там при необичайни ситуации?
Отговарям: Можете да отидете там (до файловото хранилище) и да погледнете.
Въпрос: Как следите да не губите регистрационни файлове?
Отговарям: Ние всъщност ги губим и го следим. Мониторингът започна преди месец. Библиотеката, която API на Go използва, има показатели. Тя може да преброи колко пъти не е успяла да напише в сокет. В момента има сложна евристика. Там има буфер. Опитва се да напише съобщение от него към сокета. Ако буферът се препълни, той започва да ги изпуска. И брои колко ги е изпуснал. Ако гишетата започнат да преливат там, ще разберем за това. Сега идват и в prometheus, а можете да видите графиките в Grafana. Можете да настроите сигнали. Но все още не е ясно на кого да бъдат изпратени.
Въпрос: В elasticsearch съхранявате журнали с излишък. Колко реплики имате?
Отговарям: Една реплика.
Въпрос: Само един ред ли е?
Отговарям: Това е майсторът и репликата. Данните се съхраняват в два екземпляра.
Въпрос: Променихте ли по някакъв начин размера на rsyslog буфера?
Отговарям: Пишем дейтаграми в персонализиран Unix сокет. Това веднага ни налага ограничение от 128 килобайта. Не можем да напишем повече в него. Записали сме това в стандарта. Който иска да влезе в хранилището, те пишат 128 килобайта. Освен това библиотеките се отрязват и се поставя флаг, че съобщението е отрязано. Имаме специално поле в стандарта на самото съобщение, което показва дали е отрязано по време на запис или не. Така че имаме възможност да проследим този момент.
Въпрос: Пишете ли повреден JSON?
Отговарям: Повреденият JSON ще бъде отхвърлен или по време на препредаване, защото пакетът е твърде голям. Или Graylog ще бъде премахнат, защото няма да може да анализира JSON. Но тук има нюанси, които трябва да бъдат коригирани и те са свързани най-вече с rsyslog. Вече попълних няколко въпроса там, върху които все още трябва да се работи.
Въпрос: Защо Кафка? Опитвали ли сте RabbitMQ? Graylog не се събира при такива натоварвания?
Отговарям: Не се получава с Graylog. И Graylog се оформя. За него наистина е проблемно. Той е нещо като нещо. И всъщност не е необходимо. Предпочитам да пиша от rsyslog директно на elasticsearch и след това да гледам Kibana. Но трябва да уредим въпроса с охраната. Това е възможен вариант на нашето развитие, когато изхвърлим Graylog и използваме Kibana. Logstash няма да има смисъл. Защото мога да направя същото с rsyslog. И има модул за писане в elasticsearch. С Graylog се опитваме да живеем по някакъв начин. Дори го коригирахме малко. Но все още има място за подобрение.
За Кафка. Така се е случило исторически. Когато пристигнах, вече беше там и вече се записваха логове в него. Току-що повдигнахме нашия клъстер и преместихме трупи в него. Ние го управляваме, знаем как се чувства. Що се отнася до RabbitMQ... имаме проблеми с RabbitMQ. И RabbitMQ се развива за нас. Имаме го в производство и имаше проблеми с него. Сега, преди продажбата, той ще бъде шаманизиран и ще започне да работи нормално. Но преди това не бях готов да го пусна в производство. Има още един момент. Graylog може да чете AMQP 0.9 версия, а rsyslog може да записва AMQP 1.0 версия. И няма нито едно решение, което да прави и двете по средата. Има или едното, или другото. Така че засега само Кафка. Но има и нюанси. Тъй като omkafka на версията на rsyslog, която използваме, може да загуби целия буфер на съобщенията, който е събрал от rsyslog. Стига сме го търпели.
Въпрос: Използвате ли Kafka, защото сте го имали? Не се използва за друга цел?
Отговарям: Kafka, който беше използван от екипа на Data Science. Това е съвсем отделен проект, за който, за съжаление, не мога да кажа нищо. Не знам. Тя беше ръководена от екипа на Data Science. Когато започнаха трупите, решиха да го използват, за да не слагат свои. Сега актуализирахме Graylog и загубихме съвместимост, защото има стара версия на Kafka. Трябваше да си направим сами. В същото време се отървахме от тези четири теми за всеки API. Направихме един широк топ за всички на живо, един широк широк топ за всички сцени и просто снимаме всичко там. Graylog извлича всичко това паралелно.
Въпрос: Защо ни трябва този шаманизъм със сокетите? Опитвали ли сте да използвате драйвера на syslog log за контейнери.
Отговарям: По времето, когато зададохме този въпрос, имахме обтегнати отношения с докера. Беше докер 1.0 или 0.9. Самият Docker беше странен. Второ, ако му набуташ и логове ... имам непотвърдено подозрение, че минава всички логове през себе си, през докер демона. Ако имаме един API, който полудява, тогава останалите API ще се сблъскат с факта, че не могат да изпращат stdout и stderr. Не знам докъде ще доведе това. Имам подозрение на ниво усещане, че не е необходимо да използвам драйвера на docker syslog на това място. Нашият отдел за функционално тестване има собствен Graylog клъстер с регистрационни файлове. Те използват драйвери за докерски журнал и всичко изглежда наред там. Но веднага пишат GELF на Graylog. В момента, в който започнахме всичко това, ни трябваше просто да работи. Може би по-късно, като дойде някой и каже, че от сто години работи нормално, ще опитаме.
Въпрос: Доставяте между центровете за данни с помощта на rsyslog. Защо не на Кафка?
Отговарям: Ние правим това и това е наистина така. По две причини. Ако каналът е напълно мъртъв, тогава всички наши трупи, дори и в компресирана форма, няма да се изкачат през него. И kafka им позволява просто да загубят в процеса. По този начин се отърваваме от залепването на тези трупи. Ние просто използваме Kafka в този случай директно. Ако имаме добър канал и искаме да го освободим, тогава използваме техния rsyslog. Но всъщност можете да го настроите така, че да изпуска това, през което не е преминал. В момента просто използваме rsyslog доставка директно някъде, някъде Kafka.
Източник: www.habr.com