Kaseya Community

Deciphering Event Log Alerts in Service Desk tickets for routing and remediation

  • I'd like to capture some of the details from Event Log alerts, such as EventID, Log File, Source, etc. I've created custom fields to hold this information if only I could easily get to it. The alert includes all this data but it's all dumped into a single field (ie: details or description). I assume this information is available already parsed and then concatenated together for the ticket body details. Is there any way to access the Event Log data field directly? I really don't want to try to parse the Event Log data for each ticket. But if I DO have to parse the body, does anyone know a good way to do this? I don't want to confuse Warning Event 51 with Warning Event 5110, so it will be important to have a reliable way to parse this info.




  • In case anyone tries to do this, I thought I'd give an update here for posterity. Below is the body of a ticket created from an event log alert, which is fine for human processing. I'm using ServiceDesk and I want to be able to "automate" certain types of common events. But Before I can do that, I need to accurately know the EventID, the Log that generated the event, the type, etc. So I've created several custom fields, SourceType, EventLog, EventLogSource, EventID, EventLogType, and EventLogCategory.


    Summary: [some-srv.some.place] System log generated Warning Event 2094

    Description: System log generated Warning Event 2094 on some-srv.some.place

    For more information see www.eventid.net/display.asp Administrator

    Log: System

    Type: Warning

    Event: 2094

    Agent Time: 2011-11-27 23:54:03Z

    Event Time: 04:51:22 AM 28-Nov-2011 UTC

    Source: Server Administrator

    Category: Storage Service

    Username: N/A

    Computer: SOME-SRV

    Description: Predictive Failure reported: Physical Disk 0:4 Controller 0, Connector 0


    Using the example, I'd like to populate my custom fields as follows:

    SourceType: Event Log

    EventLog: System

    EventLogSource: Server Administrator

    EventID: 2094

    EventLogType: Warning

    EventLogCategory: Storage Service

    First, it's important to understand that some of the information you need is only available in the Ticket Mapper procedure. This is a "pre-precessing" procedure that helps to direct which service desk to send the ticket. So, if you had a different service desk for Event Log alerts vs Agent Off Line alerts, this is where you could make that determination. It's also the only place that you can access the original SourceType (not my Custom Field) as well as 3 variable/value pairs called SourceType1,2&3 and their corresponding SourceValue1,2,&3. These change with each type of ticket. For instance, SourceType3/SourceValue3 is blank/empty for Agent Off Line alert (probably others too).

    SourceType is equal to whatever "caused" the ticket to be created - ie: Event Log, Log Parser Monitor, Counter, etc. So that seems to be an easy value to populate. The rest get tougher. But those variables can help a little.

    Here is an example of these variables when an Event Log ticket is created and where you can find more info about the values.

    SourceType is Event Log

    SourceTag1: AgentGuid

    SourceTag2: AlertRegistrationId

    SourceTag3: LogType

    SourceValue1: xxxxxxxxxxxx (actual GUID removed)

    SourceValue2: 104 ---> to get real name checkout the dbo.alertRegistration table

    SourceValue3: 1380569194 --> to find out which Log this is checkout dbo.eventLogType table

    So SourceValue3 maps to the name of the Event Log. So I call a SQL from my mapper procedure like this: select displayName from eventLogType where EventLogTypeId=[$SourceValue3$] and set it to a variable and then set that variable to my custom Field "EventLog."

    SourceValue2 seems to be a repeat of the SourceType. However, when I look through the dbo.alertRegistration table it seems there are a lot of possible values and SourceType might just be a "dumbed down" version. So, if SourceTag2 = "AlertRegistrionId" I go ahead and get the real name from dbo.alertRegistration table for the SourceValue2 (ie: 104) and take that over SourceType because it more be a more detailed Event Log name.

    Next, I have a very simple set of If/Else-If type logic to look for the EventLogType. There are only a handful of them (Information, Warning, Error, Success Audit, Failure Audit, Critical, Verbose), so I can safely look for each by checking the body for the existence of each (if exists - Log: Information, Log: Warning, etc). I can then set the value of EventLogType based on which one matches.

    So at this point, I've got this much of my data filled in:

    SourceType: Event Log

    EventLog: System

    EventLogType: Warning

    Now I really want the EventID because without it, I can't really do much else. Luckily, the Summary of the ticket contains the Event ID in a consistent format. It's always the last thing in the summary. So, after a bit of googling, I came up with a very simple VBScript to parse the Summary and return the last element - which is the EventID.

    outputArray  = split(wscript.Arguments(0))

    wscript.echo outputArray(uBound(outputArray))

    I saved this as VBParseTicketSummary.vbs and uploaded to my K server SharedFiles location.

    Now at this point, I can't do what I want from inside the Ticket Mapper procedure. So I move onto the New Ticket Created procedure, which is the next thing that is called in the chain (once the mapper maps it to the Service Desk that I am using). But I really don't want to do any heavy lifting in here. So I make a sub-procedure for handling Event Logs. From the New Ticket Created proc I check if SourceType = "Event Log" and call the sub-procedure for Event Logs. This format will work nicely because as I expand into other monitors I can create a seperate handler for each in the sub-procs.

    So in this proc I execute a command shell like this: cscript /nologo D:\Kaseya\WebPages\ManagedFiles\VSASharedFiles\VBParseTicketSummary.vbs "[$Summary$]" and save to a variable. Then I save that variable to my customField "EventID" and I've got pretty much everything I need to identify the ticket for automated processing.

    I'd still really like to get the Source. I don't think the Category will be all that important for figuring out how to automatically handle these but it would be nice for reporting purposes maybe. I will likely try to get these last 2 variables through a combination of brute force logic and vbscripting. If I figure out how to do it, I'll be sure to post it here.  

  • Thanks for updating this ticket with your progress!

  • If you are still using KSD I would be interested to hear how you are currently using the ticket mapping procedure and output variables created by ExecuteSqlQuery.