On Thu, Jan 6, 2011 at 10:58 AM, Laurent Guyon <laurent.gu...@adelux.fr>wrote:
>
>
> > * The scheduler and broker queues are only stored in memory,
> > so if the
> > scheduler or the broker stops or crashes, will all the pending
> > broks be
> > lost ? (more problematic)
> > Yes. There too much data to store them in database in fact. When the
> > scheduler came back, the broker ask him a full state so it goes fresh
> > states. The scheduler got the retention for not starting from a
> > PENDING environment.
>
> So the broker gets all actual states when scheduler restarts, but does
> it see and store the status changes messages that could have been missed
> (which are critical for availability reports generation) ?
>
>
> > * Will the Shinken Livestatus module will be periodically
> > upgraded to
> > follow the original Livestatus progression (new features...) ?
> > Yes, we try to keep it at the same level. We are not at 100%, we are
> > missing some feature like WAIT for example, but we are reducing the
> > gap. We ask the Livestatus author if there were automated tests so we
> > are sure to be clean, but there are not, so it will me more
> > difficult :)
> >
> > This module is the more important "presentation" module for us. So you
> > can be sure it will be our main focus :)
>
> Good to hear ;)
>
>
> > * What about using Livestatus on top of Simple log, or
> > perhaps storing
> > the logs in a couchdb/mongodb database instead of a sqlite or
> > any
> > relationnal database ?
> > Why not, it can be an option. But the default will stay sqlite,
> > because it's available everywhere.
>
> Available everywhere yes, but i usually fear logs stored in relationnal
> databases.
> A centralized non-relationnal base (couchdb) containing all monitoring
> logs could be interresting too. I saw you already coded a module using
> couchdb, so why not following this way too ;)
>
>
> > * I think it's important (in a production context) to secure
> > the broks
> > exchange process between scheduler and broker to become
> > stop-safe,
> > crash-safe and link-loss-safe, because I fear the reason we
> > get some
> > curious results in our availability/trends reports is that we
> > have lost
> > some important broks (like hosts/services state changes
> > messages) while
> > restarting daemons. Is such a feature is planned on the
> > roadmap ?
> > Yep :)
> >
> > But I'm wondering it you use the good module for reporting thing. Like
> > I said, livestatus is not done for that, it's just a immediate view.
> > Ther are no real reporting module from now. You can try with NDO, but
> > it's just slow for huge conf :(
> >
> > Such module will need indicators to be decided, and that why we really
> > wait to the Nareto project (nagios reporting) to startup with such
> > values, so we can wrote a dataware like module, that will work aside
> > livestatus (relational + real time monitoring is BAD! :) ).
>
>
> Livestatus was effectively designed first for presenting immediate
> purpose data like current status of hosts/services.
> But with its added feature to search in the Nagios logs it became the
> "de facto" module to use nowadays for getting historical data for
> reports generation.
>
I didn't know it used teh log for it, but if it does why not.
>
> Just don't forget that actually in Thruk and Multisite, the presentation
> module is also the historical data searching module. I mean, if Thruk
> uses Livestatus for presentation, it uses it also for gathering
> historical data for generating its reports, it can't use another module.
>
> So if you build a nice dataware module to store and centralize
> efficiently logs for keeping historical data (which is would be the best
> thing to do imho), Thruk and Multisite will need some modifications to
> use Livestatus for presentation AND this new module for getting
> historical data, and this could potentially break their original Nagios
> compatibility.
>
I'm just wondering if the "logs" are the best way for storing such reporting
data. It's true it's already agregated, because we log the start of a
problem, and the end too. So it's a good thing. For availability it sounds
ok, and it's the major thing for such a reporting tool after all. So maybe
yes, logs can be the data we need in fact :)
Jean
>
>
> Laurent
>
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
