I am not near a system right now to confirm but I thought you could make config changes without restarting. If I remember correctly when icinga starts is grabs all the configs and caches them, then reads off of this not the actual config files. I seem to remember in the depths of icinga.cfg you could turn this off and read from the config files in real time, thus enabling you to make changes on the fly.
I also second the idea of picking a single configuration and sticking with it, trying to mix tools can get very ugly. I tend to prefer using the command line and standard unix tools but the learning curve may be too high and not worth it for average users who only make occasional changes. Sent from my iPhone > On Apr 11, 2014, at 6:05 PM, "Carl R. Friend" <crfri...@rcn.com> wrote: > >> On Fri, 11 Apr 2014, chris wrote: >> >> - Is there a tool / plugin in Icinga, to enable user friendly wizard >> to add host / service to monitor > > You might want to take a look at NagiosQL which is a configurator > with a GUI interface. It won't know about the Icinga-specific config > bits, so those'll have to be bodged in by hand -- every time the > thing writes the config files (or gets taught about the Icinga changes). > > Generally speaking, you want to pick either manual or GUI-based > configuration tactics. Working a hybrid approach is *very* tricky. > Been there, done that. > >> - Is there any way that Icinga can read newly added host / service >> to monitor without restart > > Aside from limited operational changes that can be made via the > command file, no. Certainly adding/deleting monitored hosts requires > a restart -- at least in Icinga 1.x. > >> - Is Icinga able to do multi tenance : each user can have their own >> reporting / configuration dashboard? > > Yes, and that's possible by setting a different configuration file > for each instance of Icinga that's running on a host -- and this > includes the CGIs as well. Too, the check-spooling directory needs > to be different for each so the various instances won't step on each > other's plugin returns. The plugin library can be shared, however, > as can the webserver function. > > A more important question to answer, though, is "How will this setup > scale?" I.e. "Can it keep up with the demands that the users will put > on it -- in a sane manner?", "How will one produce aggregate views of > things and produce reports for Management?", "How will the overall > administrator of the environment keep the individual instances looking > vaguely alike (dealing with sysadmins is notoriously like trying to > herd cats)?", as well as a host of other "gotchas". Just because > something *can* be done doesn't mean that it's the *right thing* to > do, and you need to take your own environment and situation into > account. > > +------------------------------------------------+---------------------+ > | Carl Richard Friend (UNIX Sysadmin) | West Boylston | > | Minicomputer Collector / Enthusiast | Massachusetts, USA | > | mailto:crfri...@rcn.com +---------------------+ > | http://users.rcn.com/crfriend/museum | ICBM: 42:22N 71:47W | > +------------------------------------------------+---------------------+ > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users NOTICE: This message, and any attachments, contain(s) information that may be confidential or protected by privilege from disclosure and is intended only for the individual or entity named above. No one else may disclose, copy, distribute or use the contents of this message for any purpose. Its unauthorized use, dissemination or duplication is strictly prohibited and may be unlawful. If you receive this message in error or you otherwise are not an authorized recipient, please immediately delete the message and any attachments and notify the sender. _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
