documentation/specification/logging.txt

I-Scream Logging System - initial draft
=======================

tdb1, 29/11/2000

This document aims to cover the Logging System in the
i-Scream Central Monitoring System. Two areas will be 
covered, looking at the system from two angles.

  - Monitoring the System (user)
  
  - Utilising the Logging System (developer)


Monitoring the System
=====================

The Central Monitoring Systems provides a configurable 
logging system. A variety of loggers can easily be chosen 
betweeen by simply changing some settings in the system
configuration. The system also provides an extendable 
interface so further logging mechanisms can easily be added. 
This will be covered further later on.

How it works
------------

The system has one central point of logging for the server 
components (not the host or the clients). This functionality 
is provided over a CORBA system, but this is transparent to 
the end user. As each component is started up a request is 
made to the central naming service for the logging system, 
and then log messages can be sent straight to it.

Types of Logging Implementations
--------------------------------

The messages are passed over CORBA into the logging 
component. Here they are formatted with the date and time 
before being output to the final "destination". The system, 
as standard, provides a range of loggers, each with a 
different method of logging. At present this list stands at;

  - Screen Logger (ScreenLogger.class)
    A basic logger that outputs all messages to the console 
    on which the CORE was started up. This is the simplest 
    way of seeing what's happening.
  
  - File Logger (FileLogger.class)
    Similar to the screen logger, except all output is 
    written to a named file. This is better for ongoing 
    logging.
  
  - Multi Logger (MultiLogger.class)
    This logger, at present implements both of the above 
    loggers. It is intended to allow more versatility from 
    the system. It is planned to allow this logger to 
    support as many, or as few, or these loggers as is 
    required.
  
  - Simple GUI Logger (SimpleGUILogger.class)
    A basic GUI logger that just dumps the output to a 
    window on the console machine. Lacks many nice features, 
    such as the window scrolling.
  
  - Swing GUI Logger (SwingGUILogger.class)
    A more advanced version of the above logger, more 
    polished and much nicer to use. Can be made full screen 
    for use on a permanent logging station.

Choosing a Logger
-----------------

Choosing which logger you which to use is simple. In the 
CORE directory there should be a default.properties file. 
This file governs the initial bootstrapping of the server. 
The following two entries are required by the logging 
system.

  uk.ac.ukc.iscream.LoggerClass=ScreenLogger
  uk.ac.ukc.iscream.LoggerClassParam=

The "LoggerClass" entry specifies the name of the logger to 
use. For example, in the above case the ScreenLogger has 
been selected. Note that the .class extension is *not* 
added. This is all that is required to tell the system to 
utilise the ScreenLogger.

The second entry, "LoggerClassParam" is only required by the 
File Logger (and therfore the Multi Logger) to specify which 
file to write to. All the other loggers do not require this 
to be set. However, future loggers may use this, and 
additional parameters, to configure themselves.

Setting a Verbosity Level
-------------------------

The Logging system also provides a range of verbosity 
levels, so the output can be further tailored to suit the 
needs of the end user. The lower numbered levels give only 
the most important messages, whilst high numbers give a lot 
of information only really useful for debugging. These are 
specified as follows;

  FATAL   - (0) Fatal or Critical Errors
  ERROR   - (1) All Errors
  WARNING - (2) Warnings
  SYSMSG  - (3) System Component messages
  SYSINIT - (4) System Component initialisation
  DEBUG   - (5) All debugging messages

The required verbosity setting can be chosen in the 
default.properties configuration file - the same one in 
which the logger was specified above.

The following setting should be setting to one of the 
numbers above. In this case it has been set to maximum 
verbosity, the DEBUG level.

uk.ac.ukc.iscream.Verbosity= 5

What do the loggers not do ?
----------------------------

The loggers only monitor the state of the server. They do 
not monitor activity on either the host or clients, although 
they may well receive information from components intefacing 
with them.

They also do not log anything to do with the actual 
monitoring of hosts, but rather they monitoring the 
"monitoring system". The information provided by the loggers 
is purely for analysing the activity of the Central 
Monitoring System, and for identifying failures within the 
system.


Utilising the Logging System 
============================

To be added;

  - developing loggers
  - utilising a logger in the server


About
=====

This document was written by Tim Bishop [tdb@i-scream.org] for 
use by the team working on a 3rd year Computer Science 
project called "i-scream". More details can be found on the 
project website;

