qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: QPID Management Update
Date Wed, 01 Oct 2008 19:55:27 GMT
Robert Greig wrote:
>> Agents are producers and maintainers of management data.  They are software
>> components like the messaging broker, a plugin store module, or external
>> third-party software packages.  Agents provide a schema for their management
>> model that describes object and event classes.  Object classes may have
>> methods with arbitrary sets of input and output parameters for very flexible
>> and powerful management capability.  An agent API is provided in C++ along
>> with an XML-based schema compiler to get agent developers up and running
>> quickly.
> So, if the Java broker wanted to become a agent, it would be necessary
> to develop the equivalent of the Agent API in C++?
> Are all the existing agent-aware apps currently written in C++ (I presume so)?
Currently all apps using the agent API are in C++.  A likely next 
implementation for the API is Python to support non-integrated 
management agents (i.e. scripts that query their targets rather than 
being built into them).

I mentioned the possibility of a JMX => QMF bridge (the opposite of 
QMan) which will make JMX-manageable apps accessible through QMF.  This 
is a possible strategy for the Java broker.
>> The QMF Broker is co-located with the QPID messaging broker and it handles
>> the efficient routing of management data and meta-data to the places it
>> needs to be.
> You mean that if I run a qpid c++ message broker, it acts as a QMF
> broker (in the same process)? Is the idea that an org will have a
> small number of QMF brokers? Is it possible to configure qpid c++
> message brokers to use a specified QMF broker (i.e. other than
> "itself")?
It might be more accurate to call the QMF broker the "QMF exchange" 
since it is implemented as
a derivative of the topic exchange.

The QMF broker is fairly lightweight.  Its responsibilities are as follows:

  1) Manage and assign unique banks of object identifiers to the agents,
  2) Cache schema information for consoles, and
  3) Enforce access control (ACLs) tasks that involve fields from the 
message bodies.

All of the message routing involved uses plain AMQP.

Currently the QMF broker functionality is present in all brokers and 
every broker is a standalone
QMF "domain".  If a deployment has multiple brokers, a console must 
connect to all of the brokers to
manage the entire deployment.

It is desired that the QMF broker functionality be distributed such that 
a console may make a single connection to its nearest broker to manage 
the entire enterprise.  This capability has not yet been implemented.
>> Many thanks to Andrea Gazzarini who has contributed a QMF/JMX bridge (QMan)
>> to the project.  This allows Java JMX consoles to natively access all of the
>> management data in an entire QMF enterprise.  I've attached a pair of screen
>> shots of a JMX console viewing QMF data through Andrea's tool.
> Is this a console in QMF terms, that in turn exposes QMF managed
> objects over JMX?
That is correct.  QMan exposes QMF content as JMX MBeans.
> Is SNMP on your roadmap or integration with widely use enterprise
> monitoring packages such as IBM Tivoli or Microsoft SCOM?
SNMP is not on *my* road map currently.  I think that an SNMP bridge 
(similar to the JMX one) would be very useful.  One interesting aspect 
is that QMF and JMX are self-describing whereas SNMP is not.  There 
would need to be a way to generate SNMP MIBs from QMF/JMX schemata.  Or 
alternatively a specification of a mapping from QMF/JMX to a MIB.

One thing that I am thinking about is generating Syslog events from QMF 
> RG

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message