Patterns

Logmatch needs to have a file to read patterns/events from. Default location is ./Patterns.

Each pattern needs to be on a separate line and start with a name, followed by ## and then the first thing to match (either <token_name> as a reference to regex or word), then followed by a single space and another thing to match...

It is also possible to append a new pattern while the program is running, to do that put it in on the top line.

Matching a single word

Very simple example of program usage is using Unix command yes (endless generator of y or a given argument). You can match lines containing just y with a single pattern defined as yes##y, try to run: yes | ./jsonizer will keep producing the following output until terminated (with CTRL+C) or otherwise killed

{"Type":"yes","Body":null}

Note that Type contains the pattern name (before ##), Body is empty because there were no tokens used.

Matching with token (regular expression)

If we redefine our pattern to yes##, we will be using a regular expression for any word in our match (instead of just word y in previous example), output will be

...

if we dont want "WORD" (matched token/regex) in our output, we can change our pattern to: yes##<WORD:matched word> to get

...

Matching text line

Now lets generate a more complex lines, yes number 50 ip 127.0.0.1 will keep giving us the same line over and over again, until terminated

number 50 ip 127.0.0.1

if we pipe this to jsonizer with yes number 50 ip 127.0.0.1 | ./jsonizer, we will have to redefine our pattern to match one extra word 50, one extra word ip and one extra word 127.0.0.1 , or we can use regular expression for NUMBER(=50), WORD(=ip), IP(=127.0.0.1), many options present themselves:

our match##number <NUMBER> ip <IP>
our match##number 50 ip 127.0.0.1
our match##<WORD:number_word> <NUMBER> <WORD:ip_word> 127.0.0.1

will give us different corresponding outputs:

It should now be clear how to create your own patterns for whatever log events you might want.