http://www.i-scream.org
Revision:	1.2
Committed:	Sun Aug 1 10:39:55 2004 UTC (20 years, 3 months ago) by tdb
Content type:	text/plain
Branch:	MAIN
CVS Tags:	HEAD
Changes since 1.1:	+2 -2 lines
Log Message:	Catch a lot of old URL's and update them. Also remove a couple of old files that aren't used.
#	User	Rev	Content
1	tdb	1.1	I-Scream Logging System - initial draft
2			=======================
3
4			tdb1, 29/11/2000
5
6			This document aims to cover the Logging System in the
7			i-Scream Central Monitoring System. Two areas will be
8			covered, looking at the system from two angles.
9
10			- Monitoring the System (user)
11
12			- Utilising the Logging System (developer)
13
14
15			Monitoring the System
16			=====================
17
18			The Central Monitoring Systems provides a configurable
19			logging system. A variety of loggers can easily be chosen
20			betweeen by simply changing some settings in the system
21			configuration. The system also provides an extendable
22			interface so further logging mechanisms can easily be added.
23			This will be covered further later on.
24
25			How it works
26			------------
27
28			The system has one central point of logging for the server
29			components (not the host or the clients). This functionality
30			is provided over a CORBA system, but this is transparent to
31			the end user. As each component is started up a request is
32			made to the central naming service for the logging system,
33			and then log messages can be sent straight to it.
34
35			Types of Logging Implementations
36			--------------------------------
37
38			The messages are passed over CORBA into the logging
39			component. Here they are formatted with the date and time
40			before being output to the final "destination". The system,
41			as standard, provides a range of loggers, each with a
42			different method of logging. At present this list stands at;
43
44			- Screen Logger (ScreenLogger.class)
45			A basic logger that outputs all messages to the console
46			on which the CORE was started up. This is the simplest
47			way of seeing what's happening.
48
49			- File Logger (FileLogger.class)
50			Similar to the screen logger, except all output is
51			written to a named file. This is better for ongoing
52			logging.
53
54			- Multi Logger (MultiLogger.class)
55			This logger, at present implements both of the above
56			loggers. It is intended to allow more versatility from
57			the system. It is planned to allow this logger to
58			support as many, or as few, or these loggers as is
59			required.
60
61			- Simple GUI Logger (SimpleGUILogger.class)
62			A basic GUI logger that just dumps the output to a
63			window on the console machine. Lacks many nice features,
64			such as the window scrolling.
65
66			- Swing GUI Logger (SwingGUILogger.class)
67			A more advanced version of the above logger, more
68			polished and much nicer to use. Can be made full screen
69			for use on a permanent logging station.
70
71			Choosing a Logger
72			-----------------
73
74			Choosing which logger you which to use is simple. In the
75			CORE directory there should be a default.properties file.
76			This file governs the initial bootstrapping of the server.
77			The following two entries are required by the logging
78			system.
79
80			uk.ac.ukc.iscream.LoggerClass=ScreenLogger
81			uk.ac.ukc.iscream.LoggerClassParam=
82
83			The "LoggerClass" entry specifies the name of the logger to
84			use. For example, in the above case the ScreenLogger has
85			been selected. Note that the .class extension is not
86			added. This is all that is required to tell the system to
87			utilise the ScreenLogger.
88
89			The second entry, "LoggerClassParam" is only required by the
90			File Logger (and therfore the Multi Logger) to specify which
91			file to write to. All the other loggers do not require this
92			to be set. However, future loggers may use this, and
93			additional parameters, to configure themselves.
94
95			Setting a Verbosity Level
96			-------------------------
97
98			The Logging system also provides a range of verbosity
99			levels, so the output can be further tailored to suit the
100			needs of the end user. The lower numbered levels give only
101			the most important messages, whilst high numbers give a lot
102			of information only really useful for debugging. These are
103			specified as follows;
104
105			FATAL - (0) Fatal or Critical Errors
106			ERROR - (1) All Errors
107			WARNING - (2) Warnings
108			SYSMSG - (3) System Component messages
109			SYSINIT - (4) System Component initialisation
110			DEBUG - (5) All debugging messages
111
112			The required verbosity setting can be chosen in the
113			default.properties configuration file - the same one in
114			which the logger was specified above.
115
116			The following setting should be setting to one of the
117			numbers above. In this case it has been set to maximum
118			verbosity, the DEBUG level.
119
120			uk.ac.ukc.iscream.Verbosity= 5
121
122			What do the loggers not do ?
123			----------------------------
124
125			The loggers only monitor the state of the server. They do
126			not monitor activity on either the host or clients, although
127			they may well receive information from components intefacing
128			with them.
129
130			They also do not log anything to do with the actual
131			monitoring of hosts, but rather they monitoring the
132			"monitoring system". The information provided by the loggers
133			is purely for analysing the activity of the Central
134			Monitoring System, and for identifying failures within the
135			system.
136
137
138			Utilising the Logging System
139			============================
140
141			To be added;
142
143			- developing loggers
144			- utilising a logger in the server
145
146
147			About
148			=====
149
150	tdb	1.2	This document was written by Tim Bishop [tdb@i-scream.org] for
151	tdb	1.1	use by the team working on a 3rd year Computer Science
152			project called "i-scream". More details can be found on the
153			project website;
154
155	tdb	1.2	http://www.i-scream.org