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.
Difference between revisions of "SMILA/Project Concepts/Generic Management And Monitoring Concept"
m (→Category Tree Construction / Registration) |
|||
Line 12: | Line 12: | ||
== Technical proposal == | == Technical proposal == | ||
− | + | === Current SMILA Modules === | |
− | === Performance Counters Module Architecture === | + | ==== Performance Counters Module Architecture ==== |
See [[SMILA/Project_Concepts/Performance_counters_API|Performance Counters API]] | See [[SMILA/Project_Concepts/Performance_counters_API|Performance Counters API]] | ||
− | === Management Module Architecture === | + | ==== Management Module Architecture ==== |
This chart shows the Management architecture: | This chart shows the Management architecture: | ||
Line 24: | Line 24: | ||
//TODO | //TODO | ||
− | + | === Current SMILA Modules issues=== | |
− | === Performance Counters Module Architecture issues=== | + | ==== Performance Counters Module Architecture issues==== |
* its 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 ) | ||
Line 31: | Line 31: | ||
* its impossible to predict when counter will be initialized to start tracking because it initialized only on first usage | * its impossible to predict when counter will be initialized to start tracking because it initialized only on first usage | ||
− | === Management Module Architecture issues === | + | ==== Management Module Architecture issues ==== |
* its impossible to group agents into tree | * its impossible to group agents into tree | ||
− | === Common issues === | + | ==== Common issues ==== |
* its impossible to mix performance counters and management agents methods nested in one JMX leaf | * its impossible to mix performance counters and management agents methods nested in one JMX leaf | ||
=== Proposal === | === Proposal === | ||
+ | ==== Agent with Counters ==== | ||
Its suggested to use one registry from management module ( its more generic ) to use operations and counters. | Its suggested to use one registry from management module ( its more generic ) to use operations and counters. | ||
Line 74: | Line 75: | ||
</source> | </source> | ||
+ | ==== Usage ==== | ||
But how to use externally registered counters. For example Crawler Controller Agent register globally "Total" parameter. Each crawler should able to use it. | But how to use externally registered counters. For example Crawler Controller Agent register globally "Total" parameter. Each crawler should able to use it. | ||
Line 106: | Line 108: | ||
− | === Category Tree Construction / Registration === | + | ==== Category Tree Construction / Registration ==== |
Its suggested to construct categories tree during registration | Its suggested to construct categories tree during registration | ||
<source lang="java"> | <source lang="java"> |
Revision as of 05:06, 4 March 2009
Contents
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
Current SMILA Modules
Performance Counters Module Architecture
Management Module Architecture
This chart shows the Management architecture:
Current SMILA Modules issues
Performance Counters Module Architecture issues
- 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
- its impossible to group agents into tree
Common issues
- its impossible to mix performance counters and management agents methods nested in one JMX leaf
Proposal
Agent with Counters
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(); }
Usage
But how to use externally registered counters. For example Crawler Controller Agent register globally "Total" parameter. Each crawler should able to use it.
Mainly crawler should have access to CrawlerControllerAgent. Its possible to pass CrawlerControllerAgent directly to crawler. Also if CrawlerControllerAgent was registered as service (its preferable way) its possible to find it by OSGi services registry. But also its possible to generate unique ID for crawler agent during registration and use it later.
class ServiceActivatorFirst{ init(){ POC_AGENT_ID = ManagementRegistration.register(firstPocAgent) } dispose(){ ManagementRegistration.unregister(POC_AGENT_ID) } } // in other class class TheSecondClass{ usingTheFirstPocAgent(){ FirstPocAgent firstPocAgent = ManagementRegistration.get(ServiceActivatorFirst.POC_AGENT_ID) onePocAgent.getCounterOne().increment(); } }
Category Tree Construction / Registration
Its suggested to construct categories tree during registration
// manual categories ancestors iteration ManagementCategory category = ManagementRegistration.getCategory("Crawler").getCategory("Administration"); // first way to register category.register(agent); // the second way to register ManagementRegistration.register(category, agent); // the third way to register ManagementRegistration.register("Crawler/Administration", agent); // unregister ManagementRegistration.unregister(agent); // or category.unregister(agent);
Also its suggested to assume that creation/removing of categories is done automatically by ManagementRegistration and ManagementCategory classes.