#  requirements.pod: The pre-planning document
#  Copyright (C) 2002  Stanislav Sinyagin
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

# $Id: reqs.0.0.pod,v 1.1.1.1 2010-12-27 00:04:36 ivan Exp $
# Stanislav Sinyagin <ssinyagin@yahoo.com>
#
#

=head1 RRD Framework Requirements Version 0.0

Date: Jul 10 2002

This article defines some principles that a supposedly future
RRD framework should have. The framework should consist of 3
independent subsystems:

=over 4

=item Data Collection

=item Data Monitoring

=item Data Displaying

=back

=head2 Flexible Hierarchical Configuration

Inspired by Cricket hierarchical configuration, we state here that
the configuration should be hierarchical. Child nodes should
inherit the properties from parents.

The format of the configuration files has not to be neccessary
as in Cricket. I'm not sure if it's worth keeping them in a directory
structure representing the hierarchy tree, but it's definitive
that multiple files should be supported.

A good step ahead would be the configuration in XML format.
It is also possible to have a converter from some other formats
(plain text, or an SQL database) into XML which will be consumed by the
framework.

I leave the Data collection uncovered, since all of the existing
RRD frontends do this part already.

=head1 Data Monitoring Principles

At the moment, the only known solution for RRD data monitoring is
Cricket. Its threshold monitoring has certain limitation and drawbacks.
Nevertheless, it may be used as the basis for the ideas in the further
development.

The major idea is to build data monitoring as a part of a bigger RRD
framework, still being the independent part of the whole. The data can come
from many differet sources, from RRDs produced by any of the existing
and future frontends.

=head2 File Naming Flexibility

In most existing RRD frontends, each RRD datafile should be described
individually. This is not very convenient, especially for the cases
when you have several (dozens) files containing one type of data.
(e.g., input traffic per source autonomous system).
Also the files of same type can be created and deleted by their sourcing
frontend, and it would be more convenient not having to change
the monitoring configuration.

Thus, we need a wildcards language which would allow to specify
multiple files and derive the datasource names from thir names.

=head2 Datasource Naming

Each data being monitored (for RRDs, its definition specifies the
E<lt>filename, DS, RRAE<gt> triple) has to have a universal name.
The name can be fully or partly qualified, depending on the
configuration tree. Examples of such data reference follow:

  /Netflow/Exporters/63.2.3.224/if3/bps /* Interface #3 on router 63.2.3.224 */
  /Netflow/Subnets/Dialin/bps   /* Dial-in address pool */
  /* different grouping for the rack temperature in Server Room 1 */
  /Envmon/RackTemp/SR1
  /SR1/Envmon/RackTemp

Name aliasing should allow short or symbolic names for data sources:

  /* Alias for /Netflow/Exporters/63.2.3.224/if3 */
  /Netflow/Upstream/FranceTelecom1

=head2 Monitoring Rules

Data threshold monitoring should be described in a hierarchical
manner.

It would be interesting to have monitoring rules separate from
the data hierarchy. On the other hand, 1) some data sources might need
special and unique monitoring rules; 2) in some cases, several
data sources need to be combined in order to build a threshold rule.
I'm not yet sure how this must be achieved.

=head2 Event Processing

Once the threshold violation occurs, the monitoring system
should produce the alarm event.

Cricket has a good set of ways to report the alarm, and they can be taken
as the basis.

Also what Cricket is really missing, is displaying those data sources
being alarmed. The Monitoring system should produce the instructions
to the Displaying system in order to display the summary of those
data sources which produce alarms within certain time.


=head1 Data Displaying Principles

View profiles should be configured in a hierarchical manner.

Again as with data monitoring, some Views should be configured independently
of the data hierarchy, but also some data should be able to define
specific view profiles.

There should be view profiles of different types:

=over 4

=item *

HTML Framework. Defines the HTML elements that should be displayed around
the graphs. It also should define the child graphs. Also it should define
the controls which would cause the option changes in the child graphs
(e.g., enabling "Show Holt-Winters Boundaries" would produce the
corresponding graph).

=item *

Individual Graph. Defines the way the graph should look. It should
also be capable of displaying an arbitrary number of data sources.
It should have tunable options, like color, size, or time period.

=back

The Displaying system should allow the following ways of viewing:
1) hierarchical browsing, like Cricket; 2) alarm summary display;
3) individual graph display, without HTML surrounding.

The graph images should be cashed and reused whenever possible.
In alarm summary browsing, these images can be generated at the moment
of the event.

=head1 Author

Copyright (c) 2002 Stanislav Sinyagin ssinyagin@yahoo.com
