Corrected a few DTD violations
authorarjen <arjen>
Tue, 17 Dec 2002 07:29:38 +0000 (07:29 +0000)
committerarjen <arjen>
Tue, 17 Dec 2002 07:29:38 +0000 (07:29 +0000)
doc/design.xml

index a09b579..505bd03 100644 (file)
@@ -6,7 +6,7 @@
 <!--
       XML documentation system
       Original author :  Arjen Baart - arjen@andromeda.nl
-      Version         : $Revision: 1.3 $
+      Version         : $Revision: 1.4 $
 
       This document is prepared for XMLDoc. Transform to HTML,
       LaTeX, Postscript or plain text with XMLDoc utilities and
@@ -22,9 +22,9 @@
 -->
    <author>Arjen Baart <code>&lt;arjen@andromeda.nl&gt;</code></author>
    <author>Brenno de Winter<code>&lt;brenno@dewinter.com&gt;</code></author>
-   <date>September 10, 2002</date>
+   <date>December 17, 2002</date>
    <docinfo>
-      <infoitem label="Version">0.1</infoitem>
+      <infoitem label="Version">0.2</infoitem>
       <infoitem label="Organization">Andromeda Technology &amp; Automation</infoitem>
       <infoitem label="Organization">De Winter Information Solutions</infoitem>
    </docinfo>
@@ -230,8 +230,8 @@ In case the message is encrypted, it may not be possible to run <strong>gcm_inpu
 in the background, since human intervention is needed to enter the secret key.
 </para>
 <para>
-The primary function of <strong>gcm_input</strong> is to store lines from a client's log files
-into the <emph>log</emph> table.
+The primary function of <strong>gcm_input</strong> is to store lines from a client's
+log files into the <emph>log</emph> table.
 To do this, we need certain information about the client message that is usually not
 in the content of a log file.
 This information includes:
@@ -412,10 +412,11 @@ rewinding to the beginning of the message.
 Methods for the <emph>message_buffer</emph> class:
 
 <itemize>
-<item>message_buffer::message_buffer(istream *in)</item>
+<item>message_buffer::message_buffer(istream *in)
   <para>
   Constructor.
   </para>
+</item>
 <item>bool operator &gt;&gt;(message_buffer &amp;, String &amp;)
 </item>
 <item>message_buffer::rewind()</item>
@@ -442,27 +443,17 @@ Methods for the <emph>message_buffer</emph> class:
 </section>
 
 <section>
-<heading>Design ideas</heading>
-
-<para>
-Use of a neural network to analyze system logs:
-<itemize>
-<item>Classify words</item>
-<item>Classify message based on word classification</item>
-</itemize>
-</para>
-
-<header>gcm_daemon</header>
+<heading>gcm_daemon</heading>
 <para>
-<strong>Gcm_daemon</strong> is the application that process data just
+<strong>Gcm_daemon</strong> is the application that processes data just
 arrived in the database.
 It handles the log-information delivered by <strong>gcm_input</strong>
-in the table <strong>log</strong>-table of the database.
+in the <emph>log</emph> table of the database.
 With the data further storage and classification can be done.
 Where <strong>gcm_input</strong> is a highly versatile application that is
 loaded and ended all the time the daemon is continously available monitoring
 the entire system. Basically the daemon monitors everything that happens
-in the database and executes continous checks and processes all the data.
+in the database and excecutes continous checks and processes all the data.
 The two applications (gcm_input and gcm_daemon) together are the core of the central system. 
 The application has the following tasks:
 <itemize>
@@ -474,17 +465,20 @@ The application has the following tasks:
 </itemize>
 </para>
 
-</section>
 <subsection>
-<header>Performing checks</header>
-<para>One of the most difficult tasks for the daemon is performing the automatic checks.
+<heading>Performing checks</heading>
+
+<para>
+One of the most difficult tasks for the daemon is performing the automatic checks.
 Every check is different and will be made up of several parameters that have to test negative.
