Налаштування конвеєра агрегації логів: збір, зберігання, візуалізація

Чому агрегація логів ламається зі зростанням навантаження

Поки вузлів десяток, логи живуть у файлах на дисках, а інцидент розбирають через ssh і grep.

Коли серверів стає більше, а трафік зростає, ручний обхід перестає працювати: щоб відновити картину збою, інженер послідовно заходить на кожен вузол, згадує шляхи до журналів і звіряє мітки часу. На розбір одного інциденту йдуть години, і весь цей час причина залишається неясною.

Перша точка відмови — агент на самому вузлі.

На піковому навантаженні потік записів перевищує пропускну здатність відправлення, і якщо буфер агента переповнюється, частина рядків відкидається мовчки: у сховище потрапляє неповна картина, а найгірше — губляться саме сплески помилок, заради яких логи й збирають.

Хвіст журналу при цьому виглядає правдоподібно, і відсутність записів помічають лише під час розбору.

Друга — ротація швидша за вивезення. Локальний файл обрізається за розміром або строком зберігання раніше, ніж його встигають забрати, і записи зникають безповоротно.

Паралельно обсяг зростає лавиноподібно: повторювані помилки в циклі, багаторядкові трасування, налагоджувальний рівень на проді — усе це роздуває потік, здорожує зберігання й уповільнює пошук, бо потрібне тоне в шумі.

Розбираємо, як це закривається: де ставляться обмеження на боці агента, як вибудовується черга зі зворотним тиском і чому вивезення має випереджати ротацію.

Вимірний ефект єдиної системи збору подій

Єдина система збору подій вимірюється не числом підключених сервісів, а чотирма показниками: часом розбору інциденту, часткою втрачених записів, числом пропущених спрацювань і глибиною ретроспективи.

Поки події залишаються в локальних файлах із ротацією за розміром, розслідування починається з ручного обходу машин, а частина записів на момент розбору вже перезаписана.

Наскрізний пошук по всіх сервісах

Ідентифікатор запиту прокидається через сервіси й стає обов’язковим полем кожного запису — єдина точка пошуку відповідає на питання «що відбувалося з цим запитом» одним фільтром, без перемикання між консолями.

Агенти збору буферизують записи на диск і досилають їх після перезапуску сервісу, тому частка втрачених записів знижується з одиниць відсотків до десятих часток відсотка в межах вікна зберігання.

Зберігання будується на індексах із налаштовуваним строком життя — наприклад, на OpenSearch: гарячі дані тримаються для швидких запитів, старі витісняються у стиснені сегменти, і обсяг зберігання перестає зростати лінійно від трафіку.

Скорочення часу розбору інциденту

Коли сигнал про помилку, метрика й записи сервісу лежать в одному інтерфейсі, черговий переходить від «сервіс відповідає помилками» до конкретного запиту та його ланцюжка викликів за хвилини, а не години.

Правила оповіщення описуються за полями подій, а не за рядками логів, тому число пропущених спрацювань падає: перевірка не губиться при зміні формулювання тексту помилки.

Ретроспектива на кілька тижнів показує, був збій одиничним чи накопичувався, — і це підтверджується тими самими даними, без вивантажень з архівів хостів.

Варіанти агрегації логів: агент, черга, потік

Схема доставки вирішує, що станеться із записом, якщо приймач недоступний. Прямий збір агентом, буферизація через чергу та потокова обробка на льоту відрізняються точкою, у якій лог губиться або дублюється.

Коли достатньо прямого збору

Якщо джерел десятки і приймач відповідає передбачувано, агент на кожній ноді пише напряму — менше рухомих частин і місць, де рветься маршрут. Плата за простоту: накопичення немає, при тривалому простої приймача записи губляться. Схему беруть, коли лог потрібен для спостереження, а не для розбору інцидентів.

Коли потрібна буферизація й повторне доставлення

Черга розв’язує джерело та приймач: агент віддає запис і забуває про нього, брокер тримає його до підтвердження приймання. Повторне доставлення після збою стає штатним режимом, але з’являються дублікати — у сховищі потрібен ключ, що згортає запис.

Потокова обробка додає розбір і збагачення до запису, а гібридна схема з’єднує агент на джерелі, чергу як буфер і потоковий обробник перед сховищем.

Порядок упровадження: від аудиту потоків до передачі

