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]
