Monitoring and managing are two different things. I think
- What listeners/services are running?
- Recycle the listener/service
both of which are close to what we already have for an .esb archive (See the jmx-console)
- Is the listener/service alive?
- How many messages are waiting to be processed?
- How old is the oldest message?
and here I'd like to add:
- Statistics/history on message processing over time: Messages/min for each service.
for each service:
maximum time of processing a message
average time of message processing
standard deviation of message processing time
messages/min over 1 minute period
messages/min over 5 minute period
messages/min over 60 minute period
maximum wait time for a message to be processed
We're really talking about runtime management/governance aspects. That does encapsulate monitoring as well, because in order to manage, you need to know what's going on ;-)
The sorts of things I'd like us to see be able to do include:
What services are deployed?
How long have they been available
- What rules have been triggered and how often?
- What messages have not been delivered and why?
- Number of failed requests and why e.g., endpoint down versus message incompatibility
- Number of messages through a service
- Time for responses
Supported message set
Supported message exchange pattern
- what transforms have been triggered
- time to do a transform (cross referenced with message size)
A lot of this can then be cross referenced to determine things like service/network bottlenecks, availability issues, application deployment problems, scalability requirements etc.
Tom, I'd start to make progress based on this feedback. This will always be a moving target to some degree, but what's been mentioned here make a good first pass.