Hi, I've spend some more thought on this.
I really wonder why the hell we are putting data into strings in these raise_* methods, just to cut it into pieces a view seconds later. This get even more weird when livestatus-brkoger does this. IMHO these raise_* methods should but either tuples or some kind of "Result"-objects into the brok. Am 27.08.2012 17:12, schrieb nap: > good point indeed. Theses logs are not so interesting in the scheduler > side. We can say that such logs are quite "raw". But what about just > add a new data in the log brok for this? So we know how to split state > (in fact business related log) logs and tool related one. With a > logger.raw call, we can easily set the good brok data. IMHO this gets things worse. Results are not logs and those should not be mixed up. I'm going to implement: - some "result logger" (to be replaces by something better soon) - all raise_* methods put the results there - the "result logger" puts the strings into the queue as a Brok - the "result logger" log the string with level DEBUG > so all will be brok.type = 'log' (so it's easy to wrote a "dump all > logs" module in the broker side) and if the module is smart enough to > split them, it just got to look at the brok :) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | ------------------------------------------------------------------------------ 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/ _______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
