Централізований збір логів через 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. Отримайте повний аудит логів з дотриманням стандартів безпеки. Зв'яжіться з нами для консультації — оцінимо ваш проєкт за один робочий день.