On Sun, 29 Jul 2012, Michael Friedrich wrote:

> there's been plenty of effort in making this a lot better, but given the
> design data input works in *DO, you have 2 possibilities:
>
> - let the core push to a kernel msg queue until it's full, waiting
> endless for data updates on the gui (and have the problem with queue
> full - drop data, like NDO 1.5 has)
> - let the core wait for data being processed, showing accurate and
> actual data on the gui, but a bit more wait time due to various
> dependencies on the data inserts/updates, parallel operations instead
> of a serialized flow is not possible.

    I was looking at this problem this morning and wonder whether
putting a FIFO in between idomod and ido2db might not be the
ticket.  That way, the core would shove stuff to the FIFO and
get on with things and ido2db would pull stuff out of the FIFO
at its own pace, eventually catching up with core.  This would
yield snappier performance on core and would still properly
maintain data-order in the database.  The question, then, would
become one of making the FIFO how deep, in memory or on disk,
and with the buffer as a separate process or multi-threading
ido2db?

> one would want such a change, but then you might just throw
> away the database schema, and rewrite the ido2db daemon. and
> while you're at it, change the idomod data schema as well.

    I rather like the data schema as-is, and have written plenty
of custom stuff for it.  Changing schemas mid-flight is a pretty
good way to rile the user community.

>>      It might be possible if one eschews the use of ido2db directly and
>> periodically runs "log2db" using the icinga.log file as input.
>
> that method only imports logs into the logentries table, but nothing
> else. to target state and config information, this is NOT a safe way, as
> well as does not replace reporting information.

    In actually looking at it this morning it completely misses the
*status tables thereby likely making the notion utterly useless for
Icinga-web (as well as niceties like Nagvis).  I hereby withdraw
the comment for any use other than log-entries.

    Cheers!

+------------------------------------------------+---------------------+
| Carl Richard Friend (UNIX Sysadmin)            | West Boylston       |
| Minicomputer Collector / Enthusiast            | Massachusetts, USA  |
| mailto:[email protected]                        +---------------------+
| http://users.rcn.com/crfriend/museum           | ICBM: 42:22N 71:47W |
+------------------------------------------------+---------------------+

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/icinga-users

Reply via email to