Technical information of component for monitoring

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Technical information of component for monitoring

rnaudin
Hi all,
We will propose an Admin operation to get technical information about component/SA/SU, in order to audit/alert... with any admin client.

For the statistic data, it will be a push/pull mechanism. The data are proposed periodically by the component/SU, in a 'window'.
The admin operation retrieve the last 'windowed' ones.
The window can be reconfigured at runtime by a component runtime parameter.

I propose this thread to collect the informations that seam relevant to expose.

I have identified common data:
-last start/stop/shutdown (component/SA/SU)
-number of messages processed since last recovery (component/SU)
-number of messages in fault/error since last recovery (component/SU)
-number of messages processed since last window (component/SU)
-number of messages in fault/error since last window (component/SU)

Some interesting statistics:
-ratio of the static part of the processor thread pool (the borrow time against the idle time for all the threads) since last window
-number of threads of the dynamic part of the processor thread pool used since last window

specific data can be exposed by component:
-number of connection failure by BCs (since there a retry policy, the messages in fault/error are not enough)
-number of BPEL instance eg for BPEL...

others ideas?




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

Subscribe/Unsubscribe emails notifications :
http://forum.petalslink.com/m2f_usercp.php

Response to this email will be posted on the Petals forum.
Please delete the existing text before responding :)

Read the topic online:
http://forum.petalslink.com/viewtopic.php?p=31502#31502

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




_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Technical information of component for monitoring

fgardes-3
Maybe something about the transporter (local queue size, network queue size)
to be able to see through an easy way if we've got a network issue?


-----Message d'origine-----
De : rnaudin [mailto:[hidden email]]
Envoy� : lundi 23 ao�t 2010 15:52
� : [hidden email]
Objet : Technical information of component for monitoring

Hi all,
We will propose an Admin operation to get technical information about
component/SA/SU, in order to audit/alert... with any admin client.

For the statistic data, it will be a push/pull mechanism. The data are
proposed periodically by the component/SU, in a 'window'.
The admin operation retrieve the last 'windowed' ones.
The window can be reconfigured at runtime by a component runtime parameter.

I propose this thread to collect the informations that seam relevant to
expose.

I have identified common data:
-last start/stop/shutdown (component/SA/SU) -number of messages processed
since last recovery (component/SU) -number of messages in fault/error since
last recovery (component/SU) -number of messages processed since last window
(component/SU) -number of messages in fault/error since last window
(component/SU)

Some interesting statistics:
-ratio of the static part of the processor thread pool (the borrow time
against the idle time for all the threads) since last window -number of
threads of the dynamic part of the processor thread pool used since last
window

specific data can be exposed by component:
-number of connection failure by BCs (since there a retry policy, the
messages in fault/error are not enough) -number of BPEL instance eg for
BPEL...

others ideas?












*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

 --Posted via petals mailing-list (http://forum.petalslink.com/m2f_usercp.php)--




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

Subscribe/Unsubscribe emails notifications :
http://forum.petalslink.com/m2f_usercp.php

Response to this email will be posted on the Petals forum.
Please delete the existing text before responding :)

Read the topic online:
http://forum.petalslink.com/viewtopic.php?p=31503#31503

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





_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Technical information of component for monitoring

Christophe DENEUX
Administrator
In reply to this post by rnaudin
Can you add some time statistics per endpoint as
  - incoming message processing time (min/avg/max and percentil 10/50/90)
  - outcoming mesage processing time  (min/avg/max and percentil 10/50/90)
  - connection status (connected, disconnected)
  - number of established connections


In your proposal:
   - can you distinct counters for fault and error ?
   - can you count message number by endpoint ?




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

Subscribe/Unsubscribe emails notifications :
http://forum.petalslink.com/m2f_usercp.php

Response to this email will be posted on the Petals forum.
Please delete the existing text before responding :)

Read the topic online:
http://forum.petalslink.com/viewtopic.php?p=31504#31504

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