Порядок робіт побудовано хвилями: кожен етап закінчується перевірюваним результатом — схемою, конфігурацією колектора або звітом про повноту доставлення.

До того як конвеєр агрегації логів стане основним інструментом розбору інцидентів, замовник бачить стан системи й знає, де вузькі місця.

1. Аудит джерел подій. Обходимо сервіси, планувальники та мережеві вузли, фіксуємо формати записів, добовий і піковий обсяг, власника кожного джерела.
2. Схема потоків і маршрутів. Визначаємо, де стоїть колектор, що буферизує до відправлення, які типи записів ідуть в оперативне сховище, а які в архів, і на який строк.
3. Налаштування колекторів. Розбір структурованих записів на поля, єдині мітки сервісу й середовища, ліміти на сплески — одне шумне джерело не витісняє інші.
4. Перевірка повноти доставлення. Звіряємо лічильники на вході та у сховищі, проганяємо тестові сплески й обрив зв’язку, фіксуємо поведінку при недоступності приймача.
5. Розмежування доступу. Ролі за командами й сервісами, маскування персональних даних на вході, журнал запитів до сховища.
6. Передача й навчання команди. Правила іменування, шаблони пошукових запитів і панелей, чергові регламенти, розбір на реальних інцидентах.

Що уточнюємо на аудиті

• Які питання команда ставить логам найчастіше і скільки готова чекати відповідь.
• Потрібна глибина зберігання та поля, які не можна зберігати у відкритому вигляді.
• Які збирачі вже розгорнуті та що з них можна перевикористати замість дублювання.

Конфігурації, схеми потоків і регламенти чергувань

Агрегація логів тримається не на інтуїції чергового, а на артефактах — файлах і документах, які можна перечитати, відкотити й передати колезі.

Після впровадження весь цей набір залишається в репозиторії команди замовника, а не в листуванні з підрядником: новий інженер читає ті самі конфігурації, що й автор системи.

Конфігурації та схеми потоків

• Конфігурації колекторів — приймання, розбір і збагачення записів, єдині для всіх вузлів: однакові поля на тестовому стенді та в проді, без ручних правок на окремих машинах.
• Схеми потоків і маршрутів — що куди йде, за якими правилами розділяються потоки різних сервісів, середовищ і команд.
• Політики зберігання — строки життя записів за типами, що чиститься автоматично, що вирушає в архів і як звідти піднімається.
• Політики доступу до записів — ролі, хто які потоки читає, маскування чутливих полів до запису у сховище.
• Панелі моніторингу та правила оповіщень — готові запити, пороги, кому і з якою затримкою надходить сигнал.
• Інструкція з підключення нового сервісу — покроковий шлях від заявки до першого запису в спільному сховищі.

Регламенти та інструкції для чергових

• Регламент чергової зміни: приймання зміни, час реакції, зони відповідальності, порядок ескалації.
• Порядок дій на типові збої — переповнення диска, відставання черги, недоступність сховища.
• Чек-ліст перевірки після правки конфігурації: що і в якому порядку дивитися, щоб не втратити потік.
• Правила розбору інциденту й оновлення документації за його підсумками.

Кейс: як перебудова збору скоротила розбір інцидентів

Замовник — платформа з кількох десятків сервісів. Інциденти розбирала чергова зміна, і майже кожен розбір упирався не в складність причини, а у відсутність даних: потрібних записів на момент розбору вже не існувало.

Що було до: розрізнені файли на вузлах

Журнали писалися локально на кожному вузлі, ротація йшла за розміром файлу, і в пік навантаження — рівно під час аварії — свіжі записи витісняли потрібні для розбору.

Інженер заходив на вузли по одному й зводив час вручну: розходження годинників сягало кількох хвилин, тому події вишиковувалися в неправильному порядку.

Близько 12% записів губилося під час ротації та переповнення диска, пошук за інцидентом займав від 40 до 90 хвилин, а картина збиралася з шести джерел замість двадцяти.

Що стало: єдиний пошук і хвилини замість годин

Агент на вузлі читає журнали застосунку та системні, проставляє мітки сервісу, середовища й версії релізу та віддає їх у спільний приймач. Час синхронізовано, структуру записів приведено до єдиної схеми — події різних сервісів зіставляються напряму, без ручного зшивання.