-This that makes it hard to define this into software.
+That makes it hard to define this in software.
 Another downside is that some work may be very redundant.
 For that reason a more generic control structure is needed based on the technologies used.
 The logical choice is then to focus on the capabilities in the database and perform
-the job by executing queries.</para>
-<para>Since the system is about detecting problems and issues we build the detection in
+the job by executing queries.
+</para>
+<para>
+Since the system is about detecting problems and issues we build the detection in
 such a way that queries on the database result in 'suspicious' logrecords.
 So called 'innocent' records can be ignored. So if a query gives a result a
 problem is present, if there is no result there isn't a problem.
@@ -494,13 +488,17 @@ it can be said that all results are based on the log-table
 will arrive and stored for later use).
 Furthermore there are two ways of determining if a problem is present: 
 <itemize>
-<item>A single log-record or a group of log-records is within or outside the boundaries set.
+<item>
+A single log-record or a group of log-records is within or outside the boundaries set.
 If it is outside the boundaries the logrecord(s) is/are a potential problem.
 If there are more boundaries set all of these need to be applied.
-Based on fixed data results can be derived.</item>
-<item>A set of records outline a trend that throughout time may turnout
+Based on fixed data results can be derived.
+</item>
+<item>
+A set of records outline a trend that throughout time may turnout
 to be a problem. These type of values are not fixed and directly legible
-but more or less derived data. That data is input for some checks (previous bullet).</item>
+but more or less derived data. That data is input for some checks (previous bullet).
+</item>
 </itemize>
 In both cases a set of queries can be run.
 If there are more queries to be executed the later queries can be executed on
@@ -510,34 +508,58 @@ Saving a session in combination with the found log-records are sufficient.
 This is also true since logrecords are the basis of all derived presences in
 the numerous log_adv_xxx-tables and always have a reference to the log-table. 
 </para>
-<para>Building the checks will thus be nothing more than combining queries
+<para>
+Building the checks will thus be nothing more than combining queries
 and adding a classification to the results of that query.
-If this generic structure is being build properly with a simple (easy to understand) interface,
-many combinations can be made. People having a logic correct idea,
+If this generic structure is being built properly with a simple (easy to understand) interface,
+many combinations can be made. People having a logically correct idea,
 but insufficient skills to program will be able to build checks.
 As a consequence we can offer the interface to the user,
 that in turn can also make particular checks for the environment that is unique to him/her.
 This - of course - doesn't mean that a clear SQL-interface shouldn't be offered.
 </para>
-<para>When ever something happens, that is less than standard a line will be written to the syslogd.
+<para>
+Whenever something happens, that is less than standard a line will be written to the syslogd.
 This will enable users and developpers to trace exactly what happened.
 The gcm_daemon will also log startup and ending so that abrupt endings of the daemon will be detected.
-<subsubsection>
-<header>The initial process</header>
+</para>
+</subsection>
+
+<subsection>
+<heading>The initial process</heading>
 <para>
 When gcm_daemon starts first some basic actions take place that go beyond
 just opening a connection to the database. The following actions also need to take place:
 <itemize>
-<item>Check the database version if it is still the most recent version.
+<item>
+Check the database version if it is still the most recent version.
 The daemon will check the version-number of the database.
 If the database is not the same version as gcm_daemon an update will be performed.
 When the database is up-to-date normal processing will continue.
-<item>If the database reflects that the used version gcm_daemon is less recent than
+</item>
+<item>
+If the database reflects that the used version gcm_daemon is less recent than
 the running version (i.e. a new version has been installed) all records
 in the log-table that weren't recognized before will now be set to unprocessed since
 there is a fair change that they might be recognized this time. This will ensure that no data is lost.
+</item>
 </itemize>
+</para>
+
 </subsection>
+</section>
+
+<section>
+<heading>Design ideas</heading>
+
+<para>
+Use of a neural network to analyze system logs:
+<itemize>
+<item>Classify words</item>
+<item>Classify message based on word classification</item>
+</itemize>
+</para>
+</section>
 
 </chapter>