Re: [Shinken-devel] Opening of the wiki for Shinken, and need help for the RoadMap

[nap <nap...@gm...>]

Yes, a livestatus us a 'must have'. But I think it's place is not on
the scehduler, but on the broker. Now, the broker get status, then
manage them all before get new ones. I'll post a new way of doing this
: it put them in a queue and to specific queues for external modules
(I'll post a diagrams to show this), then return to the main loop.
While the queue is not empty, it manage it with standard modules
(service-perfdata, ndo/mysql, etc) and every 1s, it get new, put in
queue etc. While the main broker is running, external modules gets
status from their own queues and manage them directly (they can just
put data in memory so get all data that schedulers got) and answer to
soket for live status or create every 30s a unique status.dat for all
schedulers.

I'll post in the morning the diag.


Jean

On Mon, Jan 11, 2010 at 11:08 PM, Sven Nierlein <sv...@ni...> wrote:
> On 1/11/10 22:52, Christoph Maser wrote:
>> Am Montag, den 11.01.2010, 22:46 +0100 schrieb Spike Spiegel:
>>> much better approach is to have something like that so that it's easy
>>> to write an API around it to expose the data.
>>
>> Yes but i would prefer a direct api to the core (like MKlivestatus does
>> for nagios) instead of duplicating the data to a RDMS which brings along
>> a whole set of new problems. (update-rate, latency, etc)
>
> Thats what i would prefer too. A livestatus compatible API would be nice, then i could
> use my nagios cgi replacement Thruk.
>
> Regards,
>  Sven
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Shinken-devel mailing list
> Shi...@li...
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>