torrus/doc/devdoc/wd.uptime-mon.pod

   1 #  Copyright (C) 2002  Stanislav Sinyagin
   2 #
   3 #  This program is free software; you can redistribute it and/or modify
   4 #  it under the terms of the GNU General Public License as published by
   5 #  the Free Software Foundation; either version 2 of the License, or
   6 #  (at your option) any later version.
   7 #
   8 #  This program is distributed in the hope that it will be useful,
   9 #  but WITHOUT ANY WARRANTY; without even the implied warranty of
  10 #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  11 #  GNU General Public License for more details.
  12 #
  13 #  You should have received a copy of the GNU General Public License
  14 #  along with this program; if not, write to the Free Software
  15 #  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
  16
  17 # $Id: wd.uptime-mon.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $
  18 # Stanislav Sinyagin <ssinyagin@yahoo.com>
  19 #
  20 #
  21
  22 =head1 RRFW Working Draft: Service uptime monitoring and reporting
  23
  24 Status: in pre-design phase.
  25 Date: Sep 26 2003; Last revised:
  26
  27 =head2 Definitions
  28
  29 It is often required to monitor the service level in networks.
  30 Service level is normally covered by Service Level Agreement (SLA),
  31 which defines the following parameters:
  32
  33 =over 4
  34
  35 =item * Service definition
  36
  37 Describes the particular service in terms of functionality and means of
  38 monitoring. Examples are: IP VPN connectivity, WAN uplink, SQL database engine.
  39
  40 =item * Maintenance window
  41
  42 Describes the periodic time intervals when service outage is possible
  43 due to some maintenance work. It may be unconditional (outage is always
  44 possible within the window), or conditional (customer confirmation required
  45 for outage within the window). Notification period is normally defined
  46 for maintenance outages.
  47 Example: every 1st Tuesday of the month between 6AM and 8 AM, with 96 hours
  48 notification time.
  49
  50 =item * Outage types
  51
  52 Outages may be caused by: 1). system failure; 2). service provider's
  53 infrastructure failure; 3). customer activity.
  54
  55 =item * Service level objectives
  56
  57 These are the guarantees that the sevice provider gives to the customer.
  58 Violation of these guarantees is compensated by penalties defined.
  59
  60 These may include: Maxium maintenance downtime per specified period;
  61 Maximum downtime period due to failures on the service provider side;
  62 Minimum service availability per specified period.
  63
  64 =back
  65
  66
  67 =head2 Event datasource type
  68
  69 In order to store the service level information, we need a new datasource
  70 type in RRFW: I<event>. It represents an atomic information
  71 about a single event in time, e.g. it canot be devided into more specific
  72 elements or sub-events. Its attributes are as follows:
  73
  74 =over 4
  75
  76 =item * Event group name
  77
  78 Several events belong to one and only one group. Event group is a unique
  79 entity that describes the service.
  80
  81 =item * Event name
  82
  83 Unique name within the event group. Describes the type of the event, such as
  84 C<maintenance>, C<downtime>. Events with the same names cannot overlap in
  85 time.
  86
  87 =item * Start time
  88
  89 Timestamp of the event start.
  90
  91 =item * Duration
  92
  93 Positive integer that specifies the length of the event in seconds.
  94 Zero duration means that the event has not yet finished.
  95
  96 =item * Parameters
  97
  98 Event-specific I<(name, value)> pairs.
  99
 100 =back
 101
 102 Events are uniquely identified by I<(Event group, Event name, Start time)>
 103 triple.
 104
 105
 106 =head2 Event summary reports
 107
 108 Renderer should be able to display the events at different summary levels
 109 and in different combinations. Event reports should be specified by
 110 expressions, as follows:
 111
 112 =over 4
 113
 114 =item * Boolean operators
 115
 116 C<downtime AND NOT maintenance>.
 117
 118 =item * Time period
 119
 120 C<(downtime AND NOT maintenance)[-2DAYS,NOW]>
 121
 122 C<(downtime[-2DAYS,NOW] AND NOT maintenance AND
 123 NOT downtime[200309151200,200309151300])>
 124
 125 =item * Arithmetic operations
 126
 127 Sum of durations, substract of durations...
 128
 129 =back
 130
 131 =head2 Events generation
 132
 133 Events may be generated by the following sources:
 134
 135 =over 4
 136
 137 =item * Collector
 138
 139 SNMP collector may create events on some faulty conditions, like host
 140 unreachable, or on SNMP variables change, like interface status.
 141 Also it's possible to create an ICMP Echo collector type,
 142 which would generate events based on pinging the hosts.
 143
 144 =item * Monitor
 145
 146 Obviously, a new monitor action will be to create events.
 147
 148 =item * Human operator
 149
 150 First from commandline interface, and later from thr Web interface,
 151 the human operators may create the scheduled events, like maintenance
 152 outages. Security policy should protect certain types of events
 153 from human intervention.
 154
 155 =back
 156
 157
 158
 159
 160 =head1 Author
 161
 162 Copyright (c) 2003 Stanislav Sinyagin E<lt>ssinyagin@yahoo.comE<gt>