X-Git-Url: http://git.freeside.biz/gitweb/?p=freeside.git;a=blobdiff_plain;f=torrus%2Fdoc%2Fdevdoc%2Fwd.monitor-escalation.pod;fp=torrus%2Fdoc%2Fdevdoc%2Fwd.monitor-escalation.pod;h=3dc59796d010fa43cd85e626885f47c30d629ad9;hp=0000000000000000000000000000000000000000;hb=74e058c8a010ef6feb539248a550d0bb169c1e94;hpb=35359a73152b3d7a9ad5e3d37faf81f6fedb76e8 diff --git a/torrus/doc/devdoc/wd.monitor-escalation.pod b/torrus/doc/devdoc/wd.monitor-escalation.pod new file mode 100644 index 000000000..3dc59796d --- /dev/null +++ b/torrus/doc/devdoc/wd.monitor-escalation.pod @@ -0,0 +1,117 @@ +# 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: wd.monitor-escalation.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $ +# Stanislav Sinyagin +# +# + +=head1 RRFW Working Draft: Monitor escalation levels + +Status: pending implementation. +Date: Nov 5 2003. Last revised: Nov 10 2003 + +=head2 Introduction + +The initial idea comes from Francois Mikus in Cricket development team. +His proposal was to raise the alarm only after several true consecutive +monitor conditions. + +The idea has developed into the concept of escalation levels. + + +=head2 Monitor events + +Current implementation supports four types of monitor events: C, +C, C, and C. New event type will be C. +C designates a symbolic name for a certain escalation level. Each level +is associated with the escalation time interval. + +Given C as the escalation interval, C as the monitor condition age, +and C

as period, the escalation event will occur simultaneously with +one of C events, when the following condition is true: + + Te >= Ta + +New event types C and C will occur at the same +time as C and C respectively, +for each escalated level. + + +=head2 Monitor parameters + +New parameter will be introduced: C. Value will +be a comma-separated list of C parts, where C +designates the escalation level, and C specifies the escalation +interval in seconds. + +Example: + + + + ... + + +Another example would be Cisco TAC style priorities: P3, P2, P1. + + +=head2 Action parameters + +C parameter will be valid not for C actions only, but also +for C actions. New valid values will be C, C, +and C. + +XML configuration validator will not verify if escalation levels in +action definition match those in datasource configuration. + +New optional action parameter: C. Contains an RPN expression +which must be true at the time when the action is allowed to execute. +Two new RPN functions may be used here: C and C. + +C returns the current time of day as integer: C. For example, +830 means 8:30 AM, and 1945 means 7:45 PM. + +C returns the current day of the week as integer between and including +0 and 6, with 0 corresponding to Sunday, 1 to Monday, and 6 to Saturday. + +In this example, the action is allowed between 8 AM and 6 PM from Monday +to Friday: + + + TOD,800,GE, TOD,1800,LE, AND, + DOW,1,GE, AND, + DOW,5,LE, AND + + + +=head2 Implementation + +B database format will change: The values will consist +of five colon-separated fields. The first four fields will be as earilier, +and the fifth one will be a comma-separated list of escalation level names +that have already fired. + +The implementation of this feature is preferred after the planned redesign of +the monitor daemon. The new monitor design would support individual +schedule for each datasource leaf, analogous to collector schedules. + +In turn, the monitor daemon redesign is better to do after +the collector daemon redesign. Then it would allow to keep similar design +and architecture where possible. + +=head1 Author + +Copyright (c) 2003 Stanislav Sinyagin Essinyagin@yahoo.comE