Пошук за інцидентом займає 3–5 хвилин замість години, втрачених записів — 0,2%, повнота картини зросла до всіх сервісів, включно з фоновими задачами та чергами. Хибних спрацювань стало вчетверо менше: правило будується на швидкості зростання помилок, а не на одиничному записі. Розбір і панелі йдуть поверх одного потоку в Grafana, одна вибірка не збирається двічі.

Розбір інциденту перестав залежати від того, чи встиг інженер зайти на вузол до ротації.

Що робити, якщо події вже збираються в різних місцях?

Події, зібрані в різних місцях, — не привід переписувати весь збір. Зазвичай на частині вузлів уже стоять агенти, наприклад Fluent Bit, із налаштованими парсерами, частина сервісів пише у файли, а в поточному сховищі лежить історія, за якою побудовано дашборди й алерти. Спочатку складаємо карту контурів і за кожним шаром вирішуємо: перевикористовуємо чи замінюємо.

Плавна міграція сервісів

Переводимо по одному сервісу або групі вузлів, а не все одразу. Новий контур вмикається поруч зі старим: обидва пишуть паралельно, ми звіряємо обсяг, затримку й розмітку подій — розходження в лічильниках і порожні поля слугують стоп-сигналом.

Схема збору живе в репозиторії як конфігурація, тому відкат вузла — це повернення попередньої ревізії.

Подвійне доставлення на перехідний період

Агент надсилає події у два приймачі — у поточне сховище та в нове, з ідентифікатором події для відсікання дублів. Історія не рветься, звіти продовжують будуватися, а новий контур набирає дані під перевірку.

Коли весь потік іде через новий збір, а розходження нульові, старі агенти вимикаємо поетапно, за групами, залишаючи резервний канал на кілька днів.

Технічні питання, які ставлять до старту

Перед стартом важливо зрозуміти, як агрегація логів ляже на поточне навантаження і що станеться, якщо один із вузлів збору відмовить.

Нижче — п’ять питань, які ми розбираємо до першої зміни в інфраструктурі: від них залежать схема доставлення, політика зберігання й порядок перемикання сервісів.

Що станеться, якщо колектор недоступний?

Агент пише потік у локальний буфер на диску й досилає його після відновлення зв’язку, тому перерва не перетворюється на діру в логах. Окремо перевіряємо поведінку при переповненні буфера й налаштовуємо обмеження швидкості, щоб збір не витіснив робочий процес сервісу.

Чи можна переводити сервіси поетапно?

Так, ідемо контурами: спочатку один сервіс або неробоче середовище, потім решта. Старий і новий контури якийсь час працюють паралельно, лічильники записів звіряються, а відкат робиться перемиканням конфігурації без перезбирання застосунків.

Як бути з чутливими полями в записах?

Маскування та хешування виконуються до відправлення, на боці джерела — у сховище чутливі значення вже не потрапляють. Доступ до перегляду розмежовуємо ролями, а самі запити до логів фіксуємо в аудиті.

Які строки та рівні зберігання потрібні?

Розділяємо гарячий шар для оперативного пошуку за останні дні та холодний архів зі стисненням для розборів і перевірок. Ротація й видалення працюють за політикою автоматично, строки фіксуємо під ваші вимоги та обсяг.

Обговоримо задачу та повернемося з оцінкою й планом

Щоб повернутися з оцінкою обсягу робіт, а не із загальними словами, нам потрібно зрозуміти джерела та профіль потоку логів. Опишіть задачу у вільній формі — далі уточнимо відсутнє самі.

• Які сервіси та рівні віддають логи: застосунки, балансувальники, бази даних, оркестратор, мережеві компоненти — і чим вони їх пишуть зараз.
• Формат подій: структуровані записи з полями чи неструктурований текст, для якого знадобиться розбір на етапі приймання.
• Порядок величин: скільки подій надходить у піку та в середньому за добу, як зростає обсяг при навантаженні.
• Строк зберігання за типами: де потрібні гарячі дані для пошуку й розбору інцидентів, а де достатньо холодного архіву.
• Чутливі дані в записах і вимоги до розмежування доступу між командами.
• Обмеження за мережею та правами: які вузли можуть віддавати дані назовні і як видаються доступи до кластера зберігання.

У відповідь надсилаємо схему потоку від джерела до візуалізації, оцінку обсягу робіт за етапами, склад команди з ролями та порядок підключення сервісів — по одному, щоб збій збору було видно одразу. Опишіть задачу в зручному вигляді: розберемо її та повернемося з планом етапів упровадження.