james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Short" <ssh...@postx.com>
Subject RE: Monitoring in James (was Monitoring)
Date Mon, 08 Dec 2003 17:55:59 GMT
Guys,

Shall I go ahead with this or not?  I need to be working on this for our
product this week and I'd really like to contribute to James.

Steve

> -----Original Message-----
> From: Steve Short 
> Sent: Friday, December 05, 2003 4:26 PM
> To: James Developers List
> Subject: Monitoring in James (was Monitoring)
> 
> 
> 
> We could do it this way.
> 
> The Monitor service is effectively a registry of name to 
> metrics object mappings, so it provides register() and 
> lookup() methods to set and retrieve these mappings.  This 
> can be be done using JNDI.  The naming scheme provides an 
> implied hierarchy.  It does not know or do anything about 
> aggregating metric values.  Eventually we could provide 
> several implementations of the service one for JMX, one for 
> SNMP.  Or one implentation with multiple adaptors (SNMP, 
> AgentX) - kind of like way JMX has HTTP and RMI adaptors.
> 
> The monitored services are responsible for creating and 
> registering metrics sets, they are also responsible for 
> setting up the aggregation rules using event listeners using 
> information obtained from the config file.  Something like this:
> 
>     <monitor>
>         <name>metrics/mta/protocols/SMTP</name>
>         <listeners>
>             <listener 
> type="MonitorMetrics">metrics/mta/protocols</aggregate>
>             <listener 
> type="MonitorMtaMetrics">metrics/mta/</aggregate>
>         </aggregations>
>     </monitor>
> 
> We could drop the type if we give top level MTA metrics the 
> full set of group metrics and simply ignore the ones that 
> aren't used or relevant. Protocol specific adaptors such as 
> SNMP would be responsible for ignoring unwanted attributes.
> 
> Would result in initialization code equivalent to:
> 
>     MonitorMetrics mtaMetrics       =
> (MonitorMtaMetrics)monitor.lookup("metrics/mta");
>     MonitorMetrics protocolMetrics  = 
> (MonitorMetrics)monitor.lookup("metrics/mta/protocols");
>     
>     MonitorMetrics metrics          = (MonitorMetrics)new
> MonitorMetricsSet();
>     
>     metrics.addListener(protocolMetrics);
>     metrics.addListener(mtaMetrics)
>     
>     monitor.register("metrics/mta/protocols/SMTP", metrics);
> 
> Actual metric updates would be done using methods such as:
> 
>     metrics.addMessageReceived(long deltaCount, long 
> deltaSize, long deltaRecipients);
>     metrics.addMessageStored(long deltaCount, long deltaSize, 
> long deltaRecipients);
>     metrics.subtractMessageStored(long deltaCount, long 
> deltaSize, long deltaRecipients);
>     metrics.addMessageTransmitted(long deltaCount, long 
> deltaSize, long deltaRecipients);
>     metrics.addMessageConversion(long deltaCount);
>     metrics.addLoopDetected(long deltaCount);
>  
> 
> 
> This makes the monitor service much simpler, but it puts a 
> lot more burden on the individual components to set up the 
> hierachy associations and the aggregation using listeners.  
> It also makes mistakes much more likely because the full name 
> strings have to be specified multiple times in the config 
> file and have match, but I guess good error detection and 
> reporting would alleviate this somewhat.  There's also the 
> issue of how and when to create group entries such as 
> "Protocols" that don't have a direct implementation point in 
> James - this could be done automatically at register() time 
> but means that typos will result in new entries being created 
> instead of useful error messages being output.
> 
> More thoughts?
> 
> Steve
> 
> 
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: Friday, December 05, 2003 10:13 AM
> > To: James Developers List
> > Subject: RE: Monitoring
> > 
> > 
> > > 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.
> > 
> > My suggestion would be to use JNDI for this purpose, and to
> > have a JNDI context containing the metrics.
> > 
> >   ../metrics/protocols/SMTP/..
> > 
> > An SNMP service would expose an SNMP protocol view of the
> > information in the metrics context.  A component would get 
> > its metrics context and interact with the beans that we'll 
> > probably store there.  So long as we have a suitably common 
> > interface, the rest is automagic.
> > 
> > 	--- Noel
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message