Анализ журналов событий в реальном времени с помощью Elasticsearch

Question

Я собираю журналы событий каждый раз, когда изменяется свойство какого-либо устройства. Для этого я решил использовать:

1. Logstash - где мой агент IoT приложение отправляет журналы в формате JSON,
2. Elasticsearch - для хранения данных (журналы),
3. Kibana - для визуализации данных.

JSON с бревнами в настоящее время отправить через регулярные промежутки времени и его форма выглядит следующим образом:

{"deviceEventLogs":[{"date":"16:16:39 31-08-2016","locationName":"default","property":"on","device":"Lamp 1","value":" 
false","roomName":"LivingRoom"}, ... ,]} 

Пример записи одного события в Elasticsearch выглядит следующим образом:

{ 
      "_index": "logstash-2016.08.25", 
      "_type": "on", 
      "_id": "AVbDYQPq54WlAl_UD_yg", 
      "_score": 1, 
      "_source": { 
       "@version": "1", 
       "@timestamp": "2016-08-25T20:25:28.750Z", 
       "host": "127.0.0.1", 
       "headers": { 
        "request_method": "PUT", 
        "request_path": "/deviceEventLogs", 
        "request_uri": "/deviceEventLogs", 
        "http_version": "HTTP/1.1", 
        "content_type": "application/json", 
        "http_user_agent": "Java/1.8.0_91", 
        "http_host": "127.0.0.1:31311", 
        "http_accept": "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2", 
        "http_connection": "keep-alive", 
        "content_length": "34861" 
       }, 
       "date": "2016-08-08T14:48:11.000Z", 
       "device": "Lamp 1", 
       "property": "on", 
       "locationName": "default", 
       "roomName": "LivingRoom", 
       "value_boolean": true 
      } 
} 

Моя цель заключается в создании веб-сайта с какой-то приборной панелью, на которой анализируются данные в режиме резонансного времени (допустимо несколько минут):

• показывает историю потребления энергии и прогнозирование потребления в особенности
• обнаружения аномалий в потреблении энергии и другие факторы, такие как огни или нагревательного использование
• показывает Рекомендацию основано на каком-то не замысловатые статистики, т.е. «вы можете переместить данное устройство от LOCATION1 к LOCATION2, потому что это нужнее там (более интенсивно используется, чем в другом месте)»и т.д.

Хотя последний пункт довольно тривиально - я могу использовать простой запрос или агрегации в Elasticsearch, а затем сравнить это до некоторой стоимости, первые два пункта требуют углубленного анализа lik e машинное обучение или интеллектуальный анализ данных.

На данный момент система оснащена около 50 устройствами, обновляющими их состояние каждые 10 секунд в среднем. В будущем количество устройств может увеличиться до 50 000. Ассимиг 100 байт для одного журнала событий может привести примерно в 15 терабайт данных в Elasticsearch в год.

Общий вопрос: какими могут быть резонансные решения/технология/архитектура такой системы?

1. Является ли это резонным началом для хранения всех моих журналов в Elasticsearch?
2. Я рассматриваю библиотеку es-hadoop, чтобы использовать Elasticsearch вместе с Apache Spark, чтобы иметь возможность обрабатывать мои данные с помощью Mlib в Spark - это направление, на которое нужно идти?
3. Могу ли я использовать только Elasticsearch для хранения всех моих данных в нем и просто использовать Spark и Mlib для углубленного анализа или я должен рассмотреть возможность реализации так называемой «Лямбда-архитектуры», рассматривающей Elasticsearch как уровень скорости? Я немного покрасил о различных конфигурациях, где использовался Kafka, Apache Storm, но я не уверен, что мне это нужно. Поскольку проект должен быть выполнен в течение одного месяца, и я новичок, меня беспокоит сложность и, следовательно, время, необходимое для такой реализации.
4. Что делать, если загрузка данных будет в 10 раз меньше (около 1,5 терабайт в год) - будет ли ваш ответ одинаковым?

Answer 1

Это очень сложный вопрос, позвольте мне попытаться разбить его:

Вопросы, которые вы должны думать о

• Что такое задержка из конца в конец для вашего данные будут доступны для запросов? Вам это нужно в режиме реального времени, или вы в порядке с задержками?
• Какова потеря данных, которую вы готовы терпеть?
• Какова точность алгоритмов аналитики/ML, на которые вы смотрите? Вам нужны очень точные результаты, или вы в порядке с некоторыми неточностями?
• Вам нужны результаты только в том случае, если они полны или вам нужны какие-то спекулятивные результаты?

Эти вопросы наряду с регулярными лицами, такими как ограничения пространства и задержки при увеличении нагрузки и т. Д., Помогут вам определить правильное решение.

Как правило, эти проблемы можно рассматривать как проглатывание -> обработка -> презентация.

Глотание - Потребность в сообщении Bus

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

Processing - Потребность в масштабируемой вычислительном слоя

Это где вам нужно принять решение о такие как обработка в режиме реального времени или пакетной обработки, применимые потери данных, точность и спекулятивные результаты и т. д. Прочтите статью Тайлера Акидау о потоковой передаче по адресу https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101 для подробного объяснения.

Люди выбирают Spark streaming для использования в режиме реального времени и простое задание M/R должно делать трюк для пакетных заданий. Если вы планируете выполнять потоковые задания, то оконные и сеансы событий могут усложнять ситуацию.

Презентация - Потребность в интерактивных запросов и быстрых ответов

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

Такие инструменты, как ES, очень хорошо работают для поиска, фильтрации и огранки, но не работают, когда возникает необходимость в сложных математических агрегатах. AFAIK ES не поддерживает вероятностные структуры, такие как HyperLogLog, как Druid.

дооснащения

Теперь вы должны сопоставить требования, которые имеют с каждым из указанных слоев.

показывает историю потребления энергии и прогнозирование потребления в функции

обнаружения аномалий в потреблении энергии и другие факторы, такие как огни или нагревательного использование

Вы явно нуждаетесь библиотеки машинного обучения, как у вас есть упоминается. Spark с поддержкой MLib является супер-удивительным.

показывает Рекомендацию основано на каком-то не замысловатые статистики, т.е. «вы можете переместить данное устройство от LOCATION1 к LOCATION2, потому что больше там нужно (более интенсивно используются, чем в другом месте)» и т.д.

Вы также можете сделать это с помощью MLib на Spark и дать рекомендации, закачиваемые в отдельный индекс в ES или даже тему Kafka, которую вы можете получить до HDFS или ES. Вы должны быть осторожны с сборкой мусора здесь, так как это может привести к взрыву данных, и вам нужно быть агрессивным относительно сохранения здесь. Кроме того, рекомендации по компьютеризации помогают вам реагировать на такие вещи, как оповещение, push-уведомления и даже запрос из пользовательского интерфейса, будут быстрее.

Присвоение 100 байт для одного журнала событий может привести к приближению около 15 терабайт данных в Elasticsearch в год.

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

Является ли резонансное начало хранить все мои журналы в Elasticsearch?

Очень так, учитывая ваш прецедент. Но если вы используете Spark streaming/MLib или пакетное задание MR, тогда вы даже можете использовать немые хранилища данных, так как большинство вычислений происходит раньше.

Я рассматриваю библиотеку es-hadoop, чтобы использовать Elasticsearch вместе с Apache Spark, чтобы иметь возможность обрабатывать мои данные с помощью Mlib в Spark - это приемлемое направление?

Похоже, вы решили провести пакетную обработку, и в этом случае вы можете использовать стандартную MR или искровую партию вместе с MLib. Если вам нужно в реальном времени, вам нужно что-то вроде Kafka и использовать искрообразование. Если вы справитесь с потерей данных, вы можете проявить агрессивность в отношении удержания и даже в Spark, когда вы решите интервалы между окнами/скользящими интервалами и т. Д. Если вы не уверены, что результаты являются неточными, вы можете использовать вероятностные структуры данных (например, цветение фильтр, hyperloglog - друид поддерживает это), чтобы представить результаты.

Могу ли я использовать только Elasticsearch хранить все свои данные в нем и просто использовать Спарк и Mlib, чтобы обеспечить детальный анализ или я должен рассмотреть вопрос о внедрении так называемых «Лямбда Architecture» лечение Elasticsearch как Speed ​​Layer?

Я не уверен, можете ли вы передавать данные из ES на Spark.И лямбда-архитектура чрезмерно раздута и помогает только в том случае, если вы точно знаете, что ваш уровень в реальном времени является неточным, и вы не можете обрабатывать потери/неточности данных. В противном случае простое искрообразование, считывающее данные с Кафки и перекачки в ЭС, должно быть более чем достаточно. Пожалуйста, подумайте об измерении потери данных, прежде чем принимать решение о разработке таких архитектур, как Lambda, поскольку эксплуатационные расходы (например, дублирующий код, дополнительная инфраструктура для обслуживания и т. Д.), Вероятно, высоки.

Что делать, если загрузка данных будет в 10 раз меньше (около 1,5 терабайт в год) - будет ли ваш ответ одинаковым?

Я бы по-прежнему предпочитал ту же архитектуру - Kafka + Spark streaming (MLib) + ES/Druid - это проще реализовать и упростить для обслуживания.