I have installed the OVA 3.0.2-1 and have also configured 3 Inputs for sending logs from 3 different wildfly instances using the GELF-Logger from here: https://logging.paluch.biz/examples/wildfly.html
Logs are coming into the Graylog server but when I tried to configure my first extractor and clicked on “Load message” in order to load the most recent message received within the last hour (which is the only way to create the first extractor apart from importing one), I got the message: “Error. Input did not return a recent message”
When I go to the input and click on “Show received messages” I can see that there are many messages within the last hour, being the last one 5 minutes ago.
If I go to the Search-Tab and search for message within 1 or 2 hours no messages are shown. Only when I select the 8-hour-search I see all the messages (showing first the last one 5 minutes ago).
If I use the absolute search with a period of time within the last hour, messages are shown.
So I suppose this is a problem related to the timezone settings of the graylog server? I checked under System/Overview and I can see:
User admin: 2019-07-09 13:34:16 +02:00
Your web browser: 2019-07-09 13:34:16 +02:00
Graylog server: 2019-07-09 13:34:16 +02:00
They are all showing the right time with the right timezone.
Under server.config the root_timezone is set to CET (I updated this)
The VM of graylog has the folllowing timezone: CET (also updated by myself)
The original System/Overview was:
User admin: 2019-07-09 11:34:16 +00:00
Your web browser: 2019-07-09 13:34:16 +02:00
Graylog server: 2019-07-09 11:34:16 +00:00
When the messages received were showing the wrong timestamp.
root_timezone is the timezone of the user root_username not the timestamp that is used in Graylog. (most time the timezone for the user admin, if not renamed from default)
So is the actually the timestamp of the message itself correct? Or is that 2 hours off?
you never mentioned what you ingest … if your messages do not contain any timezone information syslog input in graylog will assume it is utc … if that is not the case you need to adjust this with a processing pipeline.