Hi, > We noticed that availability/trend reports generated with Thurk via Livestatus broker module contains strange values that do not reflect the reality. Strange, because Thruk calculates reports from log messages. Are all of your reports wrong or just some?
> * Will the Shinken Livestatus module will be periodically > upgraded to follow the original Livestatus progression (new > features...) ? as far as it makes sense (= if it is necessary to make Thruk work), there will be updates. But if there will be a new feature in mk-livestatus, it will take longer than the next day until shinken-livestatus has this feature, too. Simply because the livestatus code progresses a lot faster than the documentation. I have to examine the livestatus code and re-engineer the functionality. > * What about the Livestatus sqlite database in one year, in > a big monitoring architecture ? big database, slow queries ? There's an index on the timestamp, so the performance shouldn't degrade significantly even if you have lots of data. Of course there should be a routine that deletes messages that are older than a configurable deadline, but i hadn't the time to implement it yet. > * 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, but i think sqlite is no bottleneck and the advantages of other db backends would be too marginal to justify the extra code. Gerhard ------------------------------------------------------------------------------ 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
