Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SMILA/Project Concepts/Generic Management And Monitoring Concept"

Line 1: Line 1:
 
== Description ==
 
== Description ==
  
Now SMILA uses separate modules for Management and for Performance Counters but both uses JMX (jconsoe) as a default presentation layer.
+
Now SMILA uses separate modules for Management and for Performance Counters but both uses JMX (jconsole) as a default presentation layer.
  
During usage it was found that both modules have issues.
+
During other components development it was found that both modules have issues.
This page is a concept about merging modules into one generic module and to avoid issues found.
+
 
 +
This page is a concept about merging both modules into one generic module and to avoid issues found.
  
 
== Discussion ==
 
== Discussion ==
Line 12: Line 13:
  
  
=== Performance Counters Module Architecture problems===
+
=== Performance Counters Module Architecture issues===
  
 
See [[SMILA/Project_Concepts/Performance_counters_API|Performance Counters API]]
 
See [[SMILA/Project_Concepts/Performance_counters_API|Performance Counters API]]
  
* impossible to group counters into tree legally by API ( now its used "JMX specific names" hack to group them )
+
* its impossible to group counters into tree legally by API ( now its used "JMX specific names" hack to group them )
* impossible to have a few counters on one JMX leaf
+
* its impossible to have few counters nested in one JMX leaf
 +
* its impossible to predict when counter will be initialized to start tracking because it initialized only on first usage
  
=== Management Module Architecture problems ===
+
=== Management Module Architecture issues ===
  
 
This chart shows the Management architecture:
 
This chart shows the Management architecture:
Line 25: Line 27:
 
[[Image:ManagementRegistry.png]]
 
[[Image:ManagementRegistry.png]]
 
//TODO
 
//TODO
 
  
 
* its impossible to group agents into tree
 
* its impossible to group agents into tree
  
=== Common problems===
+
=== Common problems ===
* its impossible to mix performance counters and management agents methods in one JMX leaf
+
* its impossible to mix performance counters and management agents methods nested in one JMX leaf
 +
 
 +
=== Proposal ===
 +
Its suggested to use one registry from management module ( its more generic ) to use operations and counters.
 +
 
 +
Description and  initialization of performance counters will be in the Management Agent implementation.
 +
It will allow to group counters (also together with management operations).
 +
 
 +
<source lang="java">
 +
class MyAgent implements Agent{
 +
 
 +
  // some management operation
 +
  public  doSomething(args[]);
 +
 
 +
  // some performance counter related to that module
 +
  public PerformanceCounter getCounterOne();
 +
 
 +
  // other performance counter related to that module
 +
  public PerformanceCounter getCounterTwo();
 +
 +
}
 +
</source>
 +
 
 +
But its also possible (and suggested) to separate them because dependencies.
 +
Mainly Management Agent using service and not used inside the service. And is visa versa for Counters Agent
 +
 
 +
<source lang="java">
 +
class MyManagementAgent implements Agent{
 +
  ...
 +
  public  doSomething(args[]);
 +
  ....
 +
 
 +
}
 +
class MyCountersAgent implements Agent{
 +
  public PerformanceCounter getCounterOne();
 +
  public PerformanceCounter getCounterTwo();
 +
}
 +
</source>
 +
 
 +
 
 +
 
  
 
[[Category:SMILA]]
 
[[Category:SMILA]]

Revision as of 12:35, 3 March 2009

Description

Now SMILA uses separate modules for Management and for Performance Counters but both uses JMX (jconsole) as a default presentation layer.

During other components development it was found that both modules have issues.

This page is a concept about merging both modules into one generic module and to avoid issues found.

Discussion

Technical proposal

Performance Counters Module Architecture issues

See Performance Counters API

  • its impossible to group counters into tree legally by API ( now its used "JMX specific names" hack to group them )
  • its impossible to have few counters nested in one JMX leaf
  • its impossible to predict when counter will be initialized to start tracking because it initialized only on first usage

Management Module Architecture issues

This chart shows the Management architecture:

ManagementRegistry.png //TODO

  • its impossible to group agents into tree

Common problems

  • its impossible to mix performance counters and management agents methods nested in one JMX leaf

Proposal

Its suggested to use one registry from management module ( its more generic ) to use operations and counters.

Description and initialization of performance counters will be in the Management Agent implementation. It will allow to group counters (also together with management operations).

class MyAgent implements Agent{
 
   // some management operation
   public  doSomething(args[]);
 
   // some performance counter related to that module
   public PerformanceCounter getCounterOne();
 
   // other performance counter related to that module
   public PerformanceCounter getCounterTwo();
 
}

But its also possible (and suggested) to separate them because dependencies. Mainly Management Agent using service and not used inside the service. And is visa versa for Counters Agent

class MyManagementAgent implements Agent{
  ...
   public  doSomething(args[]);
  ....
 
}
class MyCountersAgent implements Agent{
   public PerformanceCounter getCounterOne();
   public PerformanceCounter getCounterTwo();
}

Copyright © Eclipse Foundation, Inc. All Rights Reserved.