Назад | Перейти на главную страницу

ELK против RabbitMQ для обработки больших объемов сообщений / документов?

Я искал стек ELK или RabbitMQ, чтобы заменить домашнюю систему, которая принимает большое количество файлов (200-300 миллионов в час) и работает, а затем отправляет их в различные места в зависимости от имени и содержимого, сохраняя копию локально . (В основном ELK)

Однако я более чем немного компенсирую сложность и требуемую площадь оборудования.

Каковы преимущества RabbitMQ перед стеком ELK для такого рода задач? Мне кажется, что ELK может быть излишним, но я недостаточно знаком с RabbitMQ, чтобы сказать окончательно.

По моим подсчетам, это порядка 83 тысяч событий в секунду. Это много.

Я не совсем уверен, почему вы разделяете RMQ и ELK, поскольку RMQ может быть компонентом ELK. Фактически, очень большие развертывания, о которых я знаю, определенно используют либо решение AQMP, такое как Rabbit, либо что-то вроде Kafka, для обеспечения буфера между генерацией событий и уровнем синтаксического анализа, а также для подачи нескольких потребителей.

Общий крупномасштабный конвейер, который может обрабатывать поток событий, как вы рассматриваете:

  1. Грузоотправители отправляют журналы в центральную очередь. Доставка может быть FileBeat, самим Logstash или чем-то еще.
  2. Система очередей, какая бы она ни была. Может быть Redis, RabbitMQ, Kafka или что-то еще.
  3. Уровень синтаксического анализа. Группа узлов Logstash, которая извлекает события из очереди, массирует их и отправляет на следующий этап.
    • Это масштабируется по горизонтали. Пока ваша система очередей может не отставать, вы можете добавлять сюда парсеры. В нашей системе с нашими правилами фильтрации мы можем выполнять 2К событий в секунду на ядро. Ваш будет другим.
    • Если вы используете каналы в очереди, у вас даже может быть несколько уровней синтаксического анализа в зависимости от того, как распределяется ваша рабочая нагрузка.
    • Эта группа - высокопроизводительный процессор. Насколько высока ОЗУ, зависит от того, насколько грубыми будут ваши фильтры.
  4. Уровень хранилища. В классическом ELK это ElasticSearch. Однако этого не должно быть.
    • Кластер ElasticSearch, обрабатывающий 300 миллионов событий в час, будет большим. Этого не избежать. Размер зависит от того, как долго вы хотите хранить данные.
    • Похоже, ваши потребители ждут файлов. Это тоже можно сделать. Таким образом, отправляются обработанные события (которые представляют собой просто JSON) в еще одну систему очередей для использования другой системой.

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

Это также обеспечивает некоторое разделение безопасности между вашим архивом журналов (ElasticSearch) и вашими производственными ресурсами. Если кто-то из них нападает на злого человека, наличие буфера очереди означает, что они не могут напрямую очистить ElasticSearch от своего присутствия. Это важно, если в вашей компании есть служба безопасности, и при 300 млн событий в час вы, вероятно, достаточно велики, чтобы ее создать.

Очки против системы Кролика больше связаны с отсутствующими функциями. Rabbit - это система очередей, которая сама по себе не обеспечивает никакого способа преобразования данных (L в ELK) или сохранения их для отображения (E и K в ELK). Система архивирования журналов, которая не может отображать то, что хранится, не является хорошей системой архивирования журналов.

По большей части придерживаюсь @ sysadmin1138, но хочу предупредить вас о сравнении двух разных вещей. ELK - это реализация трех отдельных приложений, которые предоставляют решение для агрегирования журналов (F / OSS конкурент Splunk), где RabbitMQ - это очередь сообщений.

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

ELK и RabbitMQ очень хорошо масштабируются, но для эффективного управления требуется некоторый опыт. С учетом сказанного, если вы не используете и не управляете кластером ELK в любом масштабе (скажем, по крайней мере 5 узлов ES), возможно, вы захотите избежать использования ELK в качестве собранной системы с непреднамеренной целью.

В зависимости от типов поступающих сообщений и места обработки результатов для меня это звучит так, как будто вам, вероятно, лучше использовать кластер MQ и пулы приложений, которые выполняют задания и действуют в соответствии с ними. Но в этот момент вы говорите о важном проекте, который, вероятно, требует участия архитектора программного обеспечения и архитектора операций для ознакомления с вашими бизнес-требованиями и рабочим процессом. (т.е. более сложный, чем вопрос ServerFault.)