Winlogbeat "ignore_older" rule not working

Elastic Stack Beats
1

I've been deploying winlogbeat with graylog-sidecar and for some reason the "ignore_older" option does not work for me.
I am using the latest graylog-sidecar version as well as winlogbeat. In my configuration I have specified the "ignore_older" variable to 72h, however I can see that when I deploy winlogbeat on a new machine I get data that is way older than 72h.

Now this wouldn't be much of an issue, however I am deploying this solution also on some really old servers as well as highly active servers, which results in Graylog clogging up with sometimes even up to 1000000 unprocessed messages.

Here's the config I am using

# Needed for Graylog
fields_under_root: true
fields.collector_node_id: ${sidecar.nodeName}
fields.gl2_source_collector: ${sidecar.nodeId}

output.logstash:
   hosts: ["x.x.x.x:5044"]
path:
  data: ${sidecar.spoolDir!"C:\\Program Files\\Graylog\\sidecar\\cache\\winlogbeat"}\data
  logs: ${sidecar.spoolDir!"C:\\Program Files\\Graylog\\sidecar"}\logs
tags:
 - windows
winlogbeat:
  event_logs:
   - name: Application
     ignore_older: 72h
   - name: System
     ignore_older: 72h
   - name: Security
     ignore_older: 72h

Running latest graylog-sidecar version, latest winlogbeat and Graylog 5.0.8+4c22532

2

Which version number is that?

3

I testing ignore_older using Winlogbeat version 8.9.1. And it worked as I expected under Windows 2022 Server.

4

It is 8.9

5

You can confirm the setting is being passed into Windows by running with debug enabled.

logging.level: debug
logging.selectors: [eventlog]

Then check the logs for a line that contains "using subscription query=" (source). The query is the XML that is passed to Windows during the subscription. Can you post that log here?

The XML in that message is the same thing that you would put in the Windows Event Viewer (like Advanced XML filtering in the Windows Event Viewer | Microsoft Learn).

6

A new problem has appeared, it looks like no new logs are being sent since winlogbeat has been implemented, the sudden influx of messages was some overdue data I guess? On some of the machines nxlog was running but the server's IP has changed and maybe Graylog was getting that data..

Nevermind that, now I have an issue that no logs are being received even though this is the same configuration I have implemented somewhere else and it works as of now; I've just checked. Sidecar logs show no errors and I can also see that Winlogbeat is successfuly "publishing" event logs on the target hosts.

I've gathered this data from \sidecar\logs and \sidecar\cache\winlogbeat\data.
From inspecting the logs there, I can see that there's nothing wrong, no errors.
And there shouldn't be any issue with the port 5044, since I have Linux machines sending data through graylog-sidecar as well and that data gets to graylog without any problems.

Looking at statistics from the "Beats" Input I can see that only Linux hosts have been sending data.

7

Scratch that, I logged in today and the logs are coming in fine, there were maybe 2 hours of inactivity yesterday for whatever reason.

So to summarise:

  • ignore_older works, the huge amount of logs being sent, were overdue nxlog logs that were being backed up by the change in the Graylog server's IP address, for quite some time the logs just failed to send and since the IP was changed to the correct one while I was installing graylog-sidecar, they just flew in.

  • Winlogbeat works as it's supposed to, at the time I was testing it just nothing arrived? Or it had to process something? Who knows, the solution turned out to be -> Go to sleep and check again in the morning.

8

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