On 03.05.2013 20:13, Ricardo Nunez wrote: > > Hi, > > I’m not an Icinga user, at least for the moment. In general what’s > shown of Icinga distributed architecture looks very interesting for me. >
When you do, make sure to join http://www.icinga.org/users/ :) > > So I have a basic question: May we have more than one web interface > (central monitoring server) in a distributed monitoring? > > In the URL http://docs.icinga.org/latest/en/distributed.html is clear > that there could be multiple “Distributed monitoring servers”, but > it’s not clear that, for example, we could a web server (“Central > monitoring server”) in a company headquarters, and another web server > (“Central monitoring server”) in a important branch “in the other side > of the world”, which cannot depend in the headquarters for everything. > It’s clear that the “Distributed monitoring servers” will need to be > capable of sending their information to more than one “Central > monitoring server” in order to be able to do what I’m asking for. > Not sure if I may answer that how you expect it. When it comes to the classic method of distributed setups, you'll put up a passive master (not doing any checks, or just a few monitoring the slaves) receiving all the checkresults from the slave nodes. The slaves themselves act as Icinga Core nodes processing their parts of the configuration and checking the hosts/services provided by those. The checkresults are then sent back to the master node. While the Icinga documentation points you to use o{h,s]cp commands and nsca, you may also have a look at LConf{Export,SlaveExport,SlaveSync} for that manner. Regarding the webinterface - you may put your master with either Classic UI or Icinga Web, and have the combined view all-in-all. But in various setups I've seen and built, it was also reasonable to put the Classic UI as local interface on those slave nodes as well. This may answer your question, but not sure about it. If you want to have different web interfaces with the same data backend, you may build yet another setup - let the central master write to the IDOUtils database, and let all Icinga Web installations access those. In regards of sending commands, you will need ssh (tunnels) anyways. The even more de-centralized method would be having a multi-master setup writing to a central IDOUtils database, where each master acts as a standalone node, but the UIs access it all. The last one described is more of a distributed view rather than actually distributing the checks among nodes like one expects from active-passive or active-active setups. While the method achieving this is now a bit complicated with Icinga 1.x, the in-development version of Icinga 2 will have replication and check distribution builtin, meaning to say that all nodes may just sync the data and provide a data api for UIs then. But that's too soon right now to promote for prod systems. kind regards, Michael -- DI (FH) Michael Friedrich mail: michael.friedr...@gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmi...@jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
