Syslog message (EventSource) creation date issue


Recommended Posts

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.

Link to comment
Share on other sites

  • Administrators

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. 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

  • Administrators
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. 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share