Added description of gcm_daemon

diff --git a/doc/design.xml b/doc/design.xml
index e00046b..a09b579 100644 (file)
--- a/doc/design.xml
+++ b/doc/design.xml
@@ -6,7 +6,7 @@
 <!--
       XML documentation system
       Original author :  Arjen Baart - arjen@andromeda.nl
 <!--
       XML documentation system
       Original author :  Arjen Baart - arjen@andromeda.nl

-      Version         : $Revision: 1.2 $
+      Version         : $Revision: 1.3 $

 
       This document is prepared for XMLDoc. Transform to HTML,
       LaTeX, Postscript or plain text with XMLDoc utilities and
 
       This document is prepared for XMLDoc. Transform to HTML,
       LaTeX, Postscript or plain text with XMLDoc utilities and


@@ -424,6 +424,7 @@ Methods for the <emph>message_buffer</emph> class:
 </itemize>
 </para>
 <subsection>
 </itemize>
 </para>
 <subsection>

+

 <heading>Command arguments</heading>
 
 <para>
 <heading>Command arguments</heading>
 
 <para>


@@ -451,7 +452,92 @@ Use of a neural network to analyze system logs:
 </itemize>
 </para>
 
 </itemize>
 </para>
 

+<header>gcm_daemon</header>
+<para>
+<strong>Gcm_daemon</strong> is the application that process 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.
+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.
+The two applications (gcm_input and gcm_daemon) together are the core of the central system. 
+The application has the following tasks:
+<itemize>
+<item>Processing data into other tables so that easy detection can take place</item>
+<item>Raising notifications based on the available input</item>
+<item>Maintain the status of notifications and changing priority when needed</item>
+<item>Priodically perform checks for alerts that are communicated through the notification-table</item>
+<item>Perform updates on the database when a new version of the software is loaded</item>
+</itemize>
+</para>
+

 </section>
 </section>

+<subsection>
+<header>Performing checks</header>
+<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.
+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
+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.
+As soon as we seek for common ground in the process of identifying problems
+it can be said that all results are based on the log-table
+(as stated in the manifest the log-table is the one and only table were input
+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.
+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
+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>
+</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
+only the results. For that reason intermediate results have to be stored in a
+temporary table for later reuse.
+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
+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,
+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.
+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>
+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.
+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
+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.
+</itemize>
+</subsection>

 
 </chapter>
 
 
 </chapter>