Чому Fluentd втрачає логи під піковим навантаженням
Піковий трафік ламає збір логів не в момент запису, а в момент відправлення. Агент Fluentd на вузлі приймає події від застосунків швидше, ніж встигає віддати їх у сховище, і складає їх у буфер — спочатку в пам'ять, потім на диск.
Коли відведене під чергу місце закінчується, спрацьовує політика переповнення: агент починає відкидати найстаріші блоки. Саме тому логи зникають рівно в той момент, коли триває розбір інциденту і вони потрібні найбільше.
Вузьке місце збору рідко буває одне.
Різні формати логів обробляються різними фільтрами: структурований JSON розбирається швидко, а багаторядкові трасування й нерегулярний потік від веб-сервера потребують регулярних виразів і склеювання за таймаутом — на кожному рядку це коштує процесорного часу. Чим більше рядків за одиницю часу, тим повільніше фільтри й тим швидше зростає черга.
Під час розбору інциденту картина повторюється: черга на вузлі зросла до межі за лічені хвилини, інтервал скидання буфера не встигає її розвантажувати, дискове сховище черги переповнене.
Частина подій дійшла до центрального сховища, частина залишилася в блоках, які вже видалені під час ротації. Відновити хронологію за обрізаними даними неможливо — зникла саме межа збою.
Розбираємо, як це закривається: рахуємо реальну пропускну здатність агента на вузлі, задаємо буферизацію із запасом по диску, обираємо політику переповнення, яка зберігає свіжі події, і приводимо різні формати логів до єдиної схеми до відправлення.
Що дає централізований збір логів і де виграш
Коли логи лежать на кожному вузлі окремо, розбір інциденту починається з обходу машин, а не з гіпотези.
Інженер звіряє хости, часові пояси й версії, втрачає контекст між контейнерами одного запиту — час пошуку за логами зростає разом із кількістю вузлів, а вартість простою рахують, поки діагнозу ще немає.
Централізоване логування знімає цей етап. Агент Fluentd збирає вивід контейнерів і системні журнали, склеює багаторядкові повідомлення в одну подію, додає метадані — вузол, сервіс, оточення — і розкладає потоки за тегами, щоб шум застосунку не змішувався з журналом ядра.
Буфер на диску переживає недоступність приймача: під час обриву зв'язку агент пригальмовує читання й доставляє накопичене пізніше, а не втрачає записи.
Далі виграш стає вимірюваним. Пошук за логами перетворюється на один запит за метаданими, розбір інциденту — на перегляд ланцюжка подій одного запиту за ідентифікатором кореляції.
Частка відновлених подій зростає: нічого не зрізається на етапі збору, тому картину збирають навіть за збоями, які раніше списували на «немає даних».
Змінюється й клас відмов. Зникає сценарій «збій помітили, причину не знайшли» — залишаються записи з точним часом, вузлом і версією збірки.
Термін зберігання задається політикою за тегами: об'ємні технічні повідомлення йдуть у холодне сховище, а помилки й події доступу залишаються під рукою довше.
Режими роботи Fluentd: агент на вузлі, служба, шлюз
Fluentd — це не лише агент на кожному вузлі. Той самий збирач розгортають у трьох режимах, і вибір визначає, де накопичується буфер, скільки ресурсів витрачає застосунок і що станеться під час обриву каналу до приймача. Нижче — варіанти, між якими реально обирають.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Агент на вузлі | Застосунок пише у файл, джерело одне, важливе мінімальне навантаження на сервіс | Немає спільної точки агрегації: правила розмазані по хостах, під час шторму логів буфер зростає поруч із робочим процесом |
| Служба на виділеному вузлі | Кілька сервісів на хості, потрібен єдиний конфіг і розбір форматів | Вузол стає точкою відмови, потрібні резерв і жорсткі ліміти за пам'яттю |
| Шлюз збору | Багато джерел, неоднорідні формати, потрібні маршрутизація й збагачення | З'являється проміжна ланка в шляху, шлюз треба масштабувати й захищати від втрати буфера |
Режим буферизації підбирається під вимоги до відмовостійкості збору. Буфер у пам'яті дає максимальну швидкість, але втрачається під час перезапуску процесу; буфер на диску з обмеженням за розміром і кількістю чанків переживає падіння агента й розрив зв'язку з приймачем.
Схема «легкий агент на вузлі плюс шлюз збору з дисковим буфером» розвантажує застосунки: мережу й повторні відправлення бере на себе шлюз, а не сам сервіс.
Етапи впровадження централізованого логування
Порядок робіт будується так, щоб кожен крок спирався на дані попереднього.
Починаємо не зі встановлення агентів, а з інвентаризації: поки невідомо, скільки джерел і в яких вони форматах, маршрутизація перетворюється на вгадування й виринає втраченими записами під час першого ж розбору інциденту.
-
Інвентаризація джерел. Перелік сервісів, файлів, системних журналів і контейнерів: формат запису (структурований JSON, неструктурований текст, багаторядкові трасування), швидкість зростання, власник. На виході — таблиця з черговістю підключення: кого беремо в першій хвилі, кого свідомо відкладаємо.
-
Схема потоків. Маршрут «агент на вузлі → агрегатор → сховище», з буферизацією на диску й заданою поведінкою за недоступності приймача. Теги й мітки (сервіс, оточення, вузол) фіксуємо заздалегідь — за ними потім будуються вибірки й алерти.
-
Налаштування збору й розбору. Конфігурації Fluentd — парсери, фільтри, розміри буферів, повтори за помилок — тримаємо в репозиторії й змінюємо через рев'ю, а не правкою на сервері.
-
Пілотна група. Три-п'ять сервісів із різними форматами логів. Перевіряємо втрати під час обриву мережі, навантаження від агента на вузол і коректність розбору багаторядкових записів.
-
Перевірка повноти логів. Звіряємо кількість записів на джерелі й у сховищі, шукаємо пропуски на піках навантаження. Критерій приймання — розходження в заданих межах, а не «наче все надходить».
-
Передавання в експлуатацію. Інструкції щодо типових збоїв, оповіщення на відставання доставки й переповнення буфера, регламент підключення нового джерела — щоб сервіси додавалися без нашої участі.
Що замовник отримує: конфігурації Fluentd і регламенти
Робота закінчується не запущеним сервісом, а комплектом артефактів, який ваша команда супроводжує своїми силами.
Кожен пункт передаємо у вигляді, придатному для правок без нас: конфігурації лежать у репозиторії, рішення щодо маршрутизації описані словами, а не лише в голові інженера.
- Конфігурації збору — описи джерел, фільтрів розбору й маршрутів виводу єдиним набором файлів у репозиторії. Зміни проходять перевірку на тестовому контурі: збирач піднімається з новим набором, проганяє еталонні події й лише потім іде в робочий контур.
- Схеми потоків — звідки й куди йде кожен тип подій, де стоїть буфер на диск, де події збагачуються, а де відкидаються як дублі. Схема дозволяє за хвилину зрозуміти, чому запис із конкретного сервісу не дійшов до сховища.
- Політики доступу — які команди бачать які набори логів, які поля маскуються до запису, як видаються й відкликаються токени збирачів. Окремо фіксуємо, що робити під час звільнення співробітника або зміни підрядника.
- Правила зберігання й очищення — скільки живуть події у швидкому доступі, що йде в архів, за яким віком видаляється решта. Сховище перестає зростати безконтрольно, при цьому вікно для розбору інциденту залишається достатнім.
- Регламент чергування — кому й у який канал надходить сигнал у разі відмови збирача або втрати потоку, за який час потрібна реакція, що вважається інцидентом, а що штатною деградацією.
- Метрики самого конвеєра — затримка доставки, заповнення буфера, частка відкинутих записів. За ними видно проблему до того, як про неї повідомить розробка.
- Документація — покрокові інструкції «як підключити нове джерело» й «як розібрати типові відмови», із прикладами готових блоків конфігурації.
Приймання проводимо на живому сценарії: гасимо один вузол збору й перевіряємо, що події не втрачаються, а після відновлення доїжджають цілком.
Кейс: розбір інциденту за логами замість годин пошуку
До: логи були, а картини інциденту не було
Сервіс працював на десятку вузлів, і кожен писав у локальний файл із ротацією за розміром.
Під час збою інженер йшов по машинах через термінал, зіставляв відмітки часу вручну — і все одно не бачив ланцюжок цілком: частина подій губилася під час ротації, частина залишалася на вузлі, який на момент розбору вже вивели з балансування.
Повнота логів трималася близько 60%, пошук потрібної події займав 40-60 хвилин, відновлення сервісу розтягувалося на години.
Що змінили
Зібрали єдиний контур: Fluentd на агрегації та легкий агент на вузлах із дисковим буфером, який переживає обрив зв'язку, перезапуск агента й перезавантаження машини.
Кожен запис розмітили метаданими — сервіс, середовище, версія релізу, ідентифікатор запиту — і привели до єдиного формату на вході, тому пошук іде за полями, а не за текстом.
Політику зберігання прив'язали до цінності даних: часті технічні події живуть дні, помилки й сліди змін — місяцями.
Після: інцидент розбирається за одним запитом
Повнота логів зросла до 99%: втрати на ротації й обривах зв'язку зникли, а пропуски відправлення агент досилає з буфера після відновлення каналу.
Пошук події займає 2-3 хвилини замість години, час відновлення сервісу скоротився приблизно вчетверо — черговий бачить послідовність від першого збою до каскаду, а не збирає її за фрагментами.
Навантаження на вузли при цьому знизилося: один робочий потік із налаштовуваним лімітом пам'яті виявився легшим за попередній важкий збирач.
На тому самому контурі пізніше підключили метрики й трасування — точки відмови тепер зіставляються з логами за спільними метаданими, і розбір не починається заново для кожного нового інструмента.
Чим Fluentd відрізняється від Fluent Bit і що вибрати
Це не два конкуруючі продукти, а два рівні однієї схеми збору. Fluent Bit ставлять на кожен вузол як легкий агент: він читає stdout контейнерів і файли журналів, додає метадані (ім'я пода, namespace, мітки) і відправляє далі.
Fluentd займає місце центрального агрегатора, де потрібні повноцінна маршрутизація, фільтрація й роздача в кілька приймачів.
Різниця видна в споживанні ресурсів. Fluent Bit — один статично зібраний виконуваний файл без зовнішніх залежностей, тому десятки вузлів не дають помітного навантаження й агент не конкурує з робочими сервісами за пам'ять.
Fluentd — середовище з великим набором плагінів і гнучкими буферами на диску, він вимогливіший і розгортається там, де ресурсів явно достатньо.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Fluent Bit на кожному вузлі | Збір логів контейнерів і файлів, мінімум навантаження на вузлі | Проста маршрутизація, складні перетворення незручні |
| Fluentd як агрегатор | Централізована обробка, фільтри, доставка в кілька сховищ | Вимогливий до пам'яті, не місце на кожному вузлі |
| Fluent Bit → Fluentd | Кластери з десятками вузлів: економія на вузлах плюс складна логіка | Більше ланок: стежити за буферами й повторами під час збоїв |
Практичний критерій простий. Якщо завдання — доставити логи з вузла без втрат і без зростання споживання, достатньо Fluent Bit із налаштуванням дискового буфера й повторів за недоступності приймача.
Якщо з'являються розгалуження потоків за мітками, маскування полів, дедуплікація, склеювання багаторядкових записів і роздача в кілька систем одночасно — це робота для Fluentd.
Змішана схема закриває обидві вимоги: на вузлах залишається дешевий агент, а вся логіка переїжджає на шар агрегації. Тоді зміна маршрутизації не потребує перезапуску агентів на кожній машині, а буфери на двох рівнях згладжують недоступність сховища.
Далі розбираємо, як ця схема налаштовується й які параметри буферів визначають, чи втратяться записи під час перезапуску вузла.
Технічні сумніви перед впровадженням логування
На етапі оцінки майже завжди виринає той самий набір сумнівів: застосунки пишуть логи по-різному, у рядках опиняються персональні дані, незрозуміло, скільки все це зберігати й чи не почне збір гальмувати робочі сервіси. Нижче — як ми закриваємо кожен із них конфігурацією, а не обіцянками.
А якщо в нас десятки сервісів із різними форматами логів?
Агент ставиться поруч із застосунком і приводить потік до структурованого вигляду: для кожного джерела описується своє правило розбору, а неструктурований текст зберігається як є з мітками контейнера й пода.
На виході — єдина схема полів, тому пошук, оповіщення й дашборди працюють однаково для всіх сервісів, а не переписуються під кожен.
Як бути з персональними даними в логах?
Маскування виконується на стороні агента, до відправлення: фільтри вирізають значення за іменами полів і шаблонами, усе інше відсікається за білим списком.
У сховище потрапляє вже знеособлений потік, тому термін зберігання перестає залежати від вимог до захисту персональних даних.
Скільки зберігати й чи не зросте реєстр нескінченно?
Політика задається за класом даних: свіжі логи лежать у швидкому сховищі, потім автоматично переїжджають у дешевий архів і видаляються за розкладом.
Для прикладних логів і журналів доступу терміни різні — реєстр не зростає нескінченно, при цьому вікно для розбору інциденту залишається достатнім.
Чи не сповільнить логування робочі сервіси й як запускати поетапно?
Агент працює окремим процесом, пише буфер на диск і обмежений за процесором і пам'яттю. Якщо приймач недоступний, буфер переживає перезапуск, а застосунок продовжує відповідати — збір логів не потрапляє в критичний шлях запиту.
Стартуємо з пілотного контуру: звіряємо повноту й втрати на одній групі сервісів, потім розкочуємо на решту, з можливістю відкотити конфігурацію на агенті.
Обговоримо ваше завдання з логування
Щоб оцінка була предметною, а не «на око», достатньо кількох вступних: які джерела пишуть логи (застосунки, системні служби, контейнери, балансувальники), приклади реальних записів за годину-дві й поточний шлях цих записів — куди вони йдуть і в якому обсязі.
За рядками відразу видно, де потрібен розбір і збагачення полів, а де достатньо доставки, і це змінює і конфігурацію, і терміни.
Далі розбираємо схему цілком: агенти на вузлах або набір демонів у кластері, буферизація на диск за недоступності приймача, мітки й маршрутизація в кілька сховищ, обмеження зростання індексів.
Після розбору повертаємося з планом, оцінкою термінів і складом робіт — без абстрактних формулювань.
Що входить у розбір і що ви отримуєте на виході:
- Перелік джерел і розмітку: які поля витягуємо з рядків, що залишаємо в початковому вигляді.
- Схему доставки: де стоять агенти, як налаштовані черги, що відбувається під час обриву зв'язку з приймачем.
- План впровадження за етапами: пілот на одному контурі, перевірка повноти й втрат, потім розкочування на решту.
- Оцінку термінів і трудовитрат за кожним етапом із точками контролю й ознаками готовності.
- Конфігурації Fluentd, схему потоків і правила зберігання — з розрахунком, як швидко зростає обсяг.
- Регламент підтримки після запуску: реакція на збої доставки, оновлення конфігурацій, чергування.
- Інструкції для вашої команди: як додати нове джерело й не зламати розбір наявних.
Опишіть завдання в тому обсязі, який є на руках, — повернемося з планом впровадження, оцінкою термінів і зрозумілою зоною відповідальності після запуску.
