On Fri, Feb 4, 2011 at 12:03 PM, Hermann Lauer <
hermann.la...@iwr.uni-heidelberg.de> wrote:
> Hello Jean,
>
Hi,
>
> On Fri, Feb 04, 2011 at 10:52:19AM +0100, nap wrote:
> > On Fri, Feb 4, 2011 at 10:38 AM, Venelin Petkov <
> petkov.vene...@gmail.com>wrote:
> > > But just parsing the perfdata isn't good enough? The format is quite
> > standard (http://nagios.sourceforge.net/docs/3_0/perfdata.html).
>
> writing a parser and all the corner cases of a pipe - oh, the module
> was quite simple written yesterday (thanks to the clean interface
> and the new .format method) and that why we like shinken so much :-)
>
Cool :)
> Just putting a cleartext udp packet on the wire and forget about it is
> a way we are using here since years and you will have no
> hassles with filling disks and the like...
>
> If anybody is interested, of course we'll publish it.
>
> > If not, the only thing is to look at how status_dat and LiveStatus module
> > does : they take the initial_*_status_brok and re-generate Hosts/Services
> > objects. You can just take the data you need into this (it's a dict with
> > key/value as property/value in fact).
> >
> > If the scheduler is restart or something like that arrive, new
> > initial_*_status are generated, so you are sure to already have the good
> > value. You can also look at status_*_update broks, if the command change
> > during the run, you will be notified (but it's very rare of course).
>
> We yesterday noticed the broker needs to be
> restarted when a module is added. Is this also nessesary for
> a config change (when used like above) or should arbiter restarting
> enough ?
>
>From now the modules are only taken into account the first time they are
read. I'm planning to add a "hashing" thing so if the module is new or if
the configuration changed it will be restarted. The main thing is the hash
function in fact.
>
> Again, many thanks for shinken and your help,
>
You're welcome :)
Jean
>
> greetings
> Hermann
>
> --
> Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
> Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
> IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
> Email: hermann.la...@iwr.uni-heidelberg.de
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
