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 (19 years, 8 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.
#	Content
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	This document was written by Tim Bishop [tdb@i-scream.org] for
151	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	http://www.i-scream.org