Hi I don't disagree with that. I am not our monitoring engineer I am with Ops. So a technical solution I can't provide. Process wise it makes no sense to power off machines especially if they require monitoring. How would you automate the handling of a random power off event with unknown time interval, or distinguish it from a genuine unhandled event that requires an action?
We use Icinga 1.09. When we have a host down I see only a host down alert - the services are not in unhandled. Sans an automated solution they can simply take downtime themselves or advise Ops to do so. If you have a secondary way of confirming its a planned host down then by acknowledging with no expiration, when it comes back up the acknowledgement will clear when it's property changes (Ok, warning, critical, unknown). In the end, you don't know why it's down, you must investigate either by sneaker net if it's a physical or other means if it's a virtual. Imagine the scenario dev *intentionally does not* power down when usually they do. Again, how do you distinguish? Bottom line standard practices must be implemented. You are chasing a red herring. Sent from my iPhone > On Jun 16, 2016, at 7:13 AM, Matt Shields <m...@shields.tv> wrote: > > Just because Dev/QA has the ability to power their virtual machines on and > off, does not mean they (or Ops) does not need to know when a disk might be > getting full. > >> On Wed, Jun 15, 2016 at 7:11 PM, Felix Cruz <felix1...@gmail.com> wrote: >> No expert here, but if they can power off at anytime, then how would Icinga >> distinguish a power off from a host down? You'd have to be able to monitor >> for power status directly at the power socket. Even then, how would you >> know if the power off status was intentional or not? >> >> Tel them if they want monitoring it stays on, or as the previous person >> said, why bother monitoring? >> >> Sent from my iPhone >> >>> On Jun 15, 2016, at 7:34 AM, Pascal Larivee <plari...@internap.com> wrote: >>> >>> My question would be then, why monitor them at all? Or you could set then >>> in a "qa" group that sends no alert at all, only viewable on the web >>> interface >>> -- >>> Pascal Larivée >>> Senior IT Architecture & Cloud Ops Engineer >>> Internap >>> Unfortunately interval time may not be the best method since dev/qa people >>> can power their servers on and off when they want. So they could power >>> them on for the weekend if they're working, or they may power them off >>> during a workday if they have the day off. >>> >>>> On Wed, Jun 15, 2016 at 7:21 AM, Gunnar Beutner >>>> <gunnar.beut...@netways.de> wrote: >>>> Hello, >>>> >>>> There are two things you could do about that: >>>> >>>> 1. Set the check_period attribute for those Host and Service objects – >>>> this way Icinga will only run checks during whatever interval you specify >>>> in that TimePeriod object. >>>> 2. Set the period attribute for whatever Notification objects you have for >>>> those hosts and services – that way Icinga will still check those hosts >>>> and services, however it will only send notifications according to the >>>> intervals in the TimePeriod object. >>>> >>>> Kind regards, >>>> Gunnar >>>> >>>> On 15/06/16 13:16, "icinga-users on behalf of Matt Shields" >>>> <icinga-users-boun...@lists.icinga.org on behalf of m...@shields.tv> wrote: >>>> >>>> I have Icinga setup to monitor our production instances in AWS, but we >>>> also have dev/qa resources that get shut off every night. I haven't been >>>> monitoring them because as soon as they power off I get flooded with >>>> alerts. >>>> >>>> >>>> Is there a way to monitor servers only when they are powered on? >>>> >>>> >>>> Thanks >>>> Matt >>>> >>>> >>>> >>>> >>>> -- >>>> Gunnar Beutner >>>> Senior Developer >>>> >>>> NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg >>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77 >>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 >>>> http://www.netways.de | gunnar.beut...@netways.de >>>> >>>> ** OSBConf 2016 - September - osbconf.org ** >>>> ** OSMC 2016 - November - netways.de/osmc ** >>>> _______________________________________________ >>>> icinga-users mailing list >>>> icinga-users@lists.icinga.org >>>> https://lists.icinga.org/mailman/listinfo/icinga-users >>> >>> _______________________________________________ >>> icinga-users mailing list >>> icinga-users@lists.icinga.org >>> https://lists.icinga.org/mailman/listinfo/icinga-users >> >> _______________________________________________ >> icinga-users mailing list >> icinga-users@lists.icinga.org >> https://lists.icinga.org/mailman/listinfo/icinga-users > > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users
_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
