Rsyslog для централизованного сбора логов с TLS-шифрованием и буферизацией при недоступности

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

Модель rsyslog и место форвардинга в правилах конфигурации

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

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

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

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

Протоколы передачи и переход от UDP к TCP

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

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

*.* action(type="omfwd" target="loghost.example.internal" port="514" protocol="tcp")

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

Скорость и overhead TCP-канала с шифрованием растут вместе, и на больших потоках это чувствуется. Практика показывает разумный потолок: тысячи записей в секунду на соединение центральный сбор переваривает без жалоб, а десятки тысяч требуют уже отдельных решений вроде секционирования по клиентам и нескольким приёмникам. Для большинства хозяйств вопрос упирается не в процессор, а в дисциплину настройки.

TLS-шифрование канала и сертификаты на обеих сторонах

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

module(load="imtcp")
global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog/keys/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog/keys/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog/keys/server-key.pem"
)
input(type="imtcp" port="514" StreamDriverMode="1" StreamDriver.AuthMode="x509/name" PermittedPeer="*.clients.example.internal")

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

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

Очереди на клиенте и поведение при недоступности приёмника

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

action(
  type="omfwd" target="loghost.example.internal" port="514" protocol="tcp"
  StreamDriverMode="1"
  queue.type="LinkedList"
  queue.filename="fwd-central"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeInterval="10"
  action.resumeRetryCount="-1"
)

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

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

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

Приёмная сторона от входящего потока к файлам по хостам

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

template(name="remotehost" type="string" string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
if $fromhost-ip != "127.0.0.1" then ?remotehost

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

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

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

Проверка канала и наблюдение за очередями

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

Проверка устойчивости делается учением. Приёмник останавливается на несколько минут, клиент продолжает работать, статистика очереди показывает рост; приёмник поднимается, очередь дренажируется, статистика возвращается к нулю. Такое учение в спокойной обстановке стоит часа, а отвечает на вопрос, который иначе проверяется только настоящим сбоем.

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

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

Рабочая конфигурация форвардинга и порядок внедрения

Порядок внедрения центральной схемы, собранный из практики, выглядит так:

1. Выбор транспорта, порта и адреса приёмника с фиксацией в документации;
2. Выпуск сертификатов локальным центром и раздача обеим сторонам;
3. Включение шифрования на входе приёмника и в действии клиента;
4. Настройка дисковой очереди с лимитом места и сохранением при остановке;
5. Повторные попытки с растущим интервалом и бесконечным счётчиком;
6. Тестовое сообщение, учение на остановку приёмника и регулярный мониторинг.

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

Итоговое суждение о центральном сборе скромное. Это не экзотика, а прямое следствие роста хозяйства, и rsyslog проводит схему от простого пересыла к шифрованному каналу с буферизацией без привлечения тяжёлых платформ. Логи, доехавшие до центра по зашифрованному каналу и пережившие два сетевых сбоя без потери строки, это не везение, а настроенная дисциплина, и собирается она именно из таких вот правил, по одному за вечер.