I import al log from an application by nxlog using a filter:
if [type] == 'MyProgram_Requests' {
date {
match => [ 'mp-date', 'M/d/yyyy hh:mm:ss a' ]
target => 'EventTime'
}
}
It works like a charm.
@timestamp
2025-03-27T01:01:45.550+01:00
mp-date
3/26/2025 11:48:07 PM
EventTime
2025-03-26T23:48:07.000Z (the same as mp-date)
And now I would order by EventTime... this is the result.
2025-03-26T23:54:25.000Z
2025-03-26T23:48:34.000Z
2025-03-26T23:53:24.000Z
2025-03-26T23:54:36.000Z
WOW!
Any suggestion?
Graziano.
Cannot order a date in EventTime
- jmichaelson
- Posts: 375
- Joined: Wed Aug 23, 2023 1:02 pm
Re: Cannot order a date in EventTime
Could you provide a little more background here? Are you using NLS 2024R1 or older, or the recently-release NLS 2024R2?
Would you also mind providing the nxlog.conf file from your log source so I can get a feel for what's being done ahead of the entry getting to Log Server?
Would you also mind providing the nxlog.conf file from your log source so I can get a feel for what's being done ahead of the entry getting to Log Server?
Please let us know if you have any other questions or concerns.
-Jason
-Jason
Re: Cannot order a date in EventTime
Thanks for the great sharing! So if I have a case where the data has different time zones (e.g. Among Us Online UTC and local time), how can I ensure that the comparison and sorting by EventTime is always correct without being affected by the time zone difference?
- jmichaelson
- Posts: 375
- Joined: Wed Aug 23, 2023 1:02 pm
Re: Cannot order a date in EventTime
The best way to ensure that is to make sure that all of the log entries going in share the same time zone. You may have to modify the source systems to o the conversion there, or add something into your filter to do it. My suggestion in this case would actually be to migrate to Nagios Log Server 2024R2, which uses a new backend based on OpenSearch (2024R1 and older use Elasticsearch 1.7.6, which is incredibly out of date), where many of the guidelines provided automatically set fields that we are aware of to use UTC for the time zone, so that everything gets correctly ordered going forward. As for the current situation, I'm not sure much can be done short of figuring out the source time zone of the relevant entries in your system and updating the log entries manually.
Please let us know if you have any other questions or concerns.
-Jason
-Jason