Kaseya Community

If I tell Kaseya to reboot a system, Surely it should ignore system down alarms on this machine because I've actioned it?

This question has suggested answer(s)

When I tell Kaseya to reboot a device, Wouldn't common sense dictate that it should ignore system down alarms because it's physically been told by Kaseya to reboot? Or is the only way to achieve this is to put it into "Suspend Alarm" or "Maintanence" mode first? Is there perhaps an option I'm missing in the Monitor Sets I've got applied to the devices that says to not generate alarms if told by Kaseya to reboot?

All Replies
  • The script you use to reboot the system is independent of monitoring.  Therefore, the monitoring system does not know that you ran a script specifically to reboot and it alarms for the offline status.  You can change how you monitor the agent offline status to give it a little more time before it alarms.  But, the safest bet is to just suspend alarms momentarily.

  • I put in a feature request a couple years ago for a "Suspend Alarm" script step for this very reason. I would encourage you all to do the same and perhaps Kaseya will make it happen.



    [edited by: SMason at 3:43 PM (GMT -7) on 11-2-2011] Clarification
  • SMason

    I put in a feature request a couple years ago for a "Suspend Alarm" script step for this very reason. I would encourage you all to do the same and perhaps Kaseya will make it happen.

    Snap.

  • If the act of you rebooting a system generates a system down alert, then I'd venture to say that your alerting needs to be tuned to a more appropriate time frame.

    We alert if a critical agent hasn't checked in for X minutes, where X is large enough to allow for reboots.  We do this so that we don't get a thousand alarms on Sundays when patches go out and servers reboot when they are patched.

    It would be nice to have a suspend alarm script step, but you'd also need an "Unsuspend alarms" script step which would be called after a script delay, or you'd have to remember to manually unsuspend the alarms for that agent.

    The solution as it stands now is to tune your agent alerts so that they will alarm when the agent is offline, but also allow time for a normal reboot and/or patches to be installed.

    Of course, all this assumes you are talking about getting alerts from the "Monitoring -> Alerts -> Agent Status" type alerting.

    EDIT: A hint:  If you're running in a virtual environment, you can set the alert time on the host server different than the alert time on each guest server.  This way you'll be able to tell by the order of alerts you receive if the guest server(s) are really down, or if it's an internet outage at the location :)

  • I don't think that's necessarily true Dan. I have over 300 servers we're monitoring, and frankly I don't have the time to put a stop watch to each one and see how long they take to reboot. We have a mix of physical and virtual, along with a lot of SBS servers thrown in, which means we have servers that reboot in anywhere from 2 minutes to 20 minutes. With most of our monitoring we've tried to set it up in a way that we can keep a single global setting for all agents, it's just easier to manage that way. Once Kaseya works most of the bugs out of the Policy Management module, I might start changing my tune on that and going for more customized settings.

    We determined as a company that we wanted alerts if a server was down for more than 7 minutes. This does cause us to get some false alerts now and then, but on the flip side we're able to jump on actual server down situations faster, so it's worth it. We do our server patching late Saturday / early Sunday morning, and then schedule all the reboots between 3am and 5:30am on Sunday. It was definitely annoying to get slammed with hundreds of alerts as you mentioned, so we just setup a recurring alarm suspension for servers during that time window. We'll still get alerted to anything critical once the alarm suspension expires, and it cuts out the rest of the noise caused by rebooting that many servers.

    Also if they were to add an alarm suspension option in the scripting, you wouldn't have to remember to unsuspend it, as long as they put a Minutes box in the step, so you could just schedule the reboot, suspend alarms for 15-20 minutes, and be done. My biggest complaint with Kaseya's scripting engine is that it doesn't allow you to do anything you can do manually in the VSA, like suspend alarms, schedule patching options, apply monitor sets, etc... If they really want to push the automation thing, I think they need to add this ability.

    I don't really think there's a one size fits all solution to this issue, we all have different needs and client expectations, so everyone just needs to look at the options available and set it up the way it works best for them.

  • I agree with kcears a suspend for duration is required, I logged another ticket for it as the previous one was on the old system I think, they have responded already....

    "Ticket Update: CS078749 - FEATURE REQUEST: Suspend Alarms step for Procedures \ Script.

    Update: Hello,

    We will process this feature request on your behalf.

    Regards,

    Joseph

    Kaseya Support"

    If that means it is a yes they will do it or a yes they will pass the request on I am not sure. I will update you if I hear anymore.