Централизованный сбор логов через syslog-ng: TLS, Elasticsearch

С централизацией логов на проекте столкнулись, когда после инцидента с утечкой данных не смогли собрать полную картину событий — логи по пяти серверам размазались по auth.log, messages и journald. Восстановление хронологии заняло два дня вместо пары часов, а анализ показал, что до 30% критических сообщений были потеряны из-за отсутствия централизованного хранилища. Тогда и решили внедрить syslog-ng — защищённое хранилище всех логов в одном месте. Сейчас MTTR по инцидентам, связанным с логами, сократился с 4 часов до 30 минут. Экономия времени на поиск логов после внедрения составляет до 40%.

Мы используем syslog-ng в продакшене более 7 лет. Инструмент понимает syslog RFC3164 и RFC5424, journald, файлы и HTTP, а его DSL для трансформации сообщений гибче, чем у rsyslog. Официальная документация подтверждает зрелость проекта и активную поддержку сообществом. За это время мы реализовали более 50 проектов централизованного сбора логов — от стартапов до enterprise на 500+ серверов.

Базовая архитектура: клиент → сервер

Клиент (каждый сервер в инфраструктуре) шлёт логи на центральный сервер syslog-ng по TLS. Сервер разбирает по источникам, пишет в файлы или отправляет в Elasticsearch.

Конфигурация клиента:

# /etc/syslog-ng/conf.d/client.conf
source s_local {
    system();
    internal();
};

destination d_central {
    syslog(
        "syslog.example.com"
        port(6514)
        transport("tls")
        tls(
            ca-file("/etc/syslog-ng/ca.pem")
            cert-file("/etc/syslog-ng/client.pem")
            key-file("/etc/syslog-ng/client.key")
        )
        flags(no-multi-line)
    );
};

log {
    source(s_local);
    destination(d_central);
};

Конфигурация сервера:

# /etc/syslog-ng/syslog-ng.conf
@version: 4.5
@include "scl.conf"

options {
  time-reap(30);
  mark-freq(0);
  keep-hostname(yes);
  create-dirs(yes);
  dir-perm(0755);
  perm(0640);
};

source s_network_tls {
  syslog(
    ip(0.0.0.0)
    port(6514)
    transport("tls")
    tls(
      key-file("/etc/syslog-ng/server.key")
      cert-file("/etc/syslog-ng/server.pem")
      ca-file("/etc/syslog-ng/ca.pem")
      peer-verify(required-trusted)
    )
  );
};

template t_json {
  template(
    "$(format-json --scope rfc5424 --scope nv-pairs --exclude DATE --key ISODATE @timestamp=${ISODATE})\n"
  );
};

destination d_elasticsearch {
  elasticsearch-http(
    url("http://elasticsearch:9200/_bulk")
    index("syslog-${YEAR}.${MONTH}.${DAY}")
    type("")
    template(t_json)
    flush-lines(100)
    flush-timeout(10000)
  );
};

destination d_files {
  file(
    "/var/log/syslog-ng/${HOST}/${PROGRAM}.log"
    template(t_json)
    create-dirs(yes)
  );
};

filter f_error {
  level(err..emerg);
};

log {
  source(s_network_tls);
  destination(d_files);
  destination(d_elasticsearch);
  flags(flow-control);
};

flags(flow-control) — при переполнении буфера syslog-ng блокируется, а не теряет сообщения. Важно для audit-critical потоков.

Трансформация и фильтрация

syslog-ng умеет парсить структурированные логи через json-parser и kv-parser:

parser p_json {
    json-parser(prefix(".json."));
};
filter f_app {
    program("myapp");
};
rewrite r_add_env {
    set("production" value(".json.environment"));
};
log {
    source(s_network_tls);
    filter(f_app);
    parser(p_json);
    rewrite(r_add_env);
    destination(d_elasticsearch);
};

Почему стоит выбрать syslog-ng вместо rsyslog?

Выбор между syslog-ng и rsyslog зависит от задач. syslog-ng выигрывает, когда нужна сложная трансформация логов и безопасность; rsyslog лучше для простой маршрутизации с максимальным перформансом. Ниже — сравнение ключевых характеристик.

Для реального кейса: на проекте с 200 серверами и требованием PCI DSS выбрали syslog-ng — потребовалась гибкая фильтрация и гарантированная доставка. Rsyslog не справился бы с трансформацией нестандартных логов.

Как syslog-ng решает проблему потери логов?

Проблема: перегрузка канала или падение приёма на сервере приводят к отбрасыванию сообщений. syslog-ng решает это двумя механизмами:

• Flow-control: блокирует клиент при переполнении буфера.
• Дисковый буфер: алгоритм disk-buffer сохраняет логи на диск, если память закончилась. Настраивается параметрами buf-size и dir.

Для критичных систем мы всегда включаем оба. Гарантия доставки — 99.9% при правильной конфигурации.

Процесс внедрения: что входит в работу

• Анализ текущей схемы сбора логов (источники, протоколы, политики ротации).
• Проектирование архитектуры: выбор схемы TLS, настройка кластеризации серверов.
• Настройка клиентов (Ansible playbook для массового деплоя).
• Конфигурация сервера: парсеры, фильтры, destinations.
• Тестирование сбоев: pull the plug — проверяем потерю логов при разрыве сети.
• Документация runbook и скрипты мониторинга (метрики Prometheus через exporter).
• Обучение команды: как добавлять новые источники и менять конфиги.

Сроки: от 3 до 7 дней в зависимости от количества серверов (от 5 до 100). Стоимость рассчитывается индивидуально — пишите, оценим проект за один рабочий день.

Типичные ошибки при настройке syslog-ng

• Использование tls() без peer-verify(required-trusted) — любой клиент с сертификатом, подписанным вашим CA, сможет слать логи. Ошибка безопасности.
• Игнорирование persist-name в логах — при перезагрузке сервера теряется индексация.
• Слишком агрессивный flush-lines в destination Elasticsearch — ведёт к частым HTTP-запросам и снижению пропускной способности. Оптимальное значение — 10-50.

Наш опыт: за годы работы с syslog-ng настроили централизованный сбор для проектов от стартапов до enterprise на 500+ серверов. Гарантируем поддержку после внедрения — фиксируем SLA в договоре.

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