Централізоване логування в Kubernetes: де ламається
Логи контейнера живуть рівно стільки, скільки живе сам контейнер. Застосунок пише у стандартний потік виводу, шар із файлами зникає під час перезапуску — і якщо збирач не встиг забрати дані, для розбору інциденту цих рядків уже не існує.
Помилку, яка призвела до падіння, видно за уривком, а причина залишається у втраченій частині. Гірше, коли збір іде напряму до сховища: під час мережевої затримки буфер нікуди скинути, і втрачається не один под, а весь вузол цілком.
Друга точка відмови — час. Годинники на вузлах розходяться, мітки надходять із різних джерел і в різному форматі, тому події одного збою вишиковуються в неправильному порядку.
Відновити послідовність «що за чим зламалося» за такою вибіркою неможливо, і черговий знову йде перезапускати сервіс навмання.
Третя — шум і дублі. Один і той самий запит залишає слід у застосунку, на вході та в системному журналі, дедуплікації немає, розбору й збагачення також.
Обсяг нерозібраних даних зростає швидше, ніж команда встигає їх читати: корисних рядків у потоці одиниці відсотків, решта — повтори й службовий шум. Саме на цьому етапі збір логів у кластері перестають використовувати й повертаються до ручного читання з вузлів.
На практиці всі три проблеми закриває один шар між застосунком і сховищем — Vector ставлять у кластер саме для цього. Розбираємо, як це влаштовано і що потрібно передбачити.
Що дає єдиний контур збору та зберігання логів
Агент на кожному вузлі збирає потік контейнерів і надсилає його в один приймач — замість того щоб заходити на конкретну машину й читати локальні файли, черговий відкриває одну точку входу.
Частка інцидентів, де причину знаходять з першого заходу, зростає з третини до більшості: контекст за всіма сервісами, що брали участь у запиті, лежить поруч, а не в чотирьох системах.
Дедуплікація та стиснення потоку закривають другу проблему — обсяг. Один і той самий стек викликів, розмножений по десятках подів, згортається в запис із лічильником повторів, а структурований формат пакується щільніше за сирий текст.
Термін зберігання логів зростає без розширення дисків: те, що раніше жило лічені дні, живе місяці, і розбір інциденту тижневої давності більше не впирається в порожнечу.
Маршрутизація за командами будується на мітках: простір імен, сервіс, середовище. Власники сервісу отримують свій потік і сповіщення за своїми помилками, а не повний шум кластера.
Час до першої відповіді за інцидентом падає з десятків хвилин до одиниць — потрібний фрагмент дістається одним запитом, а не перебором хостів.
Окремо зникає клас відмов «логи є, але не там» і «под перестворився — слід загубився»: буферизація та повторне надсилання тримають потік під час рестартів.
Збирач Vector описує весь контур декларативно — правила перетворення й маршрути версіонуються разом із конфігурацією кластера, тому нова команда підключається правкою файлу, а не окремим стендом.
Схеми централізованого логування: порівняння підходів
Схема збору визначає, у якій точці потік логів перехоплюється і що з ним відбувається, коли сховище недоступне. У кластері реально вибирають між чотирма варіантами: вони різняться точкою перехоплення, накладними витратами на вузлах і поведінкою під час розриву зв’язку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Агент збору логів на вузлі (Vector як служба вузла) | Багато сервісів на вузлі, єдині правила обробки | Один процес читає файли всіх контейнерів: накладні витрати на вузлах зростають разом із потоком, а збій агента зачіпає одразу всі поди вузла |
| Допоміжний контейнер для логів | Різнорідні формати, потрібна окрема конфігурація на сервіс | Множить кількість контейнерів у поді, додає споживання пам’яті кожному екземпляру, ускладнює оновлення конфігурації |
| Запис напряму із застосунку | Кілька сервісів, жорсткі вимоги до структури запису | Логіка надсилання живе в коді; коли сховище недоступне, буфер обмежений пам’яттю процесу, ретраї пише сам застосунок |
| Гібридна схема збору | Щільні вузли з різнорідними сервісами | Потрібен регламент: що віддається агенту, що виноситься в окремий контейнер і де вмикається дисковий буфер |
Буферизація, коли сховище недоступне, — окреме проєктне рішення, а не побічний ефект схеми.
Дисковий буфер на вузлі переживає перезапуск агента, але під час переповнення витісняє найстаріші записи — цей клас втрат і порядок наздоганяючого надсилання після довгого розриву узгоджуємо заздалегідь, до викочування.
Етапи впровадження: від інвентаризації потоків до передачі
Централізоване логування не починається зі встановлення агента — спочатку фіксують, що генерує події, з якою швидкістю і в якому форматі. Інакше контур не витримає пік або зберігатиме шум, за яким не знайти причину збою. Кожен наступний етап спирається на дані попереднього.
- Інвентаризація джерел логів. Ідемо за робочими навантаженнями: застосунок пише у stdout чи у файл, чи є нестандартні формати й багаторядкові стеки помилок, що дає аудит кластера. На виході — перелік потоків з оцінкою добового обсягу й пікової швидкості.
- Схема маршрутизації потоків. Вирішуємо, що йде в гаряче сховище для пошуку, що — у дешевий архів, що — у сповіщення; потоки отримують теги, терміни зберігання та правила відкидання дублів.
- Збір і перетворення. Агент розгортається на кожному вузлі, вмикається буфер на локальному диску, структуровані записи розбираються на поля, багаторядкові повідомлення склеюються, чутливі дані маскуються до надсилання.
- Навантажувальна перевірка контуру. Проганяємо потік вище за розрахунковий пік: чи зростає буфер, чи встигає сховище, як поводиться затримка доставки.
- Перевірка під час відмови сховища. Відключаємо приймач і переконуємося, що агент утримує події на диску, а після відновлення досилає їх без розривів і втрати порядку.
- Регламенти та сповіщення. Контроль затримки доставки, алерти на переповнення буфера, ролі доступу, терміни зберігання та порядок вивантаження за запитом.
- Передача контуру в експлуатацію. Віддаємо конфігурації, схему маршрутизації, панелі та інструкцію черговому, розбираємо з вашою командою типові інциденти.
Конфігурації, схеми та регламенти: що залишається у вас
Впровадження закінчується не працюючим кластером, а набором артефактів, які можна читати, правити й передавати новим людям. Усе лежить у Git поруч із маніфестами й проходить рев’ю, тому конфігурація збору не залишається в єдиному екземплярі на чиїйсь машині.
- Конфігурація агента збору. Джерела, перетворення, маршрутизація за приймачами, буферизація на диск і поведінка, коли сховище недоступне — з коментарями, чому вибрано саме ці параметри.
- Схема потоків логів. Звідки надходять дані, де збагачуються мітками простору імен і пода, де фільтруються, до якого приймача йдуть і на якій ділянці губляться першими під час перевантаження.
- Політики доступу до логів. Розмежування за ролями й просторами імен, окремі облікові записи для чергової зміни та розбору інцидентів, маскування чутливих полів на етапі збору.
- Регламент ротації та зберігання. Терміни за типами логів, розмір і кількість сегментів, правило перенесення в холодне сховище й перелік того, що видаляється безповоротно.
- Інструкція для чергового. Покрокові сценарії: як знайти логи конкретного пода, як перевірити, що агент віддає дані, що дивитися при відставанні приймача і коли піднімати ескалацію.
- Регламент змін. Як підключити новий застосунок до збору, хто погоджує правку маршрутів і як відкотити конфігурацію, якщо після викочування зник потік.
Перед передачею артефакти перевіряються на вашому стенді: типові операції проганяємо разом із черговою зміною й правимо формулювання під ваш процес.
Кейс: як скоротили час пошуку причини збою
Що було до
Застосунок писав логи у потік стандартного виводу, файли на вузлі ротувалися, і ротація затирала саме той інтервал, який був потрібен для розбору.
У кожного сервісу свій формат часу й своя шкала рівнів, тому черговий збирав картину вручну: обходив вузли, зіставляв позначки часу й наосліп шукав кореляцію між сервісами.
Середній час пошуку причини збою — 45 хвилин, на каскадних інцидентах сягало двох годин, а частину епізодів відновити взагалі не вдавалося.
Що змінили
Розгорнули Vector як набір агентів на кожному вузлі: вони читають і файли контейнерів, і потік стандартного виводу, розбирають формати на боці агента й приводять час до єдиної зони.
До кожного запису додаються мітки простору імен, пода, сервісу й версії збірки — саме за ними потім будується вибірка. Тут же відсікається шум: перевірки живучості, повторювані повідомлення, налагоджувальні рівні.
Далі маршрутизація: критичні рівні йдуть у гаряче сховище зі швидким пошуком, решта — у холодне з тривалим терміном. Скорочення обсягу збереженого потоку — приблизно в 6 разів, без втрати значущих подій. З’явилася єдина точка пошуку за логами: один запит за сервісом та інтервалом замість обходу вузлів.
Що стало
Час пошуку причини збою — 4–6 хвилин, це 95-й процентиль інцидентів. Усунений клас відмов — втрата логів під час перезапуску пода й розсинхронізація часу між сервісами, через яку кореляція подій будувалася неправильно. Розбір інциденту тепер починається з вибірки за міткою, а не зі збору даних.
Збір логів агентом на вузлі чи контейнером-супутником?
Обидві схеми розв’язують одну задачу — доставити логи в систему централізованого логування, — але різняться тим, де живе процес збору і чиї ресурси він витрачає.
Агент на вузлі запускається один на вузол і читає логи контейнерів через змонтований том, контейнер-супутник стартує поруч із застосунком у тому самому поді й бачить лише його потік виводу.
Агент на вузлі дешевший: один процес, один буфер, одна точка оновлення на весь вузол. Плата — спільний пул ресурсів: сплеск логів в одного сервісу забиває чергу, і сусідні потоки втрачають події.
Ізоляція потоків логів тримається не на ресурсах, а на правилах маршрутизації за мітками пода й простору імен, тому помилка в конфігурації зачіпає одразу весь вузол.
Контейнер-супутник дає граничну ізоляцію: свій процес, свої ліміти, свій розбір і свій отримувач — переповнення одного супутника не зачіпає сусідів.
Зате накладні витрати на збір логів зростають лінійно з кількістю подів: копія процесу на кожен екземпляр, окремі квоти пам’яті та помножена робота із супроводу під час оновлення парку.
Vector підтримує обидві топології однією конфігурацією: агент розгортається набором демонів на вузлах, супутник — окремим контейнером у поді, а позиції читання фіксуються в контрольних точках, тому перезапуск не призводить до повторного надсилання всього файлу.
На практиці частіше беруть гібрид: базовий потік збирає агент на вузлі, а супутник ставлять точково — для сервісів з особливими вимогами до доступів, розбору або адресата.
Відповіді на технічні питання щодо збору логів
Логи потрібні не тоді, коли все працює, а коли щось відвалилося — тому питання щодо централізованого логування стосуються не самого налаштування, а поведінки в нештатних ситуаціях.
Нижче — те, що найчастіше обговорюємо до старту: збереженість, коли сховище недоступне, витіснення контейнерів, доступи між командами та підключення вже наявного сховища.
Що буде з логами, якщо сховище недоступне?
Агент буферизує потік на диск вузла й повторює надсилання з наростаючою затримкою, тому під час короткого збою дані не втрачаються.
У дискової черги є ліміт, і політику переповнення вибирають за критичністю: для аудиту ставимо блокуючий режим, для налагоджувальних потоків — скидання найстаріших записів.
Контейнер витісняється — останні логи збережуться?
Агент працює окремо від застосунку, тому перезапуск або витіснення пода не перериває збір: вивід читається до кінця, включно з рядками, записаними перед завершенням процесу. Під час виведення вузла з експлуатації буфер устигає злитися до зупинки пода.
Як розмежувати доступ між командами?
Маршрутизація будується за метаданими — простір імен, ім’я пода, мітки. Кожна команда отримує свій індекс у сховищі й права лише на нього, тому продуктова розробка не бачить логів платіжного контуру, а черговий бачить усе потрібне для розбору збою.
Можна підключити наше наявне сховище?
Так, якщо в нього є сумісний приймач: Elasticsearch, Loki, об’єктне сховище або черга як проміжний буфер. Схему полів та індексів підганяємо під ваші дашборди, щоб старі запити й алерти продовжували працювати.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб повернутися з оцінкою робіт із впровадження та планом впровадження контуру, нам потрібні ввідні про вашу інфраструктуру — вони визначають архітектуру агентів, схему маршрутизації та трудомісткість. Нижче список того, що варто підготувати: якщо частина даних невідома, зберемо разом на дзвінку.
- Профіль навантаження й обсяг потоку. Кількість вузлів і робочих навантажень, середня та пікова швидкість подій, добовий приріст, чи є різкі сплески під час інцидентів. Від цього залежить буферизація на диску й запас за пропускною здатністю.
- Джерела й формат журналів. Вивід застосунків, системні журнали вузлів, журнал аудиту кластера, логи шару даних. Важливо, структурований це JSON чи вільний текст — визначає набір правил розбору й збагачення метаданими кластера.
- Вимоги до сховища. Термін зберігання за кожним типом журналів, чи потрібен пошук за повним текстом, правила видалення й архівації, очікуваний обсяг реєстру в перспективі.
- Схема контуру. Один кластер чи кілька, власні сервери чи хмара, обмеження на вихідний трафік, де допустимо розмістити колектор.
- Доступи й вимоги безпеки. Службові облікові записи з правами читання метаданих, шифрування каналу, необхідність маскування персональних даних до запису.
- Поточний стан. Які агенти збору вже стоять і куди пишуть — щоб не піднімати другий паралельний контур і не платити за нього двічі.
- Порядок поетапного впровадження й точки відкату. Чи допустимо вмикати збір поетапно, починаючи з одного робочого навантаження, і як швидко потрібно повернути попередню схему.
Опишіть задачу в цих межах — повернемося з оцінкою, планом робіт і схемою розгортання Vector у вашому контурі.
