[zeromq-dev] Logging format for sys://log transport

Andrew Hume andrew at research.att.com
Mon Nov 15 21:57:03 CET 2010


unless you think you need something quite different,
just follow existing practice, e.g. syslog.
that is, a type (== facility) and an impact (==severity==priority).

so i would lay it out as
byte 0 == impact
byte 1 == type
remaining bytes are UTF-8 encoding of message.

don't use multi-part (i suspect most people don't handle multi-part);  
it seems way overkill.

i bet for most folks, filtering on impact would be sufficient to weed  
out most stuff
and the rest can be done manually (no need to invoke complicated  
filtering stuff here).

i agree with martin; differentiate between logging and performance stuff
by the bind address. in fact, we could use this to distinguish versions;
for example, the first format could be "sys:/log0", and the next version
can be "sys:/log1" and so on. this way we won't need to manage  
migration.

keep it simple until we see a distinct need for something more  
complicated.

		andrew

On Nov 15, 2010, at 1:30 PM, Mikko Koppanen wrote:

> Hello,
>
> short background (and correct me if something is wrong here):
> The sys://log transport is an internal transport, a PUB socket
> providing logging information on what happens inside 0MQ. The
> information has not yet been defined but probably contains things such
> as severity, event type and message associated with the event.
>
> The question is how structure this information in the most effective
> way? One way would be to use severity as the topic and allow user to
> subscribe to all events above let's say level warning but this still
> leaves the question about the data format inside the message. My
> current thinking leans on something like:
>
> struct zmq_event_t {
>     uint8_t severity;
>     uint16_t type;
>     char *message;
> };
>
> where type could be something like ZMQ_EVENT_CONNECT,
> ZMQ_EVENT_DISCONNECT, ZMQ_EVENT_HWM_REACHED and so on.
>
> However this probably doesn't include all possible use-cases so it
> would be nice to hear ideas on what would be the best way to organise
> this information.
>
> -- 
> Mikko Koppanen
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 none currently
AT&T Labs - Research; member of USENIX and LOPSA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101115/4527ab1a/attachment.htm>


More information about the zeromq-dev mailing list