The Assimilation Project  based on Assimilation version 1.1.7.1474836767
cma.monitoring.MonitoringRule Class Reference
Inheritance diagram for cma.monitoring.MonitoringRule:
Collaboration diagram for cma.monitoring.MonitoringRule:

Public Member Functions

def __init__ (self, monitorclass, tuplespec, objclass='service')
 
def tripletuplecheck (self, triplespec)
 
def specmatch (self, context)
 
def constructaction (self, context)
 

Static Public Member Functions

def monobjclass (mtype='service')
 
def ConstructFromString (s, objclass='service')
 
def compute_available_agents (context)
 
def findbestmatch (context, preferlowoverpart=True, objclass='service')
 
def findallmatches (context, objclass='service')
 
def ConstructFromFileName (filename)
 
def load_tree (rootdirname, pattern=r".*\.mrule$", followlinks=False)
 

Data Fields

 monitorclass
 
 objclass
 
 nvpairs
 

Static Public Attributes

int NOMATCH = 0
 
int NEVERMATCH = 1
 
int PARTMATCH = 2
 
int LOWPRIOMATCH = 3
 
int MEDPRIOMATCH = 4
 
int HIGHPRIOMATCH = 5
 
dictionary monitor_objects = {'service': {}, 'host': {}}
 

Detailed Description

Abstract base class for implementing monitoring rules

This particular class implements it for simple regex matching on arbitrary regexes
on fields on ProcessNodes or Drones -- in reality on any set of graph nodes.

The question is how many subclasses should there be?  It's obvious that we need to have
specialized subclasses for Java, Python and other interpreted languages.
What comes to mind to implement first is simple monitoring using LSB scripts.

The reason for doing this is that they don't take any parameters, so all you have to do
is match the pattern and then know what init script name is used for that service on that OS.

It does vary by Linux distribution, for example...
So... (cmd-pattern, arg-pattern, OS-pattern, distro-pattern) see to be the things that
uniquely determine what init script to use to monitor that particular resource type.

The second question that comes to mind is how to connect these rules into a rule
hierarchy.

For example, if the command name matches Java, then invoke the java rules.

If a java rule matches Neo4j, then return the Neo4j monitoring action
    and so on...

Note that for Java, the monitoring rule is likely to match the _last_ argument
    in the argument string...
        arg[-1] - python-style

If it matches python, then match it against the second argument (arg[1])

Definition at line 292 of file monitoring.py.

Constructor & Destructor Documentation

def cma.monitoring.MonitoringRule.__init__ (   self,
  monitorclass,
  tuplespec,
  objclass = 'service' 
)
It is constructed from an list of tuples, each one of which represents
a value expression and a regular expression.  Each value expression
is a specification to a GraphNode 'get' operation - or a more complex GraphNodeExpression.
Each regular expression is a specification of a regex to match against the
corresponding field expression.
By default, all regexes are anchored (implicitly start with ^)
This rule can only apply if all the RegExes match.
NOTE: It can still fail to apply even if the RegExes all match.

Definition at line 333 of file monitoring.py.

Member Function Documentation

def cma.monitoring.MonitoringRule.compute_available_agents (   context)
static
Create a cache of all our available monitoring agents - and return it

Definition at line 527 of file monitoring.py.

def cma.monitoring.MonitoringRule.constructaction (   self,
  context 
)
Return a tuple consisting of a tuple as noted:
    (MonitoringRule.PRIORITYVALUE, MonitorActionArgs, optional-information)
If PRIORITYVALUE is NOMATCH, the MonitorAction will be None -- and vice versa

If PRIORITYVALUE IS PARTMATCH, then more information is needed to determine
exactly how to monitor it.  In this case, the optional-information element
will be present and is a list the names of the fields whose values have to
be supplied in order to monitor this service/host/resource.

If PRIORITYVALUE is LOWPRIOMATCH or HIGHPRIOMATCH, then there is no optional-information
element in the tuple.

A LOWPRIOMATCH method of monitoring is presumed to do a minimal form of monitoring.
A HIGHPRIOMATCH method of monitoring is presumed to do a more complete job of
monitoring - presumably acceptable, and preferred over a LOWPRIOMATCH.
a NEVERMATCH match means that we know about this type of service, and
that it's OK for it to not be monitored.

MonitorActionArgs is a hash table giving the values of the various arguments
that you need to give to the MonitorAction constuctor.  It will always supply
the values of the monitorclass and monitortype argument.  If needed, it will
also supply the values of the provider and arglist arguments.

If PRIORITYVALUE is PARTMATCH, then it will supply an incomplete 'arglist' value.
and optional-information list consists of a list of those arguments whose values
cannot be determined automatically from the given value set.

