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 >
