Логи - важлива частина системи, що дозволяє зрозуміти, що вона працює (або не працює), як очікується. В умовах мікросервісної архітектури робота з логами стає окремою дисципліною спеціальної олімпіади. Потрібно вирішити відразу купу питань:
- як писати логи із додатка;
- куди писати логі;
- як доставляти логи для зберігання та обробки;
- як обробляти та зберігати логи.
Застосування популярних нині технологій контейнеризації додає пісочок поверх граблів на полі варіантів розв'язання задачі.
Якраз про це розшифровка доповіді Юрія Бушмельова «Карта граблів на полі збирання та доставки логів»
Кому цікаво, прошу під кат.
Мене звуть Юрій Бушмельов. Я працюю в 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. Тобто весь цей бардак падав у результаті туди. Так не треба робити!
Ось так це виглядає, якщо віддалено зверху подивитися. Не потрібно так робити! Тут цифрами відразу відзначені проблемні місця. Їх насправді більше, але шість - це ось прям зовсім проблемні, з якими треба щось робити. Про них я зараз окремо розповім.
Ось тут (1,2,3) у нас пишуться файли і, відповідно, тут одразу три граблі.
Перше — це нам треба їх кудись писати. Не завжди хотілося б давати API можливість писати у файл. Бажано, щоб API була ізольована у контейнері, а ще краще – щоб вона була read-only. Я — сісадмін, тож маю трохи альтернативний погляд на ці речі.
Другий момент (2,3) — у нас багато запитів надходить до API. API пише багато даних у файл. Файли зростають. Нам їх треба ротувати. Бо інакше там жодних дисків не напасешся. Роти їх погано, тому що вони зроблені редиректом через shell в каталог. Ми ніяк не можемо його відротувати. Не можна сказати додатку, щоб він перевідкрив дескриптори. Тому що розробники на тебе подивляться як на дурня: Які дескриптори? Ми взагалі у stdout пишемо». Інфраструктурники зробили копіютрункування в logrotate, який робить просто копію файлу і транкейтит оригінал. Відповідно, між цими процесами копіювання зазвичай і закінчується місце на диску.
(4) У нас були різні формати в різних API. Вони трохи відрізнялися, але regexp треба було писати різні. Оскільки все це керувалося Puppet, то там була велика в'язанка класів зі своїми тарганами. Плюс ще td-agent більшу частину часу міг їсти пам'ять, тупити, він міг просто вдавати, що він працює, і нічого не робити. Зовні зрозуміти, що він нічого не робить було неможливо. У кращому разі він упаде, і його хтось підніме потім. Точніше, прилетить alert, і хтось піде руками підніме.
(6) І самий треш і чад - це був еластичнийдослідження. Тому що це була стара версія. Тому що у нас не було виділених майстрів на той момент. Ми мали різнорідні логи, у яких поля могли перетинатися. Різні логи різних програм могли писатися з однаковими назвами полів, але при цьому всередині могли бути різні дані. Тобто один лог приходить з Integer в поле, наприклад, level. Інший лог приходить зі String у полі level. За відсутності статичного мапінгу виходить така чудова річ. Якщо після ротації індексу в еластичномудослідженні першим прилетіло повідомлення з рядком, то ми живемо нормально. А якщо ось першим прилетіло з 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 змінюється файл 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, і нічого не впаде.
Потрібно моніторити розмір черг, що допомагає не наступити на ці граблі. По-перше, ми можемо моніторити, коли ми починаємо втрачати повідомлення. По-друге, можемо моніторити, що у нас в принципі проблеми з доставкою.
І ще неприємний момент — ампліфікація вдесятеро в мікросервісній архітектурі — це дуже легко. У нас вхідних запитів не так багато, але через граф, яким бігають ці повідомлення далі, через access-логів, ми реально збільшуємо навантаження по логах приблизно раз на десять. Я на жаль не встиг порахувати точні цифри, але мікросервіси вони такі. Це треба мати на увазі. Виходить, що на даний момент підсистема збирання логів найнавантаженіша в Lazada.
Як вирішити проблему еластичногодослідження? Якщо потрібно швидко отримати логи в одному місці, щоб не бігати всіма машинами, і не збирати їх там, використовуйте файлове сховище. Це гарантовано працює. Воно робиться із будь-якого сервера. Треба просто натикати туди дисків і встановити syslog. Після цього у вас гарантовано в одному місці всі логі є. Далі вже можна буде неспішно налаштовувати еластичнийдослідження, 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 до повідомлень за секунду. Ми ще не вперлися в ліміт, тому поки що незрозуміло, скільки реально зможемо витягти з цього.
Ось такі плани на майбутнє. З них, реально, найважливіше, мабуть, висока availability. У нас його поки що немає. Декілька машин налаштовані однаково, але їде поки що все через одну машину. Потрібно витратити час, щоб налаштувати failover між ними.
Зібрати метрики з Graylog.
Зробити rate limit щоб у нас одна, збожеволіла API, не вбивала нам bandwidth і все інше.
І нарешті, підписати якийсь SLA з розробниками, що ми можемо обслужити ось стільки. Якщо ви пишете більше, вибачте.
І написати документацію.
Коротько, підсумки всього, що ми пережили. По-перше, стандарти. По-друге, syslog – торт. По-третє, rsyslog працює саме так, як написано на слайді. І давайте перейдемо до питань.
Питання.
питання: Чому все-таки вирішили не брати ... (filebeat?)
відповідь: Треба писати у файл Дуже не хотілося. Коли у тебе API пише тисячі повідомлень за секунду, ти навіть якщо раз на годину ротуватимеш, то це все одно не варіант. Можна писати у pipe. На що мене розробники запитали: «А що буде якщо процес, в який ми пишемо, впаде»? Я просто не знайшов, що їм відповісти, і сказав: «Ну, давайте ми не будемо так робити».
питання: Чому ви не пишете логи просто в HDFS?
відповідь: Це наступний етап Ми про нього подумали на самому початку, але оскільки в даний момент немає ресурсів цим займатися, то він у нас висить у long term solution.
питання: Колонковий формат був би більш підходящим
відповідь: Я все розумію. Ми «за» обома руками.
питання: Ви пишіть у rsyslog Там можна і TCP, і UDP. Але якщо UDP, тоді як ви гарантуєте доставку?
відповідь: Є два моменти Перший, я одразу всім говорю, що ми не гарантуємо доставку логів. Тому що, коли розробники приходять і кажуть: «А давайте ми туди почнемо писати фінансові дані, а ви їх нам кудись складатимемо на випадок, якщо щось трапиться», ми їм відповідаємо «Відмінно! Давайте ви почнете блокуватися на записи в сокет і робити це в транзакціях, щоб гарантовано ви нам це в сокет поклали і переконалися, що ми з того боку це отримали». І в цей момент усім одразу стає не треба. А якщо не треба, то які до нас запитання? Якщо ви не бажаєте гарантувати запис у сокет, то навіщо нам гарантувати доставку? Ми робимо кращий ефект. Ми реально намагаємося доставити якнайбільше і якнайкраще, але ми не даємо 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 можна подивитися графіки. Можна налаштувати оповіщення. Але поки що незрозуміло, кому їх відправляти.
питання: У еластичномувишукуванні ви з резервуванням зберігаєте логи. Скільки у вас реплік?
відповідь: Одна репліка
питання: Це всього одна репліка?
відповідь: Це майстер та репліка У двох примірниках дані зберігаються.
питання: Розмір буфера rsyslog ви якось підкручували?
відповідь: Ми пишемо дейтаграми в кастомний unix socket Це нам відразу накладає обмеження 128 кілобайт. Ми не можемо записати до нього більше. Ми прописали це у стандарт. Хто хоче потрапляти до стореджів, ті пишуть 128 кілобайт. Бібліотеки, причому, обрізають і ставлять прапор, що повідомлення обрізане. У нас стандарті самого повідомлення є спеціальне поле, яке показує, чи було воно обрізане при записі чи ні. Отже, ми маємо можливість відстежити і цей момент.
Питання: Чи пишете ви биті JSON?
відповідь: Побитий JSON буде відкинуто або під час relay, тому що занадто великий пакет. Або буде відкинуто Graylog, тому що не зможе JSON розпарити. Але тут є нюанси, які треба фіксувати, і вони здебільшого зав'язані на rsyslog. Я вже заповнив туди кілька issue, над якими треба ще працювати.
Питання: Чому Kafka? Чи пробували RabbitMQ? Чи не складається Graylog при таких навантаженнях?
відповідь: У нас із Graylog не складається А Graylog у нас складається. Із ним реально проблемно. Він своєрідна штука. І насправді він не потрібен. Я б вважав за краще писати з rsyslog безпосередньо в еластичномудослідженні і дивитися потім Kibana. Але треба вгамувати питання з безпеками. Це можливий варіант нашого розвитку, коли ми викинемо Graylog та будемо використовувати Kibana. Logstash використовувати сенс не буде. Тому що, я можу все це ж зробити rsyslog. І він має модуль для запису в еластичномудослідженні. З 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