> On 02 Feb 2016, at 14:25, René Koch <rk...@rk-it.at> wrote: > > Hi list, > > I'm testing Icinga 2 and want to achive the following setup: > 2x Icinga master (notifications, ido db and nsca server) > 1x Icinga tools server (Icinga web 2 and pnp) > 3x Icinga worker (active checks) > > My 2 master servers are responsible for sending out notifications and writing > data into IDO database. These 2 nodes also host a pacemaker cluster for high > availability of PostgreSQL database, nsca server and provides a cluster ip > address. > > Both nodes do have the following features enabled (checker is only enabled to > do the health check): > [root@icinga-master01 ~]# icinga2 feature list > Disabled features: compatlog debuglog gelf graphite icingastatus livestatus > opentsdb perfdata statusdata syslog > Enabled features: api checker command ido-pgsql mainlog notification > > The tools server hosting Icinga web 2 and pnp has perfdata for writing the > pnp data. > [root@icinga-tools01 ~]# icinga2 feature list > Disabled features: checker compatlog debuglog gelf graphite icingastatus > livestatus notification opentsdb statusdata syslog > Enabled features: api command mainlog perfdata
Reading below that both, the masters and the tool server, belong to one zone, you cannot disable certain HA-aware features inside the same zone. http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring-high-availability#high-availability-features “All nodes in the same zone require the same features enabled for High Availability (HA) amongst them.” Probably that’s a general source for errors and should be taken into account beforehand when (re)designing your cluster. > > Nearly everything works fine, except the fact that I'm not able to use any > commands (e.g. disabling notifications) in Icinga web 2. > > All my systems have accept_commands the Icinga 2’s part of “accept_commands” merely targets commands executed by Icinga 2 through its cluster protocol, but not external commands such as Icinga Web 2 and other applications are sending though the command pipe. Commands coming from external interfaces are transported top-down in regard of the parent-child relationship between zones and their endpoint members. > set to true and have valid certificates (I used the fqdn of each system for > common name so it will match NodeName): > [root@icinga-tools01 ~]# cat /etc/icinga2/features-enabled/api.conf > object ApiListener "api" { > cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt" > key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key" > ca_path = SysconfDir + "/icinga2/pki/ca.crt" > accept_config = true > accept_commands = true > ticket_salt = TicketSalt > } > > My question is now how can I configure command transports for Icinga web 2? > > I tried the following: > > - Local command file: this will disable notification on tools server, but the > command want be sent to the 2 master servers, so notifications will still be > sent out > > - Remote transport: if I specify 2 remote transports (and no local command > file), the disable notifications command will be sent to the first transport > if it is reachable. But it also want disable notifications on 2nd node - so > if my first remote transport isn't the active Icinga master, notifications > are still sent out. Also if this node goes down and 2nd node will take ower, > notifications are still sent out, as I would have to disable them again in > Icinga web 2. > > So my question is now, if it should be possible that my 3 nodes in master > zone should share commands (as they do with perfdata and check results > already) Your current setup only executes 2/3 of the checks shared inside that zone, if any. > and this is a bug, or how I can configure command transports in Icinga web 2 > for a ha zone. > Thanks! I’d guess your cluster inside the master zone is not working correctly, as explained above. Kind regards, Michael > > Btw, here's my zone config in case it's needed: Config and versions are the most important part when asking questions :) > > [root@icinga-master01 icinga2]# cat zones.conf > object Endpoint "icinga-master01.rk-it.at" { > host = "icinga-master01.rk-it.at" > } > > object Endpoint "icinga-master02.rk-it.at" { > host = "icinga-master02.rk-it.at" > } > > object Endpoint "icinga-tools01.rk-it.at" { > host = "icinga-tools01.rk-it.at" > } > > object Endpoint "icinga-worker01.rk-it.at" { > host = "icinga-worker01.rk-it.at" > } > > object Endpoint "icinga-worker02.rk-it.at" { > host = "icinga-worker02.rk-it.at" > } > > object Endpoint "icinga-worker03.rk-it.at" { > host = "icinga-worker03.rk-it.at" > } > > object Zone "master" { > endpoints = [ "icinga-master01.rk-it.at", "icinga-master02.rk-it.at", > "icinga-tools01.rk-it.at" ] > } > > object Zone "worker" { > endpoints = [ "icinga-worker01.rk-it.at", "icinga-worker02.rk-it.at", > "icinga-worker03.rk-it.at" ] > parent = "master" > } > > object Zone "global" { > global = true > } > > > Here are some information about my Icinga versions: > icinga2-2.4.1-1.el7.centos.x86_64 > icingaweb2-2.1.2-1.el7.centos.noarch > > > Thanks a lot, > René > > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users -- Michael Friedrich, DI (FH) 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 | michael.friedr...@netways.de ** OSDC 2016 - April - netways.de/osdc ** ** OSBConf 2016 - September - osbconf.org ** _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
