Trialing Log server as a potential SIEM solution.
All the @timestamps are off. I’ve followed the documentation, our log server TZ set correctly, but in the log tables the @timestamp field is set to UTC+9. The Cluster Timezone is set to UTC-8 Pacific Time (US & Canada).
An example is attached. The 'TimeGenerated' and 'ReceiveTime' fields are from the syslog message and correspond within a few seconds of when the entry actually shows up in NLS.
Our TZ is PST8PDT, and the @timestamp field is logging entries in UTC+9
@alder:/var/log/net$ timedatectl
Local time: Thu 2026-03-19 10:10:41 PDT
Universal time: Thu 2026-03-19 17:10:41 UTC
RTC time: Thu 2026-03-19 17:10:41
Time zone: America/Los_Angeles (PDT, -0700)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
@timestamp value is in some random tz
-
corwingrey
- Posts: 2
- Joined: Tue Feb 18, 2020 6:25 pm
@timestamp value is in some random tz
You do not have the required permissions to view the files attached to this post.
- jmichaelson
- Posts: 379
- Joined: Wed Aug 23, 2023 1:02 pm
Re: @timestamp value is in some random tz
Which version of Log Server are you using?
Your sources should be configured to send logs to NLS with their timestamps set to UTC as this is how they are stored and processed internally, this in particular applies to the @timestamp field, which is take from whatever timestamp your inputs and filters can parse from the incoming log message. If the timestamps in the logs don't have a time zone reference attached to them they are assumed to be UTC, so your easiest route would be to ensure that if the times aren't coming in as UTC that they have a timezone offset attached to them. For example the rsyslog instructions we provide ensure that the timezone of the syslog entry has a timezone in it.
Your sources should be configured to send logs to NLS with their timestamps set to UTC as this is how they are stored and processed internally, this in particular applies to the @timestamp field, which is take from whatever timestamp your inputs and filters can parse from the incoming log message. If the timestamps in the logs don't have a time zone reference attached to them they are assumed to be UTC, so your easiest route would be to ensure that if the times aren't coming in as UTC that they have a timezone offset attached to them. For example the rsyslog instructions we provide ensure that the timezone of the syslog entry has a timezone in it.
Please let us know if you have any other questions or concerns.
-Jason
-Jason