qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject Re: QIP proposal: Easy Broker Info
Date Thu, 13 Jan 2011 01:07:20 GMT
On 12 Jan 2011, at 19:43, mick wrote:
> Solution
>         Brokers write information about themselves to files in a
>         well-known directory ( i.e. /var/run/qpid ). This allows any
>         running program or script to easily discover what brokers are
>         running, what ports they are listening to for which  
> transports,
>         and any other information that the brokers want to share. This
>         is strictly broker-based, and works whether or not  
> management is
>         enabled. Brokers only write the info, and non-brokers only  
> read
>         it. The info is in a simple, easily grepped name-value format,
>         whose names are tree-structured. For example:
>         "transports_tcp_port 6666". There is a single name-value pair
>         per line.


One problem I see with this is that any "enterprise" management  
system (definitions may vary) that may want to know this information  
is not necessarily going to have local file-system access to all the  
machines running the brokers, and the system doesn't lend itself to  
automated service-discovery. Also, what about issues with, say,  
running three brokers as three different users with various rights  
trying to access the same files - I suppose a 'qpid' user or group  
can own the directory? There is also the issue of other operating  
systems and platforms, particularly Windows Server, but that is also  
just a matter of convention.

Couldn't a mature technology like SNMP, which has a large ecosystem  
of services, tools and SDKs, be used instead?

We could define and publish a MIB for Qpid, that can become an  
officially published standard. SNMP lends itself well to describing  
arbitrary name/value key-pairs, and is an even better choice for  
periodic updating of data with counters and sending of traps for  
events, and so on. In fact, it's only the publishing, not the data  
collection or generation mechanism that is different. Then we just  
have the broker publish to SNMP instead. Also, "grep" as an  
information retrieval tool tool is not going to go down well with the  
HP OpenView or SolarWinds type of user, although I suppose a  
translator agent could be provided to read and re-publish the /var/ 
run file data.

-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message