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 "Riena/Getting Started with Client Monitoring"

(LogServiceCollector)
 
(34 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Getting Started with Client Monitoring ==
+
{{#eclipseproject:rt.riena}}
 +
{{RienaBreadcrumbs|
 +
[[Riena Project]] | [[Riena Getting started|Getting Started]] | Client Monitoring}}
 +
 
 +
{| align="right"
 +
| __TOC__
 +
|}
  
 
{{BlueBox|
 
{{BlueBox|
Line 6: Line 12:
 
::::(http://www.sacred-texts.com/ufo/mars/wow.htm)
 
::::(http://www.sacred-texts.com/ufo/mars/wow.htm)
 
}}
 
}}
 
  
 
'''Oh, no, stop! No, that's of course ''NOT'' the intent of Client Monitoring.'''
 
'''Oh, no, stop! No, that's of course ''NOT'' the intent of Client Monitoring.'''
  
 +
== Use Case ==
 +
The problem that we want to help solving with Client Monitoring is to automatically provide the operators of business applications with measurements about the health and/or usage of a system. With this information a system can be optimized (e.g. bugs fixed, user interface improved, etc.) before the user of the system stumbles upon these issues.
  
=== Use Case ===
 
The problem that we want to help solving with Client Monitoring is to automatically provide the operators of business applications with measurements about the health and/or usage of a system. With this information a system can be optimized (e.g. bugs fixed, user interface improved, etc.) before the user of the system stumbles upon these issues.<br>
 
 
Furthermore the automatically provided information ''can'' be much more precise than ''bug reports'' entered by the user - ''can'' because the developers of the application are now responsible for providing the necessary information, not the user. Remember the targeted user of a Riena application is ''not'' a developer.
 
Furthermore the automatically provided information ''can'' be much more precise than ''bug reports'' entered by the user - ''can'' because the developers of the application are now responsible for providing the necessary information, not the user. Remember the targeted user of a Riena application is ''not'' a developer.
  
Possible kind of measurements:
+
Possible kinds of measurements:
 
* logging data, e.g. certain events produced by Eclipse's LogService
 
* logging data, e.g. certain events produced by Eclipse's LogService
 
* usage data
 
* usage data
Line 23: Line 28:
 
* ..
 
* ..
  
=== Components ===
+
== Components ==
The Client Monitoring requires two bundles
+
The Client Monitoring requires two bundles:
* org.eclipse.riena.monitor.common - containing classes and interfaces that are common to both client and server side of the application. This is a necessity when using Riena's communication
+
; org.eclipse.riena.monitor.common
* org.eclipse.riena.monitor.client - containing the aliens  - ''ehm'' - no the workhorses
+
: containing classes and interfaces that are common to both client and server side of the application. This is a necessity when using Riena's communication
 +
; org.eclipse.riena.monitor.client  
 +
: containing the aliens  - ''ehm'' - no, the workhorses
  
The structure of the Client Monitoring is quite simple. There are a bunch of collectors gathering the required information and passing them to the aggregator. The aggregator puts this information in a store and activates the sender. The sender transmits the information to the receiver which is usually a Riena remote service. Activation of the sender is usually triggered by the collectors but can also triggered by any other component.<br>
+
The structure of Client Monitoring is quite simple. There are a bunch of collectors gathering the required information and passing them to the aggregator. The aggregator puts this information in a store and activates the sender. The sender transmits the information to the receiver which is usually a Riena remote service. Activation of the sender is usually triggered by the collectors but can also triggered by any other component.<br>
  
==== Collectors ====
+
[[Image:Riena_Cient_Monitoring_Components.PNG]]
Collectors gather the information that should be transferred to the server. They have to either implement the interface <code>org.eclipse.riena.monitor.client.ICollector</code> or extend <code>org.eclipse.riena.monitor.client.AbstractCollector</code> - extending the <code>AbstractCollector</code> is easier. There are already a few ready to use collectors, e.g the <code>LogServiceCollector</code>. All collectors have to be defined with the extension point <code>org.eclipse.riena.monitor.collectors</code>.
+
 
===== LogServiceCollector =====
+
=== Collectors ===
 +
Collectors gather the information that should be transferred to the server. They have to either implement the interface <code>org.eclipse.riena.monitor.client.ICollector</code> or extend <code>org.eclipse.riena.monitor.client.AbstractCollector</code> - extending the <code>AbstractCollector</code> is easier. There are already a few ready-to-use collectors, e.g the <code>LogServiceCollector</code>. All collectors have to be defined with the extension point <code>org.eclipse.riena.monitor.collectors</code>.
 +
==== LogServiceCollector ====
 
Obviously the <code>LogServiceCollector</code> listens to log service events and records them. It has to be defined with something like that:
 
Obviously the <code>LogServiceCollector</code> listens to log service events and records them. It has to be defined with something like that:
 
<source lang="xml">
 
<source lang="xml">
 
<extension point="org.eclipse.riena.monitor.collectors">
 
<extension point="org.eclipse.riena.monitor.collectors">
    <collector
+
<collector
        category="LogCollector"
+
category="LogCollector"
        maxItems="50"
+
maxItems="50"
        class="org.eclipse.riena.monitor.client.LogServiceCollector: collectRange=1..3; triggerRange=1, 2">
+
class="org.eclipse.riena.monitor.client.LogServiceCollector: collectRange=1..3; triggerRange=1, 2; async=false">
    </collector>
+
</collector>
 
</extension>
 
</extension>
 
</source>
 
</source>
The attribute <code>category</code> gives the collector a unique name. This is because the same class implementing a collector can be used for different purposes. The attribute <code>maxItems</code> defines the maximum number of logged items that shall be kept within the local store. The attribute <code>class</code> defines the collector class and contains additional configuration settings. These settings are collector specific.<br>
+
The attribute <code>category</code> gives the collector a unique name. This is because the same class implementing a collector can be used for different purposes. The attribute <code>maxItems</code> defines the maximum number of logged items that shall be kept within the local store. The attribute <code>class</code> defines the collector class and contains additional configuration settings. These settings are collector-specific.
In the example above there are two required ''parameters'' <code>collectRange</code> and <code>triggerRange</code>. Both ''parameters'' are of type ''range''. A range defines a set of integers (see <code>org.eclipse.riena.monitor.client.Range</code>), e.g.
+
 
* 1..3 - is a interval containing 1, 2 and 3
+
In the example above there are two ''parameters'' <code>collectRange</code> (or ''filterClass'' see below) and <code>triggerRange</code>. Both ''parameters'' are of type ''range''. A range defines a set of integers (see <code>org.eclipse.riena.monitor.client.Range</code>), e.g.
* 1,2 - are simply the values 1 and 2
+
* <code>1..3</code>
* 1..3, 5,7 - is a interval containing 1, 2, 3, 5 and 7
+
: is a interval containing 1, 2 and 3
 +
* <code>1,2</code>
 +
: are simply the values 1 and 2
 +
* <code>1..3, 5,7</code>
 +
: is a interval containing 1, 2, 3, 5 and 7
 
These integers are the log levels defined by <code>org.osgi.service.log.LogService</code>. So, for the above defined <code>LogServiceCollector</code> this means collect (''collectRange'') all logs that are ''INFO'' (3), ''WARNING'' (2) or ''ERROR'' (1) and trigger transmission (''triggerRange'') on ''WARNING'' (2) or ''ERROR'' (1).
 
These integers are the log levels defined by <code>org.osgi.service.log.LogService</code>. So, for the above defined <code>LogServiceCollector</code> this means collect (''collectRange'') all logs that are ''INFO'' (3), ''WARNING'' (2) or ''ERROR'' (1) and trigger transmission (''triggerRange'') on ''WARNING'' (2) or ''ERROR'' (1).
  
With the configuration capabilities of the <code>LogServiceCollector</code> it also possible to define another collector that listens to custom log levels, i.e. application specific log levels, e.g.
+
The optional ''parameter'' <code>async</code> allows to attach the <code>LogServiceCollector</code> either synchronously or asynchronously. The default is asynchronously. The advantage of attaching synchronously is that the <code>LogServiceCollector</code> can access thread information.
 +
 
 +
With the configuration capabilities of the <code>LogServiceCollector</code> it also possible to define another collector that listens to custom log levels, i.e. application-specific log levels, e.g.
 +
<source lang="xml">
 +
<extension point="org.eclipse.riena.monitor.collectors">
 +
<collector
 +
category="CustomCollector"
 +
maxItems="250"
 +
class="org.eclipse.riena.monitor.client.LogServiceCollector: collectRange=-2..0; triggerRange=-2">
 +
</collector>
 +
</extension>
 +
</source>
 +
 
 +
The filtering possibilities with the ''collectRange'' are very limited. If a more fine grained filtering is required it is possible to define a ''filter'', e.g.
 +
 
 
<source lang="xml">
 
<source lang="xml">
 
<extension point="org.eclipse.riena.monitor.collectors">
 
<extension point="org.eclipse.riena.monitor.collectors">
    <collector
+
<collector
        category="CustomCollector"
+
category="LogCollector"
        maxItems="250">
+
maxItems="50"
        class="org.eclipse.riena.monitor.client.LogServiceCollector: collectRange=-2..0; triggerRange=-2"
+
class="org.eclipse.riena.monitor.client.LogServiceCollector: triggerRange=1, 2; async=false; filterClass=org.eclipse.riena.example.client.monitor.LogServiceCollectorFilter">
    </collector>
+
</collector>
 
</extension>
 
</extension>
 
</source>
 
</source>
 +
The ''filterClass'' attribute defines a class implementing ''ILogServiceCollectorFilter''.
 +
If this attribute is given the ''collectRange'' is no longer required. However, it can still be used and it is evaluated before the filter.
  
==== Aggregator ====
+
=== Aggregator ===
The aggregator <code>org.eclipse.riena.internal.monitor.client.Aggregator</code> is implemented as a OSGi service and responsible for
+
The aggregator <code>org.eclipse.riena.internal.monitor.client.Aggregator</code> is implemented as an OSGi service and responsible for
 
* the configuration of the client monitoring, e.g. evaluating the extensions (collector, store and sender)
 
* the configuration of the client monitoring, e.g. evaluating the extensions (collector, store and sender)
 
* life cycle
 
* life cycle
Line 68: Line 97:
 
* and delegating tasks to the store and the sender
 
* and delegating tasks to the store and the sender
 
The aggregator is not meant to be replaced by custom implementations.
 
The aggregator is not meant to be replaced by custom implementations.
==== Store ====
+
 
 +
=== Store ===
 
There is already a simple store implementation <code>org.eclipse.riena.internal.monitor.client.SimpleStore</code> that stores the collected items within compressed and encrypted files.
 
There is already a simple store implementation <code>org.eclipse.riena.internal.monitor.client.SimpleStore</code> that stores the collected items within compressed and encrypted files.
 
This simple store gets configured with:
 
This simple store gets configured with:
 
<source lang="xml">
 
<source lang="xml">
extension point="org.eclipse.riena.monitor.store">
+
<extension point="org.eclipse.riena.monitor.store">
  <store
+
<store
        name="SimpleStore"
+
name="SimpleStore"
        class="org.eclipse.riena.monitor.client.SimpleStore:cleanupDelay=1 h">
+
class="org.eclipse.riena.monitor.client.SimpleStore:cleanupDelay=1 h">
  </store>
+
</store>
 
</extension>
 
</extension>
 
</source>
 
</source>
This simple store performs cleanups (i.e. removable of transmitted items) within given periods defined by the <code>cleanupDelay</code> property. This period is defined with a simple syntax that does not allow fractions but allows to use time units, e.g. 1 h 30 m 20 s 3 ms.
+
This simple store performs cleanups (i.e. removable of transmitted items) within given periods defined by the <code>cleanupDelay</code> property. This period is defined with a simple syntax that does not allow fractions but allows to use time units, e.g. <code>1 h 30 m 20 s 3 ms</code>.
 +
 
 
It is of course possible to define another store implementation with this extension point. The store just has to implement <code>org.eclipse.riena.monitor.client.IStore</code>.
 
It is of course possible to define another store implementation with this extension point. The store just has to implement <code>org.eclipse.riena.monitor.client.IStore</code>.
==== Sender ====
+
 
Same as with the store there is also a simple sender implementation <code>org.eclipse.riena.monitor.client.SimpleSender</code>. This implementation expects that an OSGi service for the interface <code>org.eclipse.riena.monitor.common.IReceiver</code> exists. This service is than used for transferring the items to the receiver. Within Riena the receiver is usually a server component and the service is a remote service that has been made accessible with Riena communications (see Riena communications how to do that).
+
=== Sender ===
 +
Same as with the store, there is also a simple sender implementation <code>org.eclipse.riena.monitor.client.SimpleSender</code>. This implementation expects that an OSGi service for the interface <code>org.eclipse.riena.monitor.common.IReceiver</code> exists. This service is then used for transferring the items to the receiver. Within Riena the receiver is usually a server component and the service is a remote service that has been made accessible with Riena communications (see [[Riena_Getting_started_remoteservices|Riena Remote Services]] for how to do that).
 +
 
 
The sender has to be configured like this:
 
The sender has to be configured like this:
 
<source lang="xml">
 
<source lang="xml">
extension point="org.eclipse.riena.monitor.sender">
+
<extension point="org.eclipse.riena.monitor.sender">
  <sender
+
<sender
        name="SimpleSender"
+
name="SimpleSender"
        class="org.eclipse.riena.monitor.client.SimpleSender:retryTime=20 m">
+
class="org.eclipse.riena.monitor.client.SimpleSender:retryTime=20 m">
  </sender>
+
</sender>
 
</extension>
 
</extension>
 
</source>
 
</source>
 
The simple sender can be configured with a <code>retryTime</code> property. This time specifies the duration between retries when sending has failed. The syntax for the <code>retryTime</code> is the same as for the <code>cleanupDelay</code> of the store.
 
The simple sender can be configured with a <code>retryTime</code> property. This time specifies the duration between retries when sending has failed. The syntax for the <code>retryTime</code> is the same as for the <code>cleanupDelay</code> of the store.
==== Receiver ====
 
The receiver is usually a server component that is exposed to the client as a Riena remote service. There is (yet) no ready to use simple receiver because it is too dependent on the customers use case. I.e. what should happen with the transmitted items? Should they be stored in a database or in the file system? Should administrators be notified when certain patterns occur? And, and ...
 
To register the receiver on the client you need something like that:
 
<source lang="java">
 
new RemoteServiceFactory().createAndRegisterProxy(IReceiver.class, "http://localhost:8080/hessian/CollectibleReceiverWS", PROTOCOL_HESSIAN, context);
 
</source>
 
While on the server there needs to be something like this to publish the service:
 
<source lang="java">
 
Hashtable<String, String> properties = new Hashtable<String, String>(3);
 
  
properties.put(RSDPublisherProperties.PROP_IS_REMOTE, Boolean.TRUE.toString());
+
=== Receiver  ===
properties.put(RSDPublisherProperties.PROP_REMOTE_PROTOCOL, REMOTE_PROTOCOL_HESSIAN);
+
properties.put(RSDPublisherProperties.PROP_REMOTE_PATH, "/CollectibleReceiverWS");
+
  
IReceiver monitoringReceiver = new SimpleMonitoringReceiver();
+
The receiver is usually a server component that is exposed to the client as a Riena remote service. There is no ready-to-use simple receiver (yet), because it is too dependent on the customer's individual use case. I.e. what should happen with the transmitted items? Should they be stored in a database or in the file system? Should administrators be notified when certain patterns occur? And, and, and ...
  
context.registerService(IReceiver.class.getName(), monitoringReceiver, properties);
+
To register the receiver on the client you need something like that: <source lang="java">
 +
Register.remoteProxy(IReceiver.class)
 +
.usingUrl("http://localhost:8080/hessian/CollectibleReceiverWS")
 +
.withProtocol("hessian")
 +
.andStart(context);
 +
</source> While on the server there needs to be something like this to register and publish the service: <source lang="java">
 +
IReceiver monitoringReceiver = new SimpleMonitoringReceiver();
 +
context.registerService(IReceiver.class.getName(), monitoringReceiver, null);
 +
Publish.service(IReceiver.class)
 +
.usingPath("/CollectibleReceiverWS")
 +
.withProtocol("hessian")
 +
.andStart(context);
 
</source>
 
</source>
=== Wrap up ===
+
 
 +
=== Client information provider  ===
 +
 
 +
Sometimes it is useful to know more about the creator of the collected information, e.g. its host name or IP address. To provide the client monitoring with this information it is necessary to define a <code>org.eclipse.riena.monitor.client.IClientInfoProvider</code> which  does exactly that. The information gathered from that provider enriches the collected data and will be transferred to the server along with it.
 +
 
 +
There is already a configurable <code>org.eclipse.riena.monitor.client.SimpleClientInfoProvider</code>, which is capable of gathering Java system properties plus a few more special properties. You need to define something like this: <source lang="xml">
 +
<extension point="org.eclipse.riena.monitor.clientinfoprovider">
 +
<clientInfoProvider
 +
name="SimpleClientInfoProvider"
 +
class="org.eclipse.riena.monitor.client.SimpleClientInfoProvider:user.name,x-host.name">
 +
</clientInfoProvider>
 +
</extension>
 +
</source> In this example there are two properties: "user.name" and "x-host.name". This configuration will gather the Java system property "user.name" and the ''synthetic'' property "x-host.name" which resolves to <code>InetAddress.getLocalHost().getHostName()</code>. This results into a client information like this: '''user.name=sliebig,x-host.name=pc4723489'''
 +
 
 +
Currently there are three ''synthetic'' properties:
 +
 
 +
; x-host.address : retrieves the host's ip address as given by <code>InetAddress.getLocalHost().getHostAddress()</code>
 +
; x-host.name : retrieves the host's name as given by <code>InetAddress.getLocalHost().getHostName()</code>
 +
; x-host.canonicalname : retrieves the host's canonical name as given by <code>InetAddress.getLocalHost().getCanonicalHostName()</code>
 +
 
 +
And of course it's possible to write your own <code>org.eclipse.riena.monitor.client.IClientInfoProvider</code>.
 +
 
 +
== Wrap-up ==
 
Integrating client monitoring is simple:
 
Integrating client monitoring is simple:
 
* add the '''common''' bundle to both the client and the server
 
* add the '''common''' bundle to both the client and the server
* configure the collectors, the store and the sender on the client
+
* configure the collectors, the store, the sender and maybe an client information provider on the client
 
* create a receiver on the server and register it as a remote service on the client
 
* create a receiver on the server and register it as a remote service on the client
  

Latest revision as of 03:42, 8 July 2011

{{#eclipseproject:rt.riena}}

Riena ProjectGetting Started ▶ Client Monitoring

We know now that in the early years of the twentieth century this world was being watched closely by intelligences greater than man's, and yet as mortal as his own. We know now that as human beings busied themselves about their various concerns they were scrutinized and studied, perhaps almost as narrowly as a man with a microscope might scrutinize the transient creatures that swarm and multiply in a drop of water. With infinite complacence people went to and fro over the earth about their little affairs, serene in the assurance of their dominion over this small, spinning fragment of solar driftwood which, by chance or design, man has inherited out of the dark mystery of Time and Space. Yet across an immense ethereal gulf, minds that are to our minds as ours are to the beasts in the jungle, intellects vast, cool and unsympathetic, regarded this earth with envious eyes and slowly and surely drew their plans against us. ...

Orson Welles, 1938, from the original script of the radio adaption of "War of the Worlds" by H.G. Wells
(http://www.sacred-texts.com/ufo/mars/wow.htm)

Oh, no, stop! No, that's of course NOT the intent of Client Monitoring.

Use Case

The problem that we want to help solving with Client Monitoring is to automatically provide the operators of business applications with measurements about the health and/or usage of a system. With this information a system can be optimized (e.g. bugs fixed, user interface improved, etc.) before the user of the system stumbles upon these issues.

Furthermore the automatically provided information can be much more precise than bug reports entered by the user - can because the developers of the application are now responsible for providing the necessary information, not the user. Remember the targeted user of a Riena application is not a developer.

Possible kinds of measurements:

  • logging data, e.g. certain events produced by Eclipse's LogService
  • usage data
    • more technical, e.g. bundle state change
    • user interface usage tracking
    • tracking of application function usage
  • ..

Components

The Client Monitoring requires two bundles:

org.eclipse.riena.monitor.common
containing classes and interfaces that are common to both client and server side of the application. This is a necessity when using Riena's communication
org.eclipse.riena.monitor.client
containing the aliens - ehm - no, the workhorses

The structure of Client Monitoring is quite simple. There are a bunch of collectors gathering the required information and passing them to the aggregator. The aggregator puts this information in a store and activates the sender. The sender transmits the information to the receiver which is usually a Riena remote service. Activation of the sender is usually triggered by the collectors but can also triggered by any other component.

Riena Cient Monitoring Components.PNG

Collectors

Collectors gather the information that should be transferred to the server. They have to either implement the interface org.eclipse.riena.monitor.client.ICollector or extend org.eclipse.riena.monitor.client.AbstractCollector - extending the AbstractCollector is easier. There are already a few ready-to-use collectors, e.g the LogServiceCollector. All collectors have to be defined with the extension point org.eclipse.riena.monitor.collectors.

LogServiceCollector

Obviously the LogServiceCollector listens to log service events and records them. It has to be defined with something like that:

<extension point="org.eclipse.riena.monitor.collectors">
	<collector
		category="LogCollector"
		maxItems="50"
		class="org.eclipse.riena.monitor.client.LogServiceCollector: collectRange=1..3; triggerRange=1, 2; async=false">
	</collector>
</extension>

The attribute category gives the collector a unique name. This is because the same class implementing a collector can be used for different purposes. The attribute maxItems defines the maximum number of logged items that shall be kept within the local store. The attribute class defines the collector class and contains additional configuration settings. These settings are collector-specific.

In the example above there are two parameters collectRange (or filterClass see below) and triggerRange. Both parameters are of type range. A range defines a set of integers (see org.eclipse.riena.monitor.client.Range), e.g.

  • 1..3
is a interval containing 1, 2 and 3
  • 1,2
are simply the values 1 and 2
  • 1..3, 5,7
is a interval containing 1, 2, 3, 5 and 7

These integers are the log levels defined by org.osgi.service.log.LogService. So, for the above defined LogServiceCollector this means collect (collectRange) all logs that are INFO (3), WARNING (2) or ERROR (1) and trigger transmission (triggerRange) on WARNING (2) or ERROR (1).

The optional parameter async allows to attach the LogServiceCollector either synchronously or asynchronously. The default is asynchronously. The advantage of attaching synchronously is that the LogServiceCollector can access thread information.

With the configuration capabilities of the LogServiceCollector it also possible to define another collector that listens to custom log levels, i.e. application-specific log levels, e.g.

<extension point="org.eclipse.riena.monitor.collectors">
	<collector
		category="CustomCollector"
		maxItems="250"
		class="org.eclipse.riena.monitor.client.LogServiceCollector: collectRange=-2..0; triggerRange=-2">
	</collector>
</extension>

The filtering possibilities with the collectRange are very limited. If a more fine grained filtering is required it is possible to define a filter, e.g.

<extension point="org.eclipse.riena.monitor.collectors">
	<collector
		category="LogCollector"
		maxItems="50"
		class="org.eclipse.riena.monitor.client.LogServiceCollector: triggerRange=1, 2; async=false; filterClass=org.eclipse.riena.example.client.monitor.LogServiceCollectorFilter">
	</collector>
</extension>

The filterClass attribute defines a class implementing ILogServiceCollectorFilter. If this attribute is given the collectRange is no longer required. However, it can still be used and it is evaluated before the filter.

Aggregator

The aggregator org.eclipse.riena.internal.monitor.client.Aggregator is implemented as an OSGi service and responsible for

  • the configuration of the client monitoring, e.g. evaluating the extensions (collector, store and sender)
  • life cycle
  • aggregating all the information from the collectors
  • and delegating tasks to the store and the sender

The aggregator is not meant to be replaced by custom implementations.

Store

There is already a simple store implementation org.eclipse.riena.internal.monitor.client.SimpleStore that stores the collected items within compressed and encrypted files. This simple store gets configured with:

<extension point="org.eclipse.riena.monitor.store">
	<store
		name="SimpleStore"
		class="org.eclipse.riena.monitor.client.SimpleStore:cleanupDelay=1 h">
	</store>
</extension>

This simple store performs cleanups (i.e. removable of transmitted items) within given periods defined by the cleanupDelay property. This period is defined with a simple syntax that does not allow fractions but allows to use time units, e.g. 1 h 30 m 20 s 3 ms.

It is of course possible to define another store implementation with this extension point. The store just has to implement org.eclipse.riena.monitor.client.IStore.

Sender

Same as with the store, there is also a simple sender implementation org.eclipse.riena.monitor.client.SimpleSender. This implementation expects that an OSGi service for the interface org.eclipse.riena.monitor.common.IReceiver exists. This service is then used for transferring the items to the receiver. Within Riena the receiver is usually a server component and the service is a remote service that has been made accessible with Riena communications (see Riena Remote Services for how to do that).

The sender has to be configured like this:

<extension point="org.eclipse.riena.monitor.sender">
	<sender
		name="SimpleSender"
		class="org.eclipse.riena.monitor.client.SimpleSender:retryTime=20 m">
	</sender>
</extension>

The simple sender can be configured with a retryTime property. This time specifies the duration between retries when sending has failed. The syntax for the retryTime is the same as for the cleanupDelay of the store.

Receiver

The receiver is usually a server component that is exposed to the client as a Riena remote service. There is no ready-to-use simple receiver (yet), because it is too dependent on the customer's individual use case. I.e. what should happen with the transmitted items? Should they be stored in a database or in the file system? Should administrators be notified when certain patterns occur? And, and, and ...

To register the receiver on the client you need something like that:
Register.remoteProxy(IReceiver.class)
		.usingUrl("http://localhost:8080/hessian/CollectibleReceiverWS")
		.withProtocol("hessian")
		.andStart(context);
While on the server there needs to be something like this to register and publish the service:
IReceiver monitoringReceiver = new SimpleMonitoringReceiver();

context.registerService(IReceiver.class.getName(), monitoringReceiver, null); Publish.service(IReceiver.class) .usingPath("/CollectibleReceiverWS") .withProtocol("hessian")

.andStart(context);

Client information provider

Sometimes it is useful to know more about the creator of the collected information, e.g. its host name or IP address. To provide the client monitoring with this information it is necessary to define a org.eclipse.riena.monitor.client.IClientInfoProvider which does exactly that. The information gathered from that provider enriches the collected data and will be transferred to the server along with it.

There is already a configurable org.eclipse.riena.monitor.client.SimpleClientInfoProvider, which is capable of gathering Java system properties plus a few more special properties. You need to define something like this:
<extension point="org.eclipse.riena.monitor.clientinfoprovider">
	<clientInfoProvider
		name="SimpleClientInfoProvider"
		class="org.eclipse.riena.monitor.client.SimpleClientInfoProvider:user.name,x-host.name">
	</clientInfoProvider>
</extension>
In this example there are two properties: "user.name" and "x-host.name". This configuration will gather the Java system property "user.name" and the synthetic property "x-host.name" which resolves to InetAddress.getLocalHost().getHostName(). This results into a client information like this: user.name=sliebig,x-host.name=pc4723489

Currently there are three synthetic properties:

x-host.address 
retrieves the host's ip address as given by InetAddress.getLocalHost().getHostAddress()
x-host.name 
retrieves the host's name as given by InetAddress.getLocalHost().getHostName()
x-host.canonicalname 
retrieves the host's canonical name as given by InetAddress.getLocalHost().getCanonicalHostName()

And of course it's possible to write your own org.eclipse.riena.monitor.client.IClientInfoProvider.

Wrap-up

Integrating client monitoring is simple:

  • add the common bundle to both the client and the server
  • configure the collectors, the store, the sender and maybe an client information provider on the client
  • create a receiver on the server and register it as a remote service on the client

That's it!

Back to the top