/usr/share/doc/lire/dev-manual/ch01.html is in lire-devel-doc 2:2.1.1-2.1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 1. Architecture Overview</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Lire Developer's Manual"><link rel="up" href="pt01.html" title="Part I. Lire Architecture"><link rel="prev" href="pt01.html" title="Part I. Lire Architecture"><link rel="next" href="ch01s02.html" title="Log File Normalisation"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 1. Architecture Overview</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pt01.html">Prev</a> </td><th width="60%" align="center">Part I. <span class="application">Lire</span> Architecture</th><td width="20%" align="right"> <a accesskey="n" href="ch01s02.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 1. Architecture Overview"><div class="titlepage"><div><div><h2 class="title"><a name="chap:overview"></a>Chapter 1. Architecture Overview</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch01.html#sect:design-patterns">Lire's Design Patterns</a></span></dt><dt><span class="section"><a href="ch01s02.html">Log File Normalisation</a></span></dt><dt><span class="section"><a href="ch01s03.html">Log Analysis</a></span></dt><dt><span class="section"><a href="ch01s04.html">Report Generation</a></span></dt><dt><span class="section"><a href="ch01s05.html">Report Formatting and Other Post-Processing</a></span></dt><dt><span class="section"><a href="ch01s06.html">Going Further</a></span></dt></dl></div><p>From a developer's point of view, <span class="application">Lire</span> intends to be the
universal log analysis framework. To this end, it provides a
reliable, complete, framework upon which to build log analysis
and reporting solution. <span class="application">Lire</span>, the tool, is a proof of the
versality and extendability of the framework as it is able to
produce reports for many of the services that run in today's
heterogeneous networks in a variety of output formats.
</p><p>As a framework, <span class="application">Lire</span> is the best choice to replace all
those home-grown scripts developed to produce reports from all
the log files from the little-known products or
custom-developed programs that run on your system. Leveraging
<span class="application">Lire</span> framework will make those scripts a lot more versatile
while not being really more complicated to develop. It will be
easier to add new reports or to support multiple report
formats.
</p><div class="figure"><a name="fig:flow-overview"></a><p class="title"><b>Figure 1.1. Log Processing in the <span class="application">Lire</span>'s Framework</b></p><div class="figure-contents"><div align="center"><img src="flow-overview.png" align="middle" alt="Log Processing in the Lire's Framework"></div></div></div><br class="figure-break"><p>The <span class="application">Lire</span>'s framework divides log analysis in four
different processes. The figure <a class="xref" href="ch01.html#fig:flow-overview" title="Figure 1.1. Log Processing in the Lire's Framework">Figure 1.1, “Log Processing in the <span class="application">Lire</span>'s Framework”</a> shows those four processes:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p title="Log Normalisation"><b>Log Normalisation. </b>The first process normalise logs from different
products into a generic format that can be
shared by all products that have similar
functionality. For example, log files from products as
different as <span class="productname">Apache</span>™ and <span class="productname">Microsoft Internet Information Server</span>™ will be transformed
into an identical format.
</p></li><li class="listitem"><p title="Log Analysis"><b>Log Analysis. </b>In the analysis process, other information is
created, inferred or extracted from the normalised
data. For example, an anlyser in the www superservice
infers the browser used by the client from the
referrer information.
</p></li><li class="listitem"><p title="Report Generation"><b>Report Generation. </b>The third process generates a report from the
normalised and analysed data. This process is done by
a generic report engine that computes the report based
on specifications describing what and how the
information should appear in the report. The report is
generated in a generic XML format.
</p></li><li class="listitem"><p title="Report Post-processing and Formatting"><b>Report Post-processing and Formatting. </b>The last process converts the generic report into
a specific format like ASCII, PDF, HTML but other kind
of post-processing (like charts generation) can also
be accomplished in this stage.
</p></li></ol></div><p>
</p><p>Before going into a more detailed description of each of
these procesesses, we'll introduce some of the common design's
patterns that you'll find throughout the <span class="application">Lire</span>'s framework.
</p><div class="section" title="Lire's Design Patterns"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect:design-patterns"></a>Lire's Design Patterns</h2></div></div></div><p>At the center of each of these processes is an XML based
file format. Having things specified in data files makes it
easier to extend. For example, the reports are built using a
generic report builder which finds the instructions on how
to build the reports in XML files. So this makes it easy to
add new information to a report: you just have to write an
XML file. The fact that there are a lot of tools to process
XML files is also an interesting aspect. For example, emacs
lovers will appreciate the help that its psgml module gives
them in writing report specifications.
</p><p>Another important aspects is that we tried to
interoperate and to build upon other standards while
defining our XML formats . The best illustration of this is
that in all the XML file formats that <span class="application">Lire</span> use, a DocBook
subset is used for all elements related to narrative
descriptions.
</p><p>Another common aspect you'll encounter is that each of
these processes and XML file formats come with an API to
manipulate them, making it easy to add functionalities at
each processing stage. APIs are also a good thing because,
even if in theory an open file format somewhat constitutes
an API, having libraries that provide convenient access to
the file formats makes it a lot easier to write new
components providing new functionalities.
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pt01.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="pt01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch01s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part I. <span class="application">Lire</span> Architecture </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Log File Normalisation</td></tr></table></div></body></html>
|