Hi Assaf, >From reading the documentation, yes, a satellite setup would probably be best. We had three separate nagios instances not talking to each other (and so would have to login to each one individually to view the dashboard). With Icinga we'd like to get rid of this, and build a single web node (the master) to show the checks from our two satellites, plus the ones defined locally on the master.
I've looked here: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/icinga2-client#icinga2-client-configuration-local and here: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring-high-availability#cluster-scenarios-master-satellite-clients I think we are looking at bottom up configurations, where the satellite has the checks for the remote hosts, where the Icinga2 client is not installed on the remote hosts. What I have done so far is to install the master, and one of the satellites and connect them: icinga2.asrc is Master momgt01.asrc is a satellite On master within repository.d/zones object Zone "momgt01.asrc" { endpoints = [ "momgt01.asrc" ] parent = "master" } On satellite within conf.d/mo/mologin01.conf object Host "mologin01" { import "generic-host" address = "mologin01" vars.group = "mo" } On satellite within conf.d/services.conf apply Service "ssh" { import "generic-service" check_command = "ssh" assign where host.vars.group == "mo" ignore where host.name == "localhost" /* for upgrade safety */ } When I run update-config on the master, the master picks up the fact that there is a host configured on the satellite and adds it to icingaweb2, but doesn't show the SSH check that it should run (on the satellite) but creates the following on the master in repository.d/hosts object Host "mologin01" { import "satellite-host" check_command = "dummy" zone = "momgt01.asrc" } And two services in the mologin01 folder - disk.conf and ping4.conf: object Service "disk" { import "satellite-service" check_command = "dummy" host_name = "mologin01" zone = "momgt01.asrc" } object Service "ping4" { import "satellite-service" check_command = "dummy" host_name = "mologin01" zone = "momgt01.asrc.cfms.org.uk" } Do the remote hosts also have to have the clients installed on them? (I just want an SSH check from the satellite to the remote host) and how do I stop the master from creating and running those checks rather than the satellite using what's been defined locally. Kind Regards, Josh Cullum -- *Josh Cullum* // IT Systems Administrator *e: josh.cul...@cfms.org.uk <josh.cul...@cfms.org.uk>* // *t: *0117 906 1106 // *w: *www.cfms.org.uk <http://www.cfms.org.uk%22/> // [image: Linkedin grey icon scaled] <https://www.linkedin.com/pub/josh-cullum/35/b90/8b9> CFMS Services Ltd // Bristol & Bath Science Park // Dirac Crescent // Emersons Green // Bristol // BS16 7FR On Thu, Aug 20, 2015 at 7:14 AM Assaf Flatto <ici...@flatto.net> wrote: > On 20/08/15 00:23, Josh Cullum wrote: > > Hi All, > > I'm a new user of Icinga2, we are looking to replace our Nagios (outdated) > monitoring with Icinga. > > Currently we have three separate instances of Nagios running monitoring > different areas of our network, and I'm currently trying to build a master, > which has local configuration on it, as well as connecting it to two > 'remote' clients that each manage a HPC Cluster. The master will only see > the results of the checks that are taking place, and show the host groups > that a particular node belongs to, the checks being defined on the remote > client (there are specific checks that we can and cannot run from certain > places within the network). So the setup is a tiered system whereby the > master can talk to anything through it's gateway that is defined in the > local configuration, and the two clients, which are then connected to their > own networks with the remote hosts attached. The master cannot talk to any > of the remote hosts directly. > > I've managed to get the master working with local configurations as well > as two remote clients, and add one node to the remote client, however, when > I run icinga2 node update-config to view the new node on the master, the > master overwrites all the checks defined in the configuration on the remote > client, with it's own ones, which fail because of the network access rules. > (Ping seems to be the default). I've tried getting it to set other checks, > but they just end up with an unhandled (blue) state. > > We're also seeing an issue where if you set the disk to be checked of the > remote machine (not the client) The disk for client is returned in the > result and not the disk for the remote host. > > Does anyone know how I can get the clients to set and run all the checks > for their remote hosts, and report back to the master, without the master > overwriting all the checks (to the default PING check), and the remote > hosts being presented in the correct groups in the master, without having > to alter each individual remote host config file? > > Any help greatly appreciated. > > Kind Regards, > > Josh Cullum > Systems Administrator > CFMS Services Ltd > www.cfms.org.uk > > > _______________________________________________ > icinga-users mailing > listicinga-users@lists.icinga.orghttps://lists.icinga.org/mailman/listinfo/icinga-users > > Hello Josh > > From first read of your email it seems that a satellite setup will be > more suitable to your requirements and not a master/client configuration. > > As far as I understood you had a distributed setup with the old system and > want to replicate this in a similar manner : > https://www.icinga.org/icinga/icinga-2/distributed-monitoring/ > > > http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/icinga2-client#icinga2-client-configuration-local > > Assaf > _______________________________________________ > 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
