Firstly to answer Serge's question: I've looked around for Java SNMP
libraries and the most fully developed ones are commercial (obviously)
or GPL. The only decent usable LGPL one I've found is Joesnmp, which is
currently part of the Opennms project but is in the process of becoming
an independent project at Sourceforge. While Joesnmp is currently a
client only library - I have created a simple server session class and
implemented a very crude SNMP agent using it. It's really ugly hackery
but I can load my agent as a JMX Mbean (in JBoss) and I can map simple
SNMP OIDs to attributes within MBean instances. No prizes for guessing
where I'm going with this! However my knowledge of SNMP is severely
limited and I need to find out more about how JMX SNMP adaptors are
expected to behave before doing any more on this front.
Back to Monitoring in James. I was thinking in broad terms of
implementing a Monitor service block. The Monitor service would be
exposed via JMX (automatically thanks to Phoenix and hopefully Merlin).
The monitor service configuration would allow declaration of groups and
act as a factory for other components that wish to be monitored. The
pre-declared groups would likely be the aggragating groups and the
individual services could then acquire a monitor record as a child of
any of the predeclared groups. E.g the monitor config might look like
this:
<monitor>
<groups>
<group name="Repositories" type="NonAggregating"/>
<group name="Protocols" type="NonAggregating"/>
<group name="Processors" type="NonAggregating"/>
</groups>
</monitor>
(The group elements can nest recursively if need be).
Each component the wishes to register for monitoring would have a config
element like this:
<smtpserver>
...
<monitor enabled="true">
<name>SMTP</name>
<parent>Protocols</parent>
<type>AggregateToParentAndRoot</type>
</monitor>
</smtpserver>
This causes the SMTPServer to create a new monitor record as a child of
Protocols and with an aggregation strategy that causes it to propagate
counter updates to its parent "Protocols" and to the top level MTA Entry
record. I'm not yet sure whether it is sufficient to declare the
aggregation stragety for the whole record or whether we would need to
specify this at the individual field level. I'm not too worried about
this as the aggregation strategy would be realised by a Java class so we
could always add a new strategy specific for, say, SMTP called
SMTPAggregationStrategy which only propagates the fields it needs to.
However any better ideas in this are would be most welcome.
I di think about declaring all of the group records in the monitor
config section, but that wont work so well for James entities such as
the RemoteDelivery Queues and Processors because the monitor service
should not need additional confiruation when a new processor is added,
hence the approach above where each component registers with the monitor
service.
I've already knocked up a quick test and I have the SMTP Server received
message counts being exposed via JMX and I've used MC4J to create a
real-time graph of messages received - jumping the gun a little but so
very cool I couldn't resist.
What remains to be done:
- agree a design
- decide on a default monitor hierarchy
- determine which stats get updated by each service
- decide which service stats get propagated to the root mta record
I'd like to be able to expose the individal group records, e.g. spool
queue or the outgoing queue as JMX Mbeans so make it possible to monitor
these via JMX directly - however I don't think the container exposes its
ServiceManager to James. I can do it using JMX calls but if Stephen
McConnell is reading - please treat this as a feature request for
Merlin's JMX implemtation.
Oh, as part of this effort, it would make sense to split the
RemoteDelivery mailet into a block and a mailet, with all of the
threading and repository management taken care of by the block and the
mailet would simple invoke the block when it has a message to send.
All thoughts welcome.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
