Проблема с multiline filter

Всем привет.

Мне нужно организовать сбор логов с продакшена и вопрос по оптимальной инфраструктуре ELK stack я задам в другом топике.
Здесь про проблемы с многострочным фильтром.
И сразу картинки:




В целом система состоит из следующих ключевых узлов:

  1. Логи приложения (в данном случае один, dialer.log)
  2. Logstash-forwarder (конфиг ниже)
  3. Logstash-shipper (Выбрасываем пустые ивенты, достаем имя файла из полного имени файла, кладем ивент в очередь redis и в файл для протокола)
  4. Redis (конвеер ивентов перед парсером)
  5. Logstash-parser (читает ивент из очереди, записывает @timestamp в received_at, собирает все строки многострочных ивентов, парсит ивент в гроке, заменяет timestamp ивента ловализированной версией из лога, заливает ивенты в elasticsearch)

Вот все настройки:
http://pastebin.com/VwL3uJj4

Проблема проявляется уже при обработке одного единственного файла с многострочными ивентами. Как можно видеть на скриншотах, в файл fromshipper.log идет лог ивентов, которые выходят из logstash-shipper instance (в формате <время_попадания_в_logstash-shipper> <неудачная попытка вывести id ивента> <строки лога>). Как мы видим в Kibana, между двумя частями лога (вторая часть которого с _grok_parse_failure) нет ни паузы, ни других ивентов из других файлов (это начинается когда собираються логи из нескольких файлов).

При попытке залить сразу несколько файлов ситуация еще больше усугубляется. Частота лог-ивентов на продакшене в моем случае без труда может достигать 5 млн лог-ивентов в час. Как справиться с таким наплывом, я не представляю. Увеличение таймаута в multiline фильтре погоды не делает. Обработка событий только замедляется. Через некоторое время redis съедает всю оперативку, весь swap и падает. Уменьшение timeout способствует увеличению разорваных ивентов.

Подскажите в чем может быть проблема? Может быть это ES? Может не правильно составлены config файлы? В общем, любые советы приветствуются.

С уважением,
Егор