_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Christophe DENEUX
Petals ESB Architect
Linagora
Twitter: @ChrisDENEUX
Reply | Threaded
Open this post in threaded view
|

Re: Technical information of component for monitoring

rnaudin
In reply to this post by rnaudin
OK,
 [Arrow] about the NMR queues states (Router/Transporter), the internal model will change with the 'HA at service level and Robustness at service level' features.
Once these feature done, i'll propose some monitoring infos about these queues.

 [Arrow] About incoming and outcoming processing time, there already time handled in the Router Monitor.
Once the queues evolution done in the NMR, the time spend in NMR queue can be too handled by the Router Monitor. So you will have all the time spent at each step of an exchange life hold in the  Router Monitor.
Maybe BCs can propose a transfer processing time? it's up to the BCs implementors, as specific data for specific component will be possible.

 [Arrow] Number of established connection, good point, as we spoke to pool the connections when possible in all the components, a pool with only 'dynamic' elements (no permanent element).
BTW, what is the difference between
> connection status (connected, disconnected)
 and  
> number of established connections


 [Arrow] Differ the fault and error, ok, not to hard.

 [Arrow] Message per endpoint. I was speaking by SU, as a SU is the administrable element, but we can 'fine grained' to endpoint. We must know what SU is bound to what endpoint in that case.
Although, there is endpoints that can be activated directly by component, so not bound to an SU.
Just a litlle more complex to handle in the CDK.




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

Subscribe/Unsubscribe emails notifications :
http://forum.petalslink.com/m2f_usercp.php

Response to this email will be posted on the Petals forum.
Please delete the existing text before responding :)

Read the topic online:
http://forum.petalslink.com/viewtopic.php?p=31505#31505

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




_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Technical information of component for monitoring

Christophe DENEUX
Administrator
In reply to this post by rnaudin
Le lundi 23 ao�t 2010 � 16:32 +0200, rnaudin a �crit :
>  
> >
> > [Arrow] About incoming and outcoming processing time, there already time handled in the Router Monitor.
> > Once the queues evolution done in the NMR, the time spend in NMR queue can be too handled by the Router Monitor. So you will have all the time spent at each step of an exchange life hold in the  Router Monitor.
> > Maybe BCs can propose a transfer processing time? it's up to the BCs implementors, as specific data for specific component will be possible.
> >
>  
 Yes, it's a specific data. Have we no way to get it at the kernel level, perhaps with an extension to the JBI API ? If the component doen't support this API extension the feature is deactivated.

>  
> >
> >
> > [Arrow] Number of established connection, good point, as we spoke to pool the connections when possible in all the components, a pool with only 'dynamic' elements (no permanent element).
> > BTW, what is the difference between
> >
> > > connection status (connected, disconnected)
> > >
> > and  
> >
> > > number of established connections
> > >
> >
>  
 Yes, they are close and linked. "Number of established connections" is more precise than the other one:
connection status = (number of established connection > 1)
We should keep "Number of established connections"

>  
> >
> >
> >
> > [Arrow] Differ the fault and error, ok, not to hard.
> >
> > [Arrow] Message per endpoint. I was speaking by SU, as a SU is the administrable element, but we can 'fine grained' to endpoint. We must know what SU is bound to what endpoint in that case.
> > Although, there is endpoints that can be activated directly by component, so not bound to an SU.
> > Just a litlle more complex to handle in the CDK.
> >
>  
 This can permit to verify the HA at service level.

 --Posted via petals mailing-list (http://forum.petalslink.com/m2f_usercp.php)--




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

Subscribe/Unsubscribe emails notifications :
http://forum.petalslink.com/m2f_usercp.php

Response to this email will be posted on the Petals forum.
Please delete the existing text before responding :)

Read the topic online:
http://forum.petalslink.com/viewtopic.php?p=31508#31508

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





_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Christophe DENEUX
Petals ESB Architect
Linagora
Twitter: @ChrisDENEUX