Время между первым и вторым событием

Elastic In Your Native Tongue Вопросы на русском языке
1

Доброго дня Коллеги,

не совсем понимаю как правильно подойти к решению задачи.

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

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

Мне надо как преобразовывать формат представления времини для данного вычисления?

или это решается по другому?

2

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

3

Игорь спасибо за ответ,

поясните пожалуйста:

связь "родитель-потомок" выстараивается уже в ES при помощи скриптов, запускаемых отдельно.
Скрипт ищет совпадения и присваивает признаки
так?

а как регистрируется процес дублирования информации по id, тоже скриптами и тоже после попадания в ES?

дополнительную информацию надо в книге смотреть, тут?
https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child.html

4

связь "родитель-потомок" выстараивается уже в ES при помощи скриптов, запускаемых отдельно.
Скрипт ищет совпадения и присваивает признаки
так?

Связь "родитель-потомок" устанавливается при создании дочернего документа. После того, как дочерний документ проиндексирован, его присвоить родителю уже нельзя. Можно только его удалить, и создать новый документ с новой связью.

а как регистрируется процес дублирования информации по id, тоже скриптами и тоже после попадания в ES?

Я не понял вопрос. О каких скриптах идет речь?

5

Игорь прошу прощения за неясность формулировок, "матчасть" в процессе изучения.

сейчас события логов попадают в ES через LS, и если я правильно понимаю именно в нем я должен выстроить связь "родитель-потомок". Правда не понимаю как (

О о баш скриптах которые делают выборку событий по определенным признакам, а потом пересоздают документы.

Я так понимаю, что я совсем все не правильно понимаю?

6

сейчас события логов попадают в ES через LS, и если я правильно понимаю именно в нем я должен выстроить связь "родитель-потомок". Правда не понимаю как (

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

7

Спасибо Игорь,
я как раз сейчас думал выслать пример и поянить свою размытую мысль конретикой )
{
"@version" => "1",
"@timestamp" => "2016-07-21T22:40:31.971Z",
"type" => "mtsl",
"vpnprotocol" => "L2TP",
"vpnclientsourceip" => "y.y.y.y",
"username" => "pv",
"vpnclientinternalip" => "x.x.x.x",
"vpnclientauth" => "login susseful"
},
"tags" => [
[0] "multiline"
]
{
"@version" => "1",
"@timestamp" => "2016-07-21T22:40:47.404Z",
"type" => "mtsl",
"vpnprotocol" => "L2TP",
"username" => "pv",
"vpnsessiontime" => "15",
"vpnclientauth" => "logout susseful"
}

в идеале у меня есть адреса, логин и время сесии.
на основе времини и локального адреса я могу смотреть например netflow статистику.

8

А какой нибудь контроль над тем что и как записывается в лог у Вас есть? Или что записалось - то записалось и вам потом разбирать?

9

да, есть раздел filter в конфиге LS

исходный формат сообщений, до обработки
вход
"pptp,info TCP connection established from y.y.y.y"
"pptp,ppp,info,account pv logged in, x.x.x.x"
выход
"pptp,ppp,info,account pv logged out, 845(это время сеанса в секундах) 215057 417433 1073 1106"

10

теоритически <46> может быть тем самым искомым id

Не думаю, <46> на syslog priority больше похоже. A нам нужно получить строку, которая бы была уникальна в индексе. Я боюсь, что для соединения этих двух записей надо либо фильтр, либо кодек для logstash писать.

11

частично,
это Микротиковский роутер и он либо шлет сообщения сислог в указанном выше формате или в BSD стиле
{
"message" => "<46>Jul 22 02:02:01 NET-031 first L2TP UDP packet received from y.y.y.y",
"@version" => "1",
"@timestamp" => "2016-07-21T23:02:01.166Z",
"type" => "mtsl",
}
{
"message" => "<46>Jul 22 02:02:01 NET-031 pv logged in, x.x.x.x",
"@version" => "1",
"@timestamp" => "2016-07-21T23:02:01.224Z",
"type" => "mtsl",
}
{
"message" => "<46>Jul 22 02:02:07 NET-031 pv logged out, 7 13081 27689 109 91",
"@version" => "1",
"@timestamp" => "2016-07-21T23:02:07.853Z",
"type" => "mtsl",
}

теоритически <46> может быть тем самым искомым id, но в документации я не нашел прямого указания на это.

12

проверил, нет, это код сообщения: ошибка, инфо и пр

13

теоритически <46> может быть тем самым искомым id

Не думаю, <46> на syslog priority больше похоже. A нам нужно получить строку, которая бы была уникальна в индексе. Я боюсь, что для соединения этих двух записей надо либо фильтр, либо кодек для logstash писать.

14

похоже вы правы, я расширил список категорий по которым логируется вход выход.
там есть уникальные коды, например id к радиус серверу.
но там многострочные логи, которые при нескольких коннектах надо еще и правильно объеденить (

Игорь, для финализации моего понимания.
следующий запрос на ES не реализуем?

есть время завершения и кол-ва времини в сеансе,

  1. отнять из времини завершения кол-во секунд и получить время старта
  2. на время старта получить сообщение о входе
  3. с сообщения входа получить локальный ip

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

15

Если честно, мне такое необычное использование этого фильтра даже в голову не приходило. Теоретически, да - при определенных условиях, это работать может. Практически - это забивание шурупов молотком. При небольшой нагрузке, и если время между входом и выходом достаточно долгое (всегда больше 30 сек, например), оно работать будет. Проблема в том, что записи в elaticsearch не доступны для поиска мгновенно. Они только появляются в индексе после операции refresh, которая автоматически запускается каждую секунду и может продолжаться некоторое время. То есть если между входом и выходом проходит меньше секунды, то есть очень большая вероятность, что поиск запись, соответствующую входу, не найдет. Если сюда еще добавить то, что записи добавляются пачками (через bulk), то получается весьма ненадежное и тяжеловесное решение. Другими словами с минутными интервалами оно работать будет. С секундными - будет работать, но далеко не всегда. При большой нагрузке и с интервалами в секунду и меньше - большинство выходов не найдут своих входов.