ELK - нерегулярный журнал с несколькими форматами и многострочными событиями

У меня есть трассировка/журнал событий (в виде «сообщений»), поступающих от некоторого коммуникационного оборудования. Моя конечная цель — иметь возможность выполнять некоторый мониторинг и анализ потока данных, поступающих от оборудования, в (близком к) режиме реального времени.

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

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

В настоящее время я сталкиваюсь с двумя проблемами (хотя только начал :-):

События с несколькими сообщениями

Некоторые события появляются поверх нескольких сообщений.

  • Связанные сообщения не обязательно идут подряд.
  • Обычно первое сообщение сообщает, что событие сегментировано, сколько сегментов следует ожидать, и включает идентификатор события (ключ).
  • Остальные сегменты имеют одинаковый идентификатор события
  • Заголовок сегментации и другие сегменты имеют собственный идентификатор преамбулы/типа.
  • Сегментированные сообщения просто «обрезаются» посередине и продолжаются в следующем сообщении. Например, "<key xyz part 1> ... 12345", а затем "<key xyz part 2> 67890 ..."

Несколько типов событий (с "нестандартным" содержанием)

  • Есть несколько типов событий (от 20 до 50 вероятностей).

  • Содержание каждого мероприятия разное.

  • Текст события не следует какому-либо «фиксированному» шаблону. Кажется, он содержит свободный текст, пары ключ-значение с разделителем "=" и пары ключ-значение с разделителем ":". Единственное, что здесь может помочь, так это то, что «поля» (если их можно так назвать) чаще всего разделяются знаком «;».

  • Некоторые поля даже не имеют значений.

  • (Я не уверен на 100%, но) кажется, что полезная нагрузка (с точки зрения полей) может меняться даже в пределах одного и того же типа сообщения.

Некоторые примеры (которые я "запутал")

[2016-08-11 11:47:44.340] [011400\00]1/RncLmUePT(1/someResource[209]) ../filename.cpp:335 INFO: сигнал some_signal_name получен в капсуле nameOfSomething@someResource в состоянии SomeEventName. Это указывает на TYPE_OF_EXEPTION, переданный в AnotherPlace.

Или эти 5 сообщений, которые являются примером события с несколькими сообщениями. Обратите внимание на неправильность последнего сообщения (оно начинается немного по-другому) и на то, что 3-е и 4-е сообщения обрезаны «на середине предложения».

[2016-08-11 11:47:44.340] [021100\01]2/PdcLmPrPT somefile.cc:172 INFO:‹ Сегментация трассировки для ключа 000001216649856, далее следуют 4 части >

[2016-08-11 11:47:44.340] [021100\01]2/PdcLmPrPT somefile.cc:179 ИНФОРМАЦИЯ: "ExceptionCode = 521; TIMER somename истек; InterfaceTimout (внутренний); Ueh; SomeCrypticName; не влияет на соединение ;callProc = ИмяПроцедурыX;DeviceRef = 2060; CLIENT_CODE = UNDEF; CLIENT_CODE2 = 1424514436 [0x54e85d84]; devId = 33456; devFroId = 871; prDevId = UNDEF; prDevFroId = UNDEF; spId = tc:p:20d:225; "

[2016-08-11 11:47:44.340] [021100\01]2/PdcLmPrPT somefile.cc:179 INFO: "S-RNFF = 377540; код причины = UNDEF; ЧТО-ТО не получено; sourceType = devNoValid; sPJK=0000000000000000000000000; targetType = someConnType; sPJK=000000000000000000000000;UE Cap = Rel9-0000000000000000000000000000000010;fileName = ../anotherFileName.cpp;line = 9031;Предыдущее состояние = someStateName;Текущее состояние ="

[2016-08-11 11:47:44.340] [021100\01]2/PdcLmPrPT somefile.cc:179 INFO:" WaitSomeOtherState;noOfSomeConnectionState = 459;noOfSomeResUsage = 598;ActiveDevId = [6548,-1,-1,- 1,-1].

[2016-08-11 11:47:44.340] [021100\01]2/PdcLmPrPT(2/SOME_EXCEPTION) ../DifferentFile.cpp:4610 TRACE1:"se является Registration(12). Ни установка соединения PPT завершена, ни POMP Получена индикация восстановления связи».

Я думал поместить эти данные в Elastic Search для визуализации (kibana) и т. д., и я не уверен, является ли logstash инструментом для работы (или, по крайней мере, существующими кодеками/плагинами/фильтрами). Я готов услышать о других/лучших фреймворках

Из того, что я читал / понял до сих пор, для более «обычных» данных я бы использовал многострочный кодек и фильтр grok с простым эластичным плагином вывода, но здесь я не вижу, что эти инструменты являются жизнеспособным вариантом. . (Правильно ли я оцениваю?)

Я подумал, может быть, попробовать написать какой-нибудь плагин logstash самостоятельно или обработать трассировку с помощью отдельной программы.

Любые мысли или идеи, как я могу использовать существующие инструменты или, альтернативно, что было бы хорошим подходом для этого сценария?

P.S. У меня нет опыта работы с Ruby, но я довольно свободно разбираюсь в java/js/python и .NET (C#)

P.S.2 Я не залочен на 100% на ELK. Кажется, это один из самых распространенных инструментов для такой работы. Я также рассматриваю TSDB или даже базы данных столбцов/документов.


elastic-stack logstash logstash-grok elasticsearch
person Tomer Cagan    schedule 06.09.2016    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Поскольку многострочные сообщения не являются последовательными, вам придется написать какой-нибудь синтаксический анализатор с отслеживанием состояния, который выясняет, как сшивать сообщения вместе. Если бы это было последовательно, вы, вероятно, могли бы использовать шаблоны logstash grok, чтобы определить начало и конец каждого сообщения.

Альтернативный подход — просто использовать шаблон grok для извлечения идентификатора сообщения и добавления его в качестве атрибута в сообщение журнала. Тогда вы получите отдельные сообщения в Elasticsearch. Однако на панели инструментов Kibana вы можете легко ограничить поиск идентификатором сообщения, чтобы получить все события, связанные с идентификатором сообщения. Это может быть достаточно хорошо для ваших целей.

person Jilles van Gurp    schedule 06.09.2016
comment
В приведенных выше настройках, ослабит ли проблема с порядком (при условии, что они последовательны), многострочный фильтр может справиться с этим? - person Tomer Cagan; 06.09.2016
comment
если вы можете придумать регулярное выражение, это должно быть выполнимо с помощью logstash - person Jilles van Gurp; 07.09.2016

arrow_upward
0
arrow_downward

Вы можете написать рубиновый фильтр, который выполняет комбинацию grep/sed/awk для получения необходимых данных из входного файла и сохранения этих данных как события. Недостаток здесь в том, что вам нужно, чтобы файл сохранялся в памяти для выполнения операции.

фильтр {

 ruby {
code => 'require "open3"
         file_path = event.get("file_path")
         cmd =  "my_filter.sh -f #{file_path}"
         stdin, stdout, stderr = Open3.popen3(cmd)
         event.set("process_result", stdout.read)
         err = stderr.read
         if err.to_s.empty?
           filter_matched(event)
         else
           event.set("ext_script_err_msg", err)
         end'
  remove_field => ["file_path"]

} }

person NinjaSolid    schedule 21.09.2017