The caller still needs to come up with these arguments for the MonitorAction constructor
    monitorname - a unique name for this monitoring action
    interval - how often to run this monitoring action
    timeout - what timeout to use before declaring monitoring failure

Not that the implementation in the base class does nothing, and will result in
raising a NotImplementedError exception.

Definition at line 439 of file monitoring.py.

Referenced by cma.monitoring.MonitoringRule.specmatch().

Here is the caller graph for this function:

def cma.monitoring.MonitoringRule.ConstructFromFileName (   filename)
static
Construct a MonitoringRule from a filename parameter.
It will construct the appropriate subclass depending on its input
string.  Note that the input is JSON -- with # comments.

Definition at line 639 of file monitoring.py.

def cma.monitoring.MonitoringRule.ConstructFromString (   s,
  objclass = 'service' 
)
static
Construct a MonitoringRule from a string parameter.
It will construct the appropriate subclass depending on its input
string.  Note that the input is JSON -- with whole-line comments.
A whole line comment has to _begin_ with a #.

Definition at line 478 of file monitoring.py.

def cma.monitoring.MonitoringRule.findallmatches (   context,
  objclass = 'service' 
)
static
We return all possible matches as seen by our complete and wonderful set of
MonitoringRules.

Definition at line 621 of file monitoring.py.

def cma.monitoring.MonitoringRule.findbestmatch (   context,
  preferlowoverpart = True,
  objclass = 'service' 
)
static
Find the best match among the complete collection of MonitoringRules
against this particular set of graph nodes.

Return value
-------------
A tuple of (priority, config-info).  When we can't find anything useful
in the complete set of rules, we return (MonitoringRule.NOMATCH, None)

Parameters
----------
context: ExpressionContext
    The set of graph nodes with relevant attributes.  This is normally the
     ProcessNode being monitored and the Drone the services runs on
preferlowoverpath: Bool
    True if you the caller prefers a LOWPRIOMATCH result over a PARTMATCH result.
    This should be True for automated monitoring and False for possibly manually
    configured monitoring.  The default is to assume that we'd rather
    automated monitoring running now over finding a human to fill in the
    other parameters.

    Of course, we always prefer a HIGHPRIOMATCH monitoring method first
    and a MEDPRIOMATCH if that's not available.

Definition at line 559 of file monitoring.py.

def cma.monitoring.MonitoringRule.load_tree (   rootdirname,
  pattern = r".*\.mrule$",
  followlinks = False 
)
static
Add a set of MonitoringRules to our universe from a directory tree
using the ConstructFromFileName function.
Return: None

Definition at line 651 of file monitoring.py.

def cma.monitoring.MonitoringRule.monobjclass (   mtype = 'service')
static

Definition at line 374 of file monitoring.py.

def cma.monitoring.MonitoringRule.specmatch (   self,
  context 
)
Return a MonitorAction if this rule can be applies in this context (GraphNodes)
Note that the GraphNodes that we're given at the present time are typically expected to be
the Drone node for the node it's running on and the Process node for the process
to be monitored.
We return (MonitoringRule.NOMATCH, None) on no match

Definition at line 404 of file monitoring.py.

References cma.monitoring.MonitoringRule._tuplespec, and cma.monitoring.MonitoringRule.constructaction().

Here is the call graph for this function:

def cma.monitoring.MonitoringRule.tripletuplecheck (   self,
  triplespec 
)

Definition at line 378 of file monitoring.py.

References cma.monitoring.MonitoringRule.nvpairs.

Field Documentation

int cma.monitoring.MonitoringRule.HIGHPRIOMATCH = 5
static

Definition at line 329 of file monitoring.py.

int cma.monitoring.MonitoringRule.LOWPRIOMATCH = 3
static

Definition at line 327 of file monitoring.py.

int cma.monitoring.MonitoringRule.MEDPRIOMATCH = 4
static

Definition at line 328 of file monitoring.py.

dictionary cma.monitoring.MonitoringRule.monitor_objects = {'service': {}, 'host': {}}
static

Definition at line 331 of file monitoring.py.

cma.monitoring.MonitoringRule.monitorclass

Definition at line 346 of file monitoring.py.

int cma.monitoring.MonitoringRule.NEVERMATCH = 1
static

Definition at line 325 of file monitoring.py.

int cma.monitoring.MonitoringRule.NOMATCH = 0
static

Definition at line 324 of file monitoring.py.

cma.monitoring.MonitoringRule.objclass

Definition at line 347 of file monitoring.py.

int cma.monitoring.MonitoringRule.PARTMATCH = 2
static

Definition at line 326 of file monitoring.py.


The documentation for this class was generated from the following file: