qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Strategies for managing and monitoring large Qpid topologies in mission critical systems
Date Thu, 22 Sep 2011 18:01:45 GMT
Hi David,
I think it's only the Java broker that exposes JMX attributes at the 
moment.

When I (eventually - hopefully next couple of weeks if I don't get 
distracted!!) get the Java QMF2 API done I'm hoping that'll be a good 
starting point for exposing QMF2 Management Objects as MBeans.

I believe that there is something called QMan mentioned in the Wiki that 
"is a tool that dynamically reads the QMF Schema information and creates 
JMX objects that consumed by any JMX console or application server to 
manage Qpid". I never got very far with that nor with the Java QMF1 
Console, which appeared fairly broken when I tried it - certainly with 
respect to the C++ broker (a lot of the brokenness was actually my old 
friend byte[] where String was expected :-)) so I gave up on that and 
started down the QMF2 path.

On the general topic of Management I was only really using OpenView as 
an example - I remain really interested in what people are using in 
practice to manage and monitor their broker networks. I'm looking into 
Cumin which looks quite nice. Does anyone know of nice eye-candy for 
visualising federated broker topologies - or am I going to have to write 
one :-)

Frase


David Karlsen wrote:
> OpenView has an JMX agent - that might be worthwhile?
> Seems like Qpid exposes quite a number of JMX attributes:
> https://cwiki.apache.org/qpid/qpid-jmx-management-console-user-guide.html
>
> 2011/9/21 Fraser Adams <fraser.adams@blueyonder.co.uk>
>
>   
>> Hello all,
>> I'm seeking thoughts from those in the community who have been using Qpid
>> in mission critical systems.
>>
>> So from my observations Qpid seems pretty stable, but there's alway the
>> possibility of exciting little gotchas especially as the complexity grows
>> and one starts to use fairly complex federated topologies of large numbers
>> of brokers. As an example in the early days we got bitten a lot by "blown"
>> links when consumers went down and queues filled to capacity. We're working
>> past that with queue routes/circular queues/servers with largish memory etc.
>>
>> Despite all that I'm expecting some gotchas so I want to turn my attention
>> to managing/monitoring/system health check.
>>
>> So what sort of things are others in similar positions using?
>>
>> The core tools qpid-config, qpid-route, qpid-stat etc. are very useful but
>> they are quite "mandraulic" so are people manually using those and
>> reactively solving problems or is there much in the way of proactive
>> management (fixing things before the clients shout :-) Are people scripting
>> the core tools or writing their own stuff? I've been doing a lot with QMF2
>> lately and there's clearly a huge potential with that, but I don't want to
>> go about reinventing wheels.
>>
>> Has anyone else integrated Qpid with Enterprise System Management tools
>> such as HP OpenView/OperationsManager? If so are they writing bespoke QMF
>> Console apps or scripting things like qpid-stat, qpid-printevents etc.
>>
>> I'd be interested to know what the recommended approaches are and whether
>> there are any "sister projects" looking into this - I'd like to keep things
>> cohesive with best practice and I'd like to avoid going down divergent
>> paths.
>>
>> Hope to hear from you
>> Cheers
>> Frase
>>
>> ------------------------------**------------------------------**---------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.**apache.org<users-subscribe@qpid.apache.org>
>>
>>
>>     
>
>
>   


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


Mime
View raw message