Unable to Drop syslog messages based on message contents

Graylog Central (peer support)
1

HI All,

I am encountering an issue with pipeline configuration where I seem to be unable to drop Syslog messages based on the message contents.

I have done some googling / searching of the forum and the other suggestions don’t seem to be helping.

I am running Graylog 4.1.14-1 on Ubuntu 22.04.1 LTS

An example of the message type I am trying to drop is below:

%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/32 (not half duplex), with -Device Name- GigabitEthernet0 (half duplex).

I have created a new pipeline and attached it to the all messages stream with the following rule attached. to the Stage 0 section of the pipeline

rule "Drop CDP Duplex Noise"
when 
    contains(to_string($message.msg), "duplex mismatch") 
then 
    drop_message();
end

Under the Message processor configuration, I have the default pipeline processor then the message filter chain. I did try reordering them but didn’t have any luck with that.

2

Hello,

Have you tried.

contains(to_string($message.msg), "DUPLEX_MISMATCH")

By chance is that a custom field “message.msg”?

Have you seen this post?

3

Hi,

Thanks for the response.

I have tried a number of different combinations and interestingly I have created another pipeline rule that actually works as intended

This rule drops the SpamAPTask messages from our WLC’s

rule “Drop SpamApTask”
when
contains(to_string($message.message), “spamApTask”)
then
drop_message();
end

But the CDP Mismatch error still doesn’t get dropped. I have updated the rule as per below but still doesn’t seem to be having the desired effect.

rule “Drop CDP Duplex Noise”
when
contains(to_string($message.message), “DUPLEX_MISMATCH”)
then
drop_message();
end

4

I see, have you tried the debug() in the rule?

5

Thanks for the tip around the debug function.

I wrapped the debug around the drop_message function and I get the following output in the log.

2022-08-12T12:33:13.065+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.
2022-08-12T12:33:13.066+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.
2022-08-12T12:33:13.360+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.
2022-08-12T12:33:14.066+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.
2022-08-12T12:33:15.076+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.
2022-08-12T12:33:15.874+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.
2022-08-12T12:33:16.743+10:00 INFO [Function] PIPELINE DEBUG: Passed value is NULL.

6

I see, so its not even grabbing it.
Wonder if its because it looks like this %CDP-4-DUPLEX_MISMATCH

7

I just tried updating the message with the full message value and I get the same result in the log file.

Would I need to escape out the %?

8

I think so, and double escape it \\. Doesn’t hurt to try.

Been think about this, I’m wonder if maybe regex to grab that unique string then drop it. Just an idea, I haven’t done it yet.

EDIT: I don’t have time tonight to lab this out but if @tmacgbay is around he may have an idea. If not I’ll be able to help more tomorrow

9

I think you want $message.message here because you are checking to see if the entire message has an instance of "duplex mismatch"

rule "Drop CDP Duplex Noise"
when 
    contains(to_string($message.message), "duplex mismatch") 
then 
    drop_message();
end
10

Thanks for the reply, I have changed it to $message.message and still having issues dropping the messages.

11

Try:

rule "Drop CDP Duplex Noise"
when 
    contains(to_string($message.message), "duplex mismatch") 
then
 // use $ tail -f /var/log/graylog-server/server.log to watch for the results of the below debug message
 //
    debug("_*_*_* - Drop Message rule was hit."); 
    drop_message();
end

If the debug statement doesn’t appear in your server log then “duplex mismatch” is not being found in the message… check to make sure the pipeline is attached to the correct stream and if it is, are there other pipelines attached to the stream or other rules/stages that run before this one?

12

Hi All,

Just wanted to come back and say I had resolved the issue.

It appears for whatever reason the rule was just broken, deleting and recreating it seemed to of resolved the issue.

Thanks for all your assistance, its been much appreciated.

2 Likes
13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.