Проблема
Rsyslog неэффективен при обработке логов в нестандартных форматах (JSON, многострочные записи, двоичные данные) и для сложной маршрутизации (одновременная отправка в несколько бэкендов с разными фильтрами). Отсутствие встроенной буферизации и гибких плагинов для трансформации/обогащения данных усложняет SIEM-интеграцию и форензику.

Причины
- Rsyslog имеет ограниченный набор модулей для парсинга (mmnormalize), требуя ручных регулярных выражений и плохо поддерживает JSON/msgpack.
- Нет встроенной поддержки очередей с гарантированной доставкой при сбоях — потеря логов при высокой нагрузке.
- Сложно настроить несколько output-потоков с разными фильтрами (например, одни логи — в ClickHouse для аналитики, другие — в Kafka для реалтайма).
- Трудоёмко расширять функциональность (написание C-модулей) — Fluentd же имеет готовые плагины на Ruby/Go.

Решение
Заменить rsyslog на Fluentd для сбора и маршрутизации логов. Пример конфигурации для парсинга syslog + отправки в Elasticsearch и Kafka:

conf
@type syslog

  port 5140

  bind 0.0.0.0

  tag system







  @type parser

  key_name message

  format /^(?[^ ]+ \d+ \d+:\d+:\d+) (?[^ ]+) (?[^:]+): (?.+)$/

  time_format %b %d %H:%M:%S







  @type copy

  

    @type elasticsearch

    host localhost

    port 9200

    logstash_format true

    flush_interval 5s

  

  

    @type kafka2

    brokers localhost:9092

    topic syslog

    required_acks -1


Для отказоустойчивости используйте `buffer_type file` и `retry_max_times` в output-плагинах — Fluentd автоматически перешлёт данные после восстановления соединения.