[General] PEtALS monitoring & Administration

[cdeneux]

I propose you to use this post to specify the Monitoring a Administration features. It will be updated according our thought maturity for these features. Don't hesitate to contribute replying to this post !

About Administration feature

	
About exposing PEtALS kernel JMX API using other protocols

	For network configuration/security reasons or management console usage, it could be interesting to expose the PEtALS Kernel JMX API using protocols as HTTP, SNMP, WSDM.

	These protocols don't have to be included in the PEtALS Kernel because of:


	to avoid a source code complexity increase of the PEtALS kernel,

	to have PEtALS a light process,

	to avoid configuration conflict between components deployed into the container (ie: TCP port, ...)




Proposed solution wrote:
> 
> 
> 	A new BC (
> petals-bc-kernel) could be created to expose the PEtALS kernel JMX API as a service on NMR (each API method will be an operation of the service). So this service could be exposed outside PEtALS using petals-bc-soap for example, or a new compodent "petals-bc-snmp",
> 	petals-bc-kernel services will be compliant with WSDM, so in combination with petals-bc-soap we will have a support of WSDM managers (a SA can be delivered to expose theses services),
> 
> 	To be reusable with other JBI container, petals-bc-kernel will expose the JBI management API if it runs with a JBI container that is not PEtALS, and expose the PEtALS specific API if it runs with PEtALS.
> 
> 


About Monitoring feature
	The monitoring feature includes a statistics part. Two kinds of statistics:


	common statistics:


	number of messages (failed or sucessfull) per container, per exchange pattern, per interface, per service, per endpoint, during a given time (10 minutes),

	minimum response time, maximum response time, average response time, percentile 90, percentile 10, during a given time (10 minutes),

	...


	component specific statistics:


	petals-se-orchestra: number of pending processes, ...

	petals-bc-soap: number of requests rejected by Rampart for security reason, ...

	...


Any statistics information must be lost, particularly statistics available per duration.

	Monitoring API should be based on WSDM.



Proposed solution wrote:

> 
> 
> 	Common statistics should be computed by the PEtALS kernel and exposed using its JMX API (and so petals-bc-kernel). 
> A solution should be found concerning the storage of periodic statistics into the kernel waiting their consumption, perhaps using MEP "InRobust ",
> 	Component specific statistics should be included in the CDK using WSDM.
> 
> 
> 


About Administration & Monitoring GUI feature

	A centralized GUI is needed to avoid switching between each PEtALS of a PEtALS network,

	The GUI requires minimal network configuration (only one TCP port with one PEtALS node for example)



Proposed solution wrote:
> 
> 
> 	To have the minimal network configuration required by the GUI, it will be interesting to propose the GUI inside a SE (as the petals-sample-client), so all communication needs will be assumed by the NMR. The customer will only configure the link between the SE and its machine.
> 
> 	The GUI could be an embedded web-application, based on the current web-console.
> 
> 
> 





-------------------- m2f --------------------

Read this forum topic online here:
http://petals.ebmwebsourcing.com/forum/viewtopic.php?p=209#209

-------------------- m2f --------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum-list.petalslink.org/pipermail/general/attachments/20110316/38383437/attachment.htm>