Elektronika 2009-11.pdf - Instytut Systemów Elektronicznych

• information on their state comes from various sources (e.g.:
monitoring systems, emails being sent by maintenance
tasks executed regularly, customers),
• those objects exist on machines connected by network
having complex topology,
• undesired state of specified objects or their combination indicates
problems that must be solved (usually as soon as
possible),
• big number of repairs is conducted manually, while they are
repeatable and it is noticeable that they may be formally
and precisely specified.
Main ideas and terms
The following subsections contain explanation of main ideas
and terms used in the developed solution and introduce unified
naming convention, regarding both of discussed problems:
Monitoring
Analysis of multiple monitoring systems allowed for creating
more general description of monitoring, which can be perceived
as a process of examining states of groups of objects
of any kind, and of informing about any abnormalities. Each
object may assume precisely determined number of, mutually
exclusive, states taking their values from precisely determined
domain. Some values mean the states are correct, while the
other ones mean the object is associated with a problem that
needs resolving.
We may introduce simple method of identification of those
objects, consisting on associating each of them with the complex
variable of precisely determined name. Monitoring becomes
then a process of continuous checking (or observing)
the values of many variables, and of extracting from their
space, those variables that do not fulfill required constraints.
Binding the names of those variables with the real monitored
objects is done in monitoring procedures. Because most of
those objects may be placed in leaves of a tree, representing
hierarchy of the monitored world, it is convenient to create
space of variables with qualified names, resembling directory
structure of hard disk drive, the DNS (Domain Name System
of Internet names), or the MIB tree of SNMP (Simple Net Management
Protocol). Staying with the analogy of directory structure,
objects (so variables) are represented by files, while
directories represent units grouping them.
eclipse.oracle.TESTDB.fs.usage may be, for example,
a variable representing percent usage of filesystem of
machine eclipse, belonging to DBMS (DataBase Management
System) oracle, identified by SID (System IDentifier)
TESTDB. Values of those variables are changeable in time and
frequency of their changes depends on applied monitoring
mechanisms, on frequency of processing by them the data
coming from monitored objects, on stability of their states and
on their character. Sometimes, there is also a need to bind
a state with some details. Summarizing, we may say:
• state of monitored object is represented by a value of complex
variable associated with it,
• each variable has a name, identifying its position in a monitoring
tree unambiguously,
• their values are changeable in time and can be assigned
optional details.
Monitoring is a process of continuous checking (or observing)
the values of variables making up the monitoring tree.
Problem is a situation when one or more variables have undesired
values. Undesired values, so problems, are expressed
by predicates of problem-related variables of the monitoring
tree. Precisely saying, problem is defined as a situation when
any of those predicates is unfulfilled (when it is false), and
a scope of problem is a term referring to a set of problem-related
variables, falsifying the problem-related predicate.
Repair
Each problem, the RMS is able to solve, is associated with
one or more repair procedures and repair is the process of
using those procedures to bring monitored objects back from
undesired states to desired states. Repair is initiated (triggered)
by detecting in the monitoring tree set of such unprocessed
variables, that make up the scope of the problem,
that has been associated with at least one repair procedure.
Repair procedures are interactive algorithms, written in
high-level programming language, using the standard flow
control instructions and taking advantage of other features of
language, they are embedded in. Those algorithms execute,
so called, corrective steps, whose invocations may be perceived
as calls of external routines (procedures or functions).
External routines are well-known programming languages concept
and, like internal ones, they resemble black boxes having
precisely determined interface (getting determined input and
returning determined output) but, unlike internal ones, having
their bodies defined outside the algorithms calling them. In
case of the RMS system, they are exported, before their executions,
to remote machines, related to problems that need
them to be solved, and they are executed on those machines
with access rights of users defined in repair algorithms.
Programmers writing repair procedures may use means
of expressions encapsulated in routines provided by the repair
library (the repair API), and each repair is started up in
environment containing all necessary information on the particular
problem initiating it (and with the use of the repair library,
this information is easily retrievable).
Construction of the RMS
Ideas and considerations drafted in the previous subsections, as
well as existing industrial reality and already employed monitoring
systems, have lead to the following construction of the RMS:
Architecture of the RMS
Architecture of the RMS has been shown in the Figure 1. MON-
JAMI and HVRMONITOR correspond to systems described in
[2,3]. The RMS collects data coming from various sources, initializes
repairs, manages their whole lifecycle and each repair
may assume one of the following states:
• pending: need for repair was detected and appropriate repair
is awaiting its starting up,
• running: repair has been started up and its realization is in
progress,
• suspended: it has been suspended, as it needs additional
information,
• finished: it has been finished (regardless of its result) and
its result has been saved.
Features of the RMS
The most important features of the RMS are the following:
• it starts up subsequent repairs in parallel (not sequentially),
• starting up follows the order requests for repairs are coming
into the repairs queue,
ELEKTRONIKA 11/2009 55