1 # requirements.pod: The pre-planning document
2 # Copyright (C) 2002 Stanislav Sinyagin
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.
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.
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.
18 # $Id: reqs.0.0.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $
19 # Stanislav Sinyagin <ssinyagin@yahoo.com>
23 =head1 RRD Framework Requirements Version 0.0
27 This article defines some principles that a supposedly future
28 RRD framework should have. The framework should consist of 3
29 independent subsystems:
41 =head2 Flexible Hierarchical Configuration
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.
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.
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
57 I leave the Data collection uncovered, since all of the existing
58 RRD frontends do this part already.
60 =head1 Data Monitoring Principles
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
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
72 =head2 File Naming Flexibility
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.
82 Thus, we need a wildcards language which would allow to specify
83 multiple files and derive the datasource names from thir names.
85 =head2 Datasource Naming
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:
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 */
98 Name aliasing should allow short or symbolic names for data sources:
100 /* Alias for /Netflow/Exporters/63.2.3.224/if3 */
101 /Netflow/Upstream/FranceTelecom1
103 =head2 Monitoring Rules
105 Data threshold monitoring should be described in a hierarchical
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.
114 =head2 Event Processing
116 Once the threshold violation occurs, the monitoring system
117 should produce the alarm event.
119 Cricket has a good set of ways to report the alarm, and they can be taken
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.
128 =head1 Data Displaying Principles
130 View profiles should be configured in a hierarchical manner.
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.
136 There should be view profiles of different types:
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).
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.
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.
160 The graph images should be cashed and reused whenever possible.
161 In alarm summary browsing, these images can be generated at the moment
166 Copyright (c) 2002 Stanislav Sinyagin ssinyagin@yahoo.com