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.
----EXAMPLE TICKET SUMMARY AND DESCRIPTION-----
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
Agent Time: 2011-11-27 23:54:03Z
Event Time: 04:51:22 AM 28-Nov-2011 UTC
Source: Server Administrator
Category: Storage Service
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
EventLogSource: Server Administrator
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
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:
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))
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!
shankwc 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.