Настройка централизованного логирования через Vector в Kubernetes

Централизованное логирование в Kubernetes: где ломается

Логи контейнера живут ровно столько, сколько живёт сам контейнер. Приложение пишет в стандартный поток вывода, слой с файлами исчезает при перезапуске — и если сборщик не успел забрать данные, для разбора инцидента этих строк уже не существует. Ошибку, которая привела к падению, видно по обрывку, а причина остаётся в потерянной части. Хуже, когда сбор идёт напрямую в хранилище: при сетевой заминке буфер некуда сбросить, и теряется не один под, а весь узел целиком.

Вторая точка отказа — время. Часы на узлах расходятся, метки приходят из разных источников и в разном формате, поэтому события одного сбоя выстраиваются в неверном порядке. Восстановить последовательность «что за чем сломалось» по такой выборке нельзя, и дежурный снова идёт перезапускать сервис наугад.

Третья — шум и дубли. Один и тот же запрос оставляет след в приложении, на входе и в системном журнале, дедупликации нет, разбора и обогащения тоже. Объём неразобранных данных растёт быстрее, чем команда успевает их читать: полезных строк в потоке единицы процентов, остальное — повторы и служебный шум. Именно на этом этапе сбор логов в кластере перестают использовать и возвращаются к ручному чтению с узлов.

На практике все три проблемы закрывает один слой между приложением и хранилищем — Vector ставят в кластер именно для этого. Разбираем, как это устроено и что нужно предусмотреть.

Что даёт единый контур сбора и хранения логов

Агент на каждой ноде собирает поток контейнеров и отправляет его в один приёмник — вместо того чтобы заходить на конкретную машину и читать локальные файлы, дежурный открывает одну точку входа. Доля инцидентов, где причина находится с первого захода, растёт с трети до большинства: контекст по всем сервисам, участвовавшим в запросе, лежит рядом, а не в четырёх системах.

Дедупликация и сжатие потока закрывают вторую проблему — объём. Один и тот же стек вызовов, размноженный по десяткам подов, схлопывается в запись со счётчиком повторов, а структурированный формат упаковывается плотнее сырого текста. Срок хранения логов растёт без расширения дисков: то, что раньше жило считанные дни, живёт месяцы, и разбор инцидента недельной давности больше не упирается в пустоту.

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

Отдельно уходит класс отказов «логи есть, но не там» и «под пересоздался — след потерялся»: буферизация и повторная отправка держат поток при рестартах. Сборщик Vector описывает весь контур декларативно — правила преобразования и маршруты версионируются вместе с конфигурацией кластера, поэтому новая команда подключается правкой файла, а не отдельным стендом.

Схемы централизованного логирования: сравнение подходов

Схема сбора определяет, в какой точке поток логов перехватывается и что с ним происходит, когда хранилище недоступно. В кластере реально выбирают между четырьмя вариантами: они различаются точкой перехвата, накладными расходами на узлах и поведением при разрыве связи.

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

Этапы внедрения: от инвентаризации потоков до передачи

Централизованное логирование не начинается с установки агента — сначала фиксируют, что генерирует события, с какой скоростью и в каком формате. Иначе контур не выдержит пик или будет хранить шум, по которому не найти причину сбоя. Каждый следующий этап опирается на данные предыдущего.

1. Инвентаризация источников логов. Идём по рабочим нагрузкам: приложение пишет в stdout или в файл, есть ли нестандартные форматы и многострочные стеки ошибок, что даёт аудит кластера. На выходе — перечень потоков с оценкой суточного объёма и пиковой скорости.
2. Схема маршрутизации потоков. Решаем, что идёт в горячее хранилище для поиска, что — в дешёвый архив, что — в оповещения; потоки получают теги, сроки хранения и правила отбрасывания дублей.
3. Сбор и преобразование. Агент разворачивается на каждой ноде, включается буфер на локальном диске, структурированные записи разбираются на поля, многострочные сообщения склеиваются, чувствительные данные маскируются до отправки.
4. Нагрузочная проверка контура. Прогоняем поток выше расчётного пика: растёт ли буфер, успевает ли хранилище, как ведёт себя задержка доставки.
5. Проверка при отказе хранилища. Отключаем приёмник и убеждаемся, что агент удерживает события на диске, а после восстановления досылает их без разрывов и потери порядка.
6. Регламенты и оповещения. Контроль задержки доставки, алерты на переполнение буфера, роли доступа, сроки хранения и порядок выгрузки по запросу.
7. Передача контура в эксплуатацию. Отдаём конфигурации, схему маршрутизации, панели и инструкцию дежурному, разбираем с вашей командой типовые инциденты.

Конфигурации, схемы и регламенты: что остаётся у вас

Внедрение заканчивается не работающим кластером, а набором артефактов, которые можно читать, править и передавать новым людям. Всё лежит в Git рядом с манифестами и проходит ревью, поэтому конфигурация сбора не остаётся в единственном экземпляре на чьей-то машине.

• Конфигурация агента сбора. Источники, преобразования, маршрутизация по приёмникам, буферизация на диск и поведение при недоступности хранилища — с комментариями, почему выбраны именно эти параметры.
• Схема потоков логов. Откуда приходят данные, где обогащаются метками пространства имён и пода, где фильтруются, в какой приёмник уходят и на каком участке теряются первыми при перегрузке.
• Политики доступа к логам. Разграничение по ролям и пространствам имён, отдельные учётки для дежурной смены и разбора инцидентов, маскирование чувствительных полей на этапе сбора.
• Регламент ротации и хранения. Сроки по типам логов, размер и число сегментов, правило переноса в холодное хранилище и перечень того, что удаляется безвозвратно.
• Инструкция для дежурного. Пошаговые сценарии: как найти логи конкретного пода, как проверить, что агент отдаёт данные, что смотреть при отставании приёмника и когда поднимать эскалацию.
• Регламент изменений. Как подключить новое приложение к сбору, кто согласует правку маршрутов и как откатить конфигурацию, если после выката пропал поток.

Перед передачей артефакты проверяются на вашем стенде: типовые операции прогоняем вместе с дежурной сменой и правим формулировки под ваш процесс.

Кейс: как сократили время поиска причины сбоя

Что было до

Приложение писало логи в поток стандартного вывода, файлы на узле ротировались, и ротация затирала как раз тот интервал, который нужен был для разбора. У каждого сервиса свой формат времени и своя шкала уровней, поэтому дежурный собирал картину вручную: обходил узлы, сопоставлял отметки времени и вслепую искал корреляцию между сервисами. Среднее время поиска причины сбоя — 45 минут, на каскадных инцидентах доходило до двух часов, а часть эпизодов восстановить вообще не удавалось.

Что изменили

Развернули Vector как набор агентов на каждом узле: они читают и файлы контейнеров, и поток стандартного вывода, разбирают форматы на стороне агента и приводят время к единой зоне. К каждой записи добавляются метки пространства имён, пода, сервиса и версии сборки — именно по ним потом строится выборка. Тут же отсекается шум: проверки живости, повторяющиеся сообщения, отладочные уровни.

Дальше маршрутизация: критичные уровни уходят в горячее хранилище с быстрым поиском, остальное — в холодное с длительным сроком. Сокращение объёма хранимого потока — примерно в 6 раз, без потери значимых событий. Появилась единая точка поиска по логам: один запрос по сервису и интервалу вместо обхода узлов.

Что стало

Время поиска причины сбоя — 4–6 минут, это 95-й процентиль инцидентов. Устранённый класс отказов — потеря логов при перезапуске пода и рассинхрон времени между сервисами, из-за которого корреляция событий строилась неверно. Разбор инцидента теперь начинается с выборки по метке, а не со сбора данных.

Сбор логов агентом на узле или контейнером-спутником?

Обе схемы решают одну задачу — доставить логи в систему централизованного логирования, — но различаются тем, где живёт процесс сбора и чьи ресурсы он расходует. Агент на узле запускается один на ноду и читает логи контейнеров через смонтированный том, контейнер-спутник стартует рядом с приложением в том же поде и видит только его поток вывода.

Агент на узле дешевле: один процесс, один буфер, одна точка обновления на всю ноду. Плата — общий пул ресурсов: всплеск логов у одного сервиса забивает очередь, и соседние потоки теряют события. Изоляция потоков логов держится не на ресурсах, а на правилах маршрутизации по меткам пода и пространства имён, поэтому ошибка в конфигурации затрагивает сразу весь узел.

Контейнер-спутник даёт предельную изоляцию: свой процесс, свои лимиты, свой разбор и свой получатель — переполнение одного спутника не задевает соседей. Зато накладные расходы на сбор логов растут линейно с числом подов: копия процесса на каждый экземпляр, отдельные квоты памяти и умноженная работа по сопровождению при обновлении парка.

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

Ответы на технические вопросы по сбору логов

Логи нужны не тогда, когда всё работает, а когда что-то отвалилось — поэтому вопросы по централизованному логированию касаются не самой настройки, а поведения в нештатных ситуациях. Ниже — то, что чаще всего обсуждаем до старта: сохранность при недоступности хранилища, вытеснение контейнеров, доступы между командами и подключение уже существующего хранилища.

Контейнер вытесняется — последние логи сохранятся?

Агент работает отдельно от приложения, поэтому перезапуск или вытеснение пода сбор не прерывает: вывод читается до конца, включая строки, записанные перед завершением процесса. При выводе узла из эксплуатации буфер успевает слиться до остановки пода.

Как разграничить доступ между командами?

Маршрутизация строится по метаданным — пространство имён, имя пода, метки. Каждая команда получает свой индекс в хранилище и права только на него, поэтому продуктовая разработка не видит логи платёжного контура, а дежурный видит всё нужное для разбора сбоя.

Можно подключить наше существующее хранилище?

Да, если у него есть совместимый приёмник: Elasticsearch, Loki, объектное хранилище или очередь как промежуточный буфер. Схему полей и индексов подгоняем под ваши дашборды, чтобы старые запросы и алерты продолжали работать.

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

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

• Профиль нагрузки и объём потока. Число узлов и рабочих нагрузок, средняя и пиковая скорость событий, суточный прирост, есть ли резкие всплески при инцидентах. От этого зависит буферизация на диске и запас по пропускной способности.
• Источники и формат журналов. Вывод приложений, системные журналы узлов, журнал аудита кластера, логи слоя данных. Важно, структурированный это JSON или свободный текст — определяет набор правил разбора и обогащения метаданными кластера.
• Требования к хранилищу. Срок хранения по каждому типу журналов, нужен ли поиск по полному тексту, правила удаления и архивации, ожидаемый объём реестра в перспективе.
• Схема контура. Один кластер или несколько, собственные серверы или облако, ограничения на исходящий трафик, где допустимо разместить коллектор.
• Доступы и требования безопасности. Служебные учётные записи с правами чтения метаданных, шифрование канала, необходимость маскирования персональных данных до записи.
• Текущее состояние. Какие агенты сбора уже стоят и куда пишут — чтобы не поднимать второй параллельный контур и не платить за него дважды.
• Порядок раскатки и точки отката. Допустимо ли включать сбор поэтапно, начиная с одной рабочей нагрузки, и как быстро нужно вернуть прежнюю схему.

Опишите задачу в этих границах — вернёмся с оценкой, планом работ и схемой развёртывания Vector в вашем контуре.