On Thu, Aug 23, 2012 at 10:15 PM, Hartmut Goebel <
h.goe...@crazy-compilers.com> wrote:
> Hi,
>
> When implementing the new logging system I discovered a serious design
> problem:
>
> There are different formats of messages sent to the broker:
>
> 1) Log-Messages, having a format containing the log-level
>
> 2) State-Messages, (e.g. "SERVICE ALLERT") which do not contain a
> levelname.
>
> The current implementation does not differentiate both kinds of messages
> -- but they are quite different: State-Messages are essential, while
> log-messages could be ignored without (AFAIK) any impact to the function.
>
> Both types of messages are send as Broks to the broker.
>
> I propose the following change:
>
> No longer use the logging module for sending state-messages to the
> receiver. Instead add a minimal "state-sender" doing this.
>
> Now the question is: Should state-messages be logged on the sender side
> (the scheduler)? If so, we need to trick the logger, as it send all logs
> to the broker, too, so each state-change would be send twice.
>
> IMHO we do not need to log state-messages at the scheduler only with
> level "DEBUG" which is not send to the broker. State-messages are not
> interesting at the scheduler side except for debugging.
>
> What do you think?
>
Hi,
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.
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 :)
Jean
------------------------------------------------------------------------------
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
