$ raku -MJSON::Fast -e '
loop {
say to-json :!pretty, %(:type<bla>, :a(^100 .pick), :b(^100 .pick))
}
' | bin/eel -l=events2.log -e='
event ble {
has $a1 = #1.a;
has $a2 = #2.a;
has $b1 = #1.b;
has $b2 = #2.b;
match {[
& bla(#1, a == 42, ?b == #2.b)
& bla(#2, a == 13, ?b == #1.b)
]}
}
'
{"a1":42,"a2":13,"b1":22,"b2":22,"timestamp":"2020-02-20T04:19:47.178670Z","type":"ble"}
{"timestamp":"2020-02-20T04:19:47.515712Z","type":"ble","b2":43,"b1":43,"a2":13,"a1":42}
{"b2":45,"type":"ble","timestamp":"2020-02-20T04:19:51.563406Z","a1":42,"a2":13,"b1":45}
{"b2":99,"type":"ble","timestamp":"2020-02-20T04:19:52.089484Z","a1":42,"a2":13,"b1":99}
{"b2":19,"type":"ble","timestamp":"2020-02-20T04:19:54.037338Z","a2":13,"a1":42,"b1":19}
{"b2":10,"type":"ble","timestamp":"2020-02-20T04:19:55.338196Z","a2":13,"a1":42,"b1":10}
{"b2":81,"timestamp":"2020-02-20T04:19:55.971652Z","type":"ble","a2":13,"a1":42,"b1":81}
{"b2":49,"timestamp":"2020-02-20T04:20:04.710167Z","type":"ble","a1":42,"a2":13,"b1":49}
{"a1":42,"a2":13,"b1":52,"b2":52,"timestamp":"2020-02-20T04:20:05.310459Z","type":"ble"}
{"b2":49,"timestamp":"2020-02-20T04:20:06.304376Z","type":"ble","a1":42,"a2":13,"b1":49}
^C
It's an idea of a solution for complex event processing, it's divided into 3 main parts:
-
parse:
it should parse a language based on raku's grammar and raku's class
syntax meaning 5min time applied for the last construct (units: s, min, h, days) [ A ] group A & B A AND B in any order A && B A AND B on that order A | B A OR B ** N indicates that the last matcher should be matched N times ** N..M indicates that the last matcher should be matched at least N times and max M bla() matches an event called bla
bla( value > 3 ) matches an event called bla
where value is greater than 3$ble event propert called ble #bli internal name for a specific event ?attr = #blo.attr test if attr
is equal to#blo.attr
only if#blo
is defined[ bla( #blabla, ?id == #bleble.id ) & ble( #bleble, ?id == #blabla.id ) ] 5min matches 2 events ( bla
andble
) at any order that has the same id and were dispatcher at max 5 min intervalit should check most of things on parse time. its first draft is here and some examples here and a code to run this here
Something like this:
event temperature { has $value, $area } event humidity { has $value, $area } event fire-risk { has $temperature = #temp.value; has $humidity = #hum.value; match { [ & temperature(#temp, value > 40, ?area == #hum.area ) & humidity(#hum, value < 20, ?area == #temp.area) ] 5min } }
should be transformed into something like this:
my @rules = { cmd => "query", query => %( :type("==" => "temperature"), :value(">" => 40) ), id => "#temp", store => < value area >, next => { cmd => "query", query => %( :type("==" => "humidity"), :value("<" => 20), :area("==" => -> %state { %state<#temp><area> }) ), id => "#hum", store => < value area >, next => { cmd => "dispatch", data => -> %state --> Hash() { :type<fire-risk>, :area(%state<#temp><area>), :temperature(%state<#temp><value>), :humidity(%state<#hum><value>) }, } } }, { cmd => "query", query => %( :type("==" => "humidity"), :value("<" => 20) ), id => "#hum", store => < value area >, next => { cmd => "query", query => %( :type("==" => "temperature"), :value(">" => 40), :area("==" => -> %state { %state<#hum><area> }) ), id => "#temp", store => < value area >, next => { cmd => "dispatch", data => -> %state --> Hash() { :type<fire-risk>, :area(%state<#temp><area>), :temperature(%state<#temp><value>), :humidity(%state<#hum><value>) }, } } } ;
Usage:
bin/eel [-l|--log=<Any>] [-d|--debug] <file>
bin/eel -e|--eval|--evaluate|--code=<Str> [-l|--log=<Any>] [-d|--debug]
It accepts some EEL code (by file or by -e flag) and reads STDIN line by line for JSON object. And prints back all recognized patterns.
-
runner:
It should accept the structure created by the parser and use it to add some queries on the query storage. It should connect to N streams (log file, kinesis, kafka, eventsource, websocket, rabit MQ, etc) and following the given rules, generate new events. There are some examples of that should work here.
Once you describe what properties (and possibly those types) each event should have, it will also validate events, and create a error event always it finds an invalid event.
Each step of the recognition of the pattern should store on the QueryStorage along with the query itself the next steps for that pattern. So, for instance, your pattern is:
get-login-page(#login-page) post-login(form-id == #login-page.form-id, status-code == 200)
, then, it will add on the query storage the query:{ :type<get-login-page> }
, and on it's data information saying that on the next it should match{ :type<post-login>, :form-id(XXX), :status-code(200) }
whenXXX
is theform-id
gotten fromget-login-page
. -
query storage:
is a way to store queries and when the events are dispatched, find what queries match that object and that way match each part of the track. currently it's being implemented here, but optimally it should be an central process (as a database).