Hi Dan, thanks for your remarks. The 3 seconds poll interval shoudn't be a problem, because it polls only the delta. And in oposite to thruk itself, it will only fetch the runtime data, not all attributes (childs, contacts,...) over and over. Shadownaemon then uses a single keepalive connection, so it should reduce load and bandwitdh usage on the remote sites too. The interval could be increased by an option, but i still would like to keep the shadow almost live. Encryption is currently not part of shadownaemon because i didn't want to introduce new dependencies. Normally you would just use SSH to tunnel the livestatus TCP port.
Sven On 3/7/14 4:39, Daniel Wittenberg wrote: > Something else I thought of is how do you encrypt the data channel, it didn’t > look like any built in ssl or anything. > > Dan > > On Mar 6, 2014, at 9:01 PM, Daniel Wittenberg <[email protected]> > wrote: > >> Interesting idea, looks like it’s updating all 200 sites every 3 seconds if >> my quick glance was right? Does it do them in parallel? Serial? >> >> Of course I think any use of /tmp should go :) >> >> Dan >> >> >> On Mar 6, 2014, at 3:03 PM, Sven Nierlein <[email protected]> wrote: >> >>> Hey, >>> >>> I am working with a client which has reached almost 200 cores across the >>> globe >>> and Thruk is starting to become slow when viewing all instances into one >>> combined view. Since all core have livestatus already enabled, i wrote a >>> small >>> program which fetches hosts and services by livestatus, writes out a naemon >>> config and starts and emtpy naemon core which loads the livestatus broker. >>> It then pulls in changed host and service status over livestatus as well as >>> performance >>> counter from livestatus itself. So instead of 200 remote connections, thruk >>> has 200 local unix socket connections and is much faster again. >>> >>> Basically it works like this: >>> %> ./shadownaemon -i remotehost:6557 -o /tmp/cache/inst1 -l >>> .../naemon-livestatus/src/livestatus.o >>> started caching remotehost:6557 to /tmp/cache/inst1/live >>> >>> Besides starting the cache manually, its planed to do that transparently >>> from Thruk. >>> Logs and Commands are excluded from the cache and have to be fetched >>> directly from the the >>> remote instance but in such large setups, Thruk uses a mysql cache anyway. >>> >>> The source is in my branch for now: >>> https://github.com/sni/naemon-core/blob/shadow/naemon/shadownaemon.c >>> >>> So the main question is, do we want to maintain that thing besides naemon >>> and the >>> main repository? I noticed there are some tools already, like ex. >>> oconfsplit. >>> >>> There are still a few things to work out and there are some todos left on >>> top of that >>> file, but i hope you get the idea. >>> >>> Any ideas or remarks on this? >>> >>> Sven >>> -- Sven Nierlein [email protected] ConSol* GmbH http://www.consol.de Franziskanerstrasse 38 Tel.:089/45841-439 81669 Muenchen Fax.:089/45841-111
