torrus/doc/devdoc/reqs.0.0.pod

   1 #  requirements.pod: The pre-planning document
   2 #  Copyright (C) 2002  Stanislav Sinyagin
   3 #
   4 #  This program is free software; you can redistribute it and/or modify
   5 #  it under the terms of the GNU General Public License as published by
   6 #  the Free Software Foundation; either version 2 of the License, or
   7 #  (at your option) any later version.
   8 #
   9 #  This program is distributed in the hope that it will be useful,
  10 #  but WITHOUT ANY WARRANTY; without even the implied warranty of
  11 #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  12 #  GNU General Public License for more details.
  13 #
  14 #  You should have received a copy of the GNU General Public License
  15 #  along with this program; if not, write to the Free Software
  16 #  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
  17
  18 # $Id: reqs.0.0.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $
  19 # Stanislav Sinyagin <ssinyagin@yahoo.com>
  20 #
  21 #
  22
  23 =head1 RRD Framework Requirements Version 0.0
  24
  25 Date: Jul 10 2002
  26
  27 This article defines some principles that a supposedly future
  28 RRD framework should have. The framework should consist of 3
  29 independent subsystems:
  30
  31 =over 4
  32
  33 =item Data Collection
  34
  35 =item Data Monitoring
  36
  37 =item Data Displaying
  38
  39 =back
  40
  41 =head2 Flexible Hierarchical Configuration
  42
  43 Inspired by Cricket hierarchical configuration, we state here that
  44 the configuration should be hierarchical. Child nodes should
  45 inherit the properties from parents.
  46
  47 The format of the configuration files has not to be neccessary
  48 as in Cricket. I'm not sure if it's worth keeping them in a directory
  49 structure representing the hierarchy tree, but it's definitive
  50 that multiple files should be supported.
  51
  52 A good step ahead would be the configuration in XML format.
  53 It is also possible to have a converter from some other formats
  54 (plain text, or an SQL database) into XML which will be consumed by the
  55 framework.
  56
  57 I leave the Data collection uncovered, since all of the existing
  58 RRD frontends do this part already.
  59
  60 =head1 Data Monitoring Principles
  61
  62 At the moment, the only known solution for RRD data monitoring is
  63 Cricket. Its threshold monitoring has certain limitation and drawbacks.
  64 Nevertheless, it may be used as the basis for the ideas in the further
  65 development.
  66
  67 The major idea is to build data monitoring as a part of a bigger RRD
  68 framework, still being the independent part of the whole. The data can come
  69 from many differet sources, from RRDs produced by any of the existing
  70 and future frontends.
  71
  72 =head2 File Naming Flexibility
  73
  74 In most existing RRD frontends, each RRD datafile should be described
  75 individually. This is not very convenient, especially for the cases
  76 when you have several (dozens) files containing one type of data.
  77 (e.g., input traffic per source autonomous system).
  78 Also the files of same type can be created and deleted by their sourcing
  79 frontend, and it would be more convenient not having to change
  80 the monitoring configuration.
  81
  82 Thus, we need a wildcards language which would allow to specify
  83 multiple files and derive the datasource names from thir names.
  84
  85 =head2 Datasource Naming
  86
  87 Each data being monitored (for RRDs, its definition specifies the
  88 E<lt>filename, DS, RRAE<gt> triple) has to have a universal name.
  89 The name can be fully or partly qualified, depending on the
  90 configuration tree. Examples of such data reference follow:
  91
  92   /Netflow/Exporters/63.2.3.224/if3/bps /* Interface #3 on router 63.2.3.224 */
  93   /Netflow/Subnets/Dialin/bps   /* Dial-in address pool */
  94   /* different grouping for the rack temperature in Server Room 1 */
  95   /Envmon/RackTemp/SR1
  96   /SR1/Envmon/RackTemp
  97
  98 Name aliasing should allow short or symbolic names for data sources:
  99
 100   /* Alias for /Netflow/Exporters/63.2.3.224/if3 */
 101   /Netflow/Upstream/FranceTelecom1
 102
 103 =head2 Monitoring Rules
 104
 105 Data threshold monitoring should be described in a hierarchical
 106 manner.
 107
 108 It would be interesting to have monitoring rules separate from
 109 the data hierarchy. On the other hand, 1) some data sources might need
 110 special and unique monitoring rules; 2) in some cases, several
 111 data sources need to be combined in order to build a threshold rule.
 112 I'm not yet sure how this must be achieved.
 113
 114 =head2 Event Processing
 115
 116 Once the threshold violation occurs, the monitoring system
 117 should produce the alarm event.
 118
 119 Cricket has a good set of ways to report the alarm, and they can be taken
 120 as the basis.
 121
 122 Also what Cricket is really missing, is displaying those data sources
 123 being alarmed. The Monitoring system should produce the instructions
 124 to the Displaying system in order to display the summary of those
 125 data sources which produce alarms within certain time.
 126
 127
 128 =head1 Data Displaying Principles
 129
 130 View profiles should be configured in a hierarchical manner.
 131
 132 Again as with data monitoring, some Views should be configured independently
 133 of the data hierarchy, but also some data should be able to define
 134 specific view profiles.
 135
 136 There should be view profiles of different types:
 137
 138 =over 4
 139
 140 =item *
 141
 142 HTML Framework. Defines the HTML elements that should be displayed around
 143 the graphs. It also should define the child graphs. Also it should define
 144 the controls which would cause the option changes in the child graphs
 145 (e.g., enabling "Show Holt-Winters Boundaries" would produce the
 146 corresponding graph).
 147
 148 =item *
 149
 150 Individual Graph. Defines the way the graph should look. It should
 151 also be capable of displaying an arbitrary number of data sources.
 152 It should have tunable options, like color, size, or time period.
 153
 154 =back
 155
 156 The Displaying system should allow the following ways of viewing:
 157 1) hierarchical browsing, like Cricket; 2) alarm summary display;
 158 3) individual graph display, without HTML surrounding.
 159
 160 The graph images should be cashed and reused whenever possible.
 161 In alarm summary browsing, these images can be generated at the moment
 162 of the event.
 163
 164 =head1 Author
 165
 166 Copyright (c) 2002 Stanislav Sinyagin ssinyagin@yahoo.com