Am I the only one frustrated with event log monitoring? We are new to Kaseya, so we just started on K2 and the event log monitoring feels like a holdover of some older archaic system.
Specifically, I'm having a hard time managing all my event log monitoring sets. I modeled my templates after the ones provided by Kaseya, so they are organized into server roles, applications, etc. I think the most frustrating part is trying to remember which event log each template needs to be applied to (e.g. Do those events show up in Application, System, or some other log?). I now have a large collection of event log sets and typically apply 10-15 event sets to a machine, which gets very cumbersome very quickly.
Am I missing some veteran secret to keeping the event sets under control? Should I create seperate event sets for each log (e.g. instead of a "Domain Controller" event set that gets applied 3-4 times per machine, have a "DNS-Domain Controller", "File Replication-Domain Controller", etc.)
I also have a second question: How do you handle your rearms? If an alarm is triggered, I assume it will wait for the rearm period before triggering a second time (assuming the condition still exists). However, what happens when I delete an alarm? What happens when I close one? Does that "reset" the timer, or is it just checking to see if an alarm already exists?
Thanks for the help
Welcome to Kaseya. As you have seen it is a nice product but can quickly be frustrating in some areas.
I have spent a lot of time on our event monitoring, and after talking with a bunch of people and trying different options I feel that the best method is to monitor for all events, and then build up an ignore list.
What we do, is (for servers only) assign Application, Directory Service, DNS, File Replication, and System event set of All Events, and a rearm time of 1 day. Then, we created an ignore list and applied to Application and System with a rearm time of 0 which means it continually runs.
This will cause a bunch of tickets, so if you go this approach take it in steps. We have created an ignore list for events we know are safely ignored or unfixable, and except for a few that still slip by we only get events we want/need to be alerted on. This allow prevents us from missing critical events (week I started setting this up we had two RAID arrays fall out because they were not on the list of things we did want to be alerted on). As we get these events (averaging maybe 200 a day now, was a lot more) we spend the time and resolve the root cause to prevent the error from repeating.
Another option, is to build up just a list of what you want to ignore. Both methods are time consuming.
Again on the rearms, we rearm every 1 day, and the ignore list is set to 0. We use ConnectWise, and when I close a ticket for an event out, it is a day later before I will see the event alert again (assuming the event repeats within that day). Hope some of this helps you out
Ahh, that's a fantastic idea Jon, thanks for the input. I can see Kaseya is in a transition period, hopefully the "enhanced monitoring" that we see the 2010-2011 roadmap will become a reality.
It is definately a reality. I went to the Connect Conference in Atlanta last week, and the information presented was astounding. All of these new features that my company has desired for months will be released publicly October 1, 2010. The enhanced monitoring looks great, unfortunately I have the feeling it is more along the lines of hardware and performance than event logs, but will have to wait and see.