Graylog pipeline rule syntax errors (I guess?)

Graylog Central (peer support)
, , ,
1

I was working on changing a pipeline rule for better processing. I changed the conditional statement from
has_field("winlogbeat_source_name") AND NOT contains(to_string($message.winlogbeat_source_name), "Microsoft-Windows-Sysmon")

to

has_field("winlogbeat_source_name") AND NOT to_string($message.winlogbeat_source_name) == "Microsoft-Windows-Sysmon"

Rule was accepted syntactically by the pipeline rule creation. As soon as I implemented I got thousands upon thousands of the following messages from the graylog server:

2018-09-13T19:22:14.630Z WARN  [ProcessBufferProcessor] Unable to process message <52249861-b78a-11e8-8744-0adf684f2f04>: java.lang.ClassCastException: org.graylog.plugins.pipelineprocessor.ast.expressions.FunctionExpression cannot be cast to org.graylog.plugins.pipelineprocessor.ast.expressions.LogicalExpression

I cannot figure out what is wrong with my syntax because I have another very similar conditional statement that is working fine. The only difference in the two similar ones is this is using AND NOT. The other one is using AND. Is this a bug or am I just missing something?

2

Hi!

Is there more to the exception to have a better pointer for debugging?

Without being at the computer right now, this looks like an issue with operator precedence or expression construction:
The NOT is trying to evaluate something that has boolean value, the type checker apparently accepts it (otherwise you would get an error while editing) but when executed it doesn’t get the result of the == but the function call to_string.

I think you are correct in assuming this to work, I’ll look into in tomorrow morning.
For now, I believe it should work if you added parentheses around the to_string() == "..." expression.

3

Yeah just checked the grammar, NOT binds closer than == so it will try to run (NOT to_string(...)) == "...".

However the type checker should’ve rejected this, but I think it still cannot see beyond function calls, so it should now allow the code as it is and instead give a proper error message.

4

Thank you @kay! Glad it was not just me writing a really bad query.