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:[EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
