Kaseya Community

HOW TO MONITOR FOR EVENT IDS ?????

  • I need a complete stp by step process for monitoring several hosts for a particular Event ID. I can not find for the life of me where to set this up in K2.

     

    Please Help!!!!!!

  • Key trick is probably look under Alerts, rather than Monitor Sets. Then it's pretty easy.

    Set your machine group  / view as required.

    Monitor module -> Agent Monitoring -> Alerts, then in the main panel up the top where it says Select Alert Function, change it to Event Logs, pick the log you want (Application, System, whatever)

    In the block below that, choose what you want to happen.

    Block below that, pick an event set or create a new one - it's really not too hard. Don't forget to tick what type of message you're looking for, be it Error, Warning, etc.

    Select the machines you want to apply it to, then click the Apply button way back up by the first block of ticky things.

    See if that gets you far enough... (There are a couple of extra twiddles but nothing that's not in the help.)

  • thanks for your help.

    say i have a re-occuring error that is happening every minute. i only want it to alert (send me an email) once per day. or once every 4 hours. what setting wold this be? and what would be the correct value.

  • Second block of ticky boxes down, just to the right of where you pick which events to monitor, you'd select "Alert when this event occurs once" (which is the default anyway) and then just below that, set "Ignore additional alarms for" to whatever you want. Correct is up to you depending on what you're monitoring for.

  • It would be better to re-arm the alert after 4 hours instead of ignoring them.

  • I created a new event set to ignore certain events, now I get 0 alerts from the host, the only items in the list are all set to ignore, I did this thinking that by selecting the ones to ignore all other alerts would come through, however I get none.  Do I need to apply 2 sets for each log type I want to monitor, like the <All Events> and my ignore list or should it work with just my list??

  • You need two lists. If an event matches ANY ignore filter applied to that machine, it will be dropped. But you also need a filter to tell it which events to alert on. If your goal is to have all events alerted on except for those events in your ignore list, then you need to apply the <All Events> event set, plus your events to ignore event set for each log type (ie. Application, System, Security).

  • Hey Alex

    I thought that was the case, however I have the <All Events> set and a custom one I created to ignore certain warnings etc. I still get all the alerts I told it to ignore, an example would be Warning Event 8, this is a warning telling you that a specific printer in session 3 was purged, I have decided that this alert would be added to the ignore list, but I still get it and it is filling my inbox like crazy as it is coming from several servers and they all have both event sets selected.

  • OK, gotta say that Labtech has got this beat - I did a demo of it last month, and while I don't think we're going to switch there's some extremely cool things they do.  Have an event you need to monitor for?  Right-click, say "monitor for this event", and set your alert info/options.  Want to apply it too agroup of machines?  Simply add it to the policy for that group.  

    Seeing that option alone I was ready to put up with the pain of a switch.

  • @RJ goodluck with the move then Smile from my research Kaseya has more functionality out of the box then most MSP products but if Labtech works for you and your customers I say go for it.

     

    @dirkdigs as you are just starting out with this, here are a few tips that I'll share and that I would have appreciated when I first started using Eventlog monitoring.

    I will briefly explain how this works, create error/warning specific eventlog monitoring sets that trigger agent procedures instead of alerts or emails. These eventlog triggered procedures can then in turn be used to check for certain conditions and execute a dummy executable file which does nothing other then run for 30-60 seconds and stops. This dummy executable file can then be monitored for by a process monitor set that triggers an alert.

    Why might you say would you do this? Well mainly because Eventlog alerts can not be sorted into individual categories in the Alarm Monitoring Grid (aka Group Alarm Status) Dashboard so they only show up under Events category. When the event is triggered you don't get a lot information specifically what monitor set triggered it in the first place.

    Things to do;

    • Make yourself a spreadsheet with Event ID's and document them as you find them, I would start with the ones that already exist in Kaseya.
    • Split up your event monitoring sets and create separate event sets.
    • Create your self a naming convention for your eventlog sets and make sure to include an identifier that tells event types (e.g.: Information,Warning,Error etc...) and Log types (e.g.: Application, Security, System etc...)
    • Create your self a dummy executable that you can monitor for with a process monitor.
    • Create matching Event monitor set named Agent Procedures/scripts to execute the dummy executable when triggered by the eventlog monitoring set
    • Create matching Event monitor set named Process monitor sets that monitor for the dummy executables and allocate them to appropriate alert categories.
    • Create Agent templates for monitoring different applications and OS type events and apply the Eventlog and Process monitoring sets to make deployment easier for the future.  

    For the dummy executable I use an AutoIT script that I compile into an executable here is a sample of what I use;

    Opt("TrayIconHide", 1)    ; Hides AutoIt Tray icon
    Sleep (30000)            ; = 30 seconds

    The dummy executable should have a unique name when executed on the computer but you can use a generic one stored on your Kserver that gets renames when it uploads to the target machine.

     

    I realize that this is a lot of work and not something that you would expect to have to do for an "out of the box system" however long term all the work will pay off. Its a pity that Kaseya has had the same eventlog monitoring interface for so long without improving it to make it easier for us.



    [edited by: HardKnoX at 5:22 PM (GMT -8) on 1-18-2011] typo
  • that does sound like a lot of work, but if it works I guess we have to suffer through it.  It would be nice if Kaseya would do that for us, doesn't make sense to be able to create a group of alerts to ignore and the alerting system ignores the list and sends them through anyway creating a headache for me, 300 emails overnight is kind of a pain and if you own a blackberry your listening or felling the stupid vibration for each and every one.

    Gary

  • HI Gary,

    We are doing what you are looking to do with out problems.

    What I would suggest is to try this

    Remove all Event sets from the machine then apply the ignore event set and then apply the All Events one.

    We have a large block list event set that blocks unwanted and it is working fine and then we have other multiple categories below that.

    I think HardKnoX's solution is not a direct solution for your problem but rather a solution for the fact that you cannot group event alerts like you can monitor sets and in that case it is good solution.

    But the basic functionality you are trying to do does work - if you cannot get it working I would open a support ticket.

    Michael

  • Thanks Michael I will try that and let you know if it works, last night I got over 300 emails about events, it will be really nice if this works..lol.

    Gary

  • It seems to be working, I guess it is all about the order.  Thanks!

    Gary

  • (Sorry for the long winded response)

    The method I mentioned above is not my idea, I did think of and use some parts before I learned the whole method (aka reinventing the wheel) from some Kaseya workshops so I won't take credit for it. Personally I think it could be done a whole lot better but that's a story for another day.

    Using the "catch all" monitor sets method (aka the lazy method) forces you to rely more on Event exclusions sets, so far I know an exclusion in one Event Monitoring set affects all the other Event Monitoring sets applied to that agent which is why they provide a single exclusion Event Monitoring set in the Samples so that they are easy to find. This can cause problems if you don't add enough detail to the events that you want to exclude resulting in similar critical events occurring that your catch-all monitor set would have picked up but it got excluded due to you exclusion list.

    Something I left out in my previous post regarding the the method I learned from the Kaseya work shops is that this method is not really suppose to be used with "catch all" monitor set/s (aka the lazy method) that so many Kaseya Admins like to use, you instead monitor for specific Events and Event types (Information, Warning Error, etc...) which means you won't get so many false alerts in the first place. By breaking up your event sets by Event ID's, Event types (Information, Warning Error, etc...) and specifying partial descriptions It allows you to select which ones are worthy of critical email notifications or just an Alert to look at later when you get to the office.

    The down side is that you need to know what to monitor for, hence the "Make yourself a spreadsheet with Event ID's and document them as you find them" or else you run the risk of critical events falling through the cracks. Personally I do still use "catch all" monitor sets but I only make them Alert (not Email or run scripts) so that I can build my spreadsheet with Event ID's up as so may are still Event ID's undocumented. Once I'm happy that I have a good coverage of the individual Event monitoring sets I plan to disable the catch-all event sets and schedule an audit every now and then to make sure I didn't leave anything out.

    Another reason why this method I mentioned above is great is it allows you to record events that does not require alerting, email notification or remedial work. A good example would be Successful backup events (not Kaseya BUDR), we don't need an alert for this because nothing has gone wrong but I would still like to report on it so I can show my customers both failed and successful events so that they don't just see reporting on bad events but on good events too making you reports neutral rather list of bad/failed events.

    @mmartin So yes if you follow this method with some logic and common sense you should see a lot less false alerts and eventually none if you remember to schedule suspending monitoring during planned outages and updates.



    [edited by: HardKnoX at 9:58 PM (GMT -8) on 1-22-2011] typo