Syslog message (EventSource) creation date issue

Not that i know of.

Just now, Stuart Weenig said:

Not that i know of.

This is really an handicap to us. The device in question is a Cisco FMC, which doesn't pass the time zone attribute in the syslog timestamp format. Since it's located in a different time zone, we get alarms in a 'future' date once they hit LM. This is causing the syslog suppression not to work properly unfortunately.

Once you have a global infrastructure, honestly, all systems should be using UTC to store time. This removes all issues of time zone and DST. If you want to display something in a different time, use a tool's TZ/DST offset feature to display it in your local time. 

12 minutes ago, Stuart Weenig said:

Once you have a global infrastructure, honestly, all systems should be using UTC to store time. This removes all issues of time zone and DST. If you want to display something in a different time, use a tool's TZ/DST offset feature to display it in your local time. 

We're talking about client infra which we don't manage. Regardless of what's the optimal procedure, we should be able to control that on the tool end. Doesn't make sense to have an alert start date other than the time it actually hit the tool.

6 hours ago, Vitor Santos said:

Doesn't make sense to have an alert start date other than the time it actually hit the tool.

This actually happens a lot, enabled by asynchronous data transfer. Particularly in our case, it needs to happen because there could be delays between when the event happens and when the data is received by the LM platform. 

14 hours ago, Stuart Weenig said:

This actually happens a lot, enabled by asynchronous data transfer. Particularly in our case, it needs to happen because there could be delays between when the event happens and when the data is received by the LM platform. 

There should be a field for the syslog time then, or include it in the message itself. But the actual alert date should be the time it hit LM (because that's the actual time where we received the notification - not 4/5 hours ahead of the REAL time in the portal).

My two cents -- I gave up on using syslog and most other eventsources a long time ago due to lack of basic correlation features. At the time, Cisco logs weren't even parsed correctly in our client environments and it took forever to get that dealt with.  We now use SumoLogic for log processing since then since we can run queries on the data over time and get meaningful results (and if needed, tie to LM via the SumoLogic API).  LM also realized the existing stuff was a bit limited so bought a company and added LMLogs as a premium addon.  That is fine, but adding some basic ability to correlate "regular" events (even just counts over time based on custom cross-event ID extraction) should be included in the base license.  We still use it for Windows event logs to have the extra info visible, but we always have to warn folks not to bother ACK'ing any that generate email since that does nothing meaningful.  I have asked that the ACK functionality be removed for eventsources as well (SDT still is helpful).

1 minute ago, mnagel said:

adding some basic ability to correlate "regular" events (even just counts over time based on custom cross-event ID extraction)

Stay tuned.