syslog-ng 3: централизованные логи с 80+ серверов без потерь

Классическая история: клиент с парком в 80+ Linux-серверов, syslog по UDP на центральный коллектор, и периодические дыры в логах во время сетевых неполадок. UDP не гарантирует доставку - это все знают. Но пока инфраструктура была небольшой, потери были терпимы. Когда инфраструктура выросла, пропавшие события на security-коллекторе превратились из неудобства в реальную проблему: не видишь что происходило в момент инцидента.

Именно это и стало поводом перейти на syslog-ng 3.0, который вышел в этом году с нормальной TCP-доставкой.

Почему rsyslog переставал устраивать

rsyslog у нас стоял давно и работал нормально для базовых задач. TCP-режим в нём тоже есть, но в нашем конкретном случае он вёл себя непредсказуемо при разрыве соединения: демон мог потерять буфер при перезапуске, а disk-queue настраивался через опции, которые в разных версиях rsyslog ведут себя по-разному. Возможно, мы просто плохо настроили - но несколько часов разбирательств с документацией убедили нас смотреть в сторону альтернатив.

syslog-ng к тому моменту знали как более конфигурируемый вариант, но третья версия добавила несколько вещей, которых нам не хватало в ветке 2.x:

• Надёжная доставка по TCP с disk-buffer. При разрыве соединения события пишутся в очередь на диске и отправляются когда соединение восстанавливается. Размер очереди настраивается, у нас выставили на несколько сотен мегабайт - с запасом на несколько часов при нормальной нагрузке.
• Структурированные сообщения. syslog-ng 3 умеет разбирать сообщения через patterndb и извлекать именованные поля. Не просто строка в лог, а разобранный hostname, program, pid, и произвольные поля из тела сообщения.
• Более гибкая маршрутизация. Правила фильтрации и источников/назначений в syslog-ng всегда были богаче, чем у конкурентов, и в третьей версии это сохранилось.

Как разворачивали

Центральный коллектор - отдельная машина, которая принимает события от всех хостов. Поменяли схему: агенты на серверах теперь отправляют по TCP на порт 514 коллектора, коллектор пишет в файлы по шаблону /var/log/remote/<hostname>/%Y/%m/%d.log. Раньше было то же самое, но по UDP.

На агентах конфиг минимальный: source - локальный /dev/log и /proc/kmsg, destination - TCP на коллектор с disk-buffer. На коллекторе - source на входящий TCP, несколько фильтров по facility и severity, destinations в файлы и отдельно в базу для security-событий.

Disk-buffer на агентах сначала пугал: надо явно указать путь к файлу очереди, и если этот файл случайно удалить - очередь пропадёт вместе с событиями. Это не баг, это надо просто держать в голове при обслуживании. Путь вынесли в отдельную директорию /var/lib/syslog-ng/, которую мониторят отдельно.

Что проверили в первую неделю

Намеренно отключали сеть на нескольких тестовых хостах на 5-10 минут и смотрели что происходит. Результат: события накапливались в disk-buffer, после восстановления соединения уходили на коллектор с небольшой задержкой. На коллекторе временная метка сохранялась оригинальная - из syslog-заголовка, а не время приёма. Это важно для расследований: видно когда событие произошло, а не когда дошло.

Одна неожиданность: при одновременном восстановлении соединения с нескольких агентов коллектор получал всплеск входящего трафика. Не критично, но мы увеличили log-fifo-size на коллекторе и добавили небольшой rate-limit на агентах при переотправке буфера.

Структурированные поля на практике

patterndb настроили для нескольких типов событий: SSH-аутентификации, sudo, падения сервисов через systemd. Теперь из строки вида sshd[1234]: Accepted publickey for user from 10.0.0.5 port 45678 ssh2 автоматически извлекаются поля user, src_ip, auth_method. Это сильно упрощает фильтрацию: запрос по полю быстрее и точнее, чем grep по тексту.

Для сопровождения инфраструктуры это меняет характер работы с логами: вместо grep "Failed password" /var/log/remote/*/... можно делать структурированные запросы по полю action=failed и hostname. Не идеально - patterndb надо поддерживать и добавлять паттерны для каждого нового типа событий - но для типовых случаев работает.

Где сейчас

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

rsyslog на нескольких хостах оставили - там специфичные конфиги под конкретные приложения, и трогать их сейчас нет смысла. Два коллектора параллельно не идеал, но рабочий компромисс.

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