>>>>> "AJ" == Aaron Johnson <[EMAIL PROTECTED]> writes:
AJ> Can you please give a more detailed example of how one would setup
AJ> Stem to do a simple email when a system fails for example?
there are several ways stem could do this. all are fairly simple but i
will describe the primary method using the stem log subsystem. i assume
by system failure, you mean a process exiting (watchdog) but you can
define any exception you want. any form of monitoring can be created
which will trigger exceptions.
so a monitor cell (stem object watching a process, a server, some
resource, etc.) detects a fault. it generates a log entry and injects
it into a logical log. the log entry can contain a severity level, text
label and text data. it is also automatically timestamped and its host
and stem hub (process) are added to it. the entry is submitted to a
logical log (or more than one) that can be local to this process or
remote.
the logical log will have a set of rules and actions configured for
it. rules include such things as comparing the severity level to a fixed
or variable value (these variables are called stem environment and they
can be set from anywhere - more on this later), the label or level can
be matched against a regex (again, fixed or from a variable). multiple
of these rules can be used in boolean combinations. when a set of rules
pass, then the following set of actions will happen to this
entry. actions include forwarding the log entry to another logical log,
sending it via email, calling the write or wall utility, printing it to
stdout/stderr or sending it to any stem cell (object). you can have
multiple distinct sets of boolean rules and actions in a given logical
log. and since a rule can check on a stem env variable, then you can
change the behavior of a rule at runtime very simply. a good example is
a rule which checks a env value and that value is set or cleared by a
stem cron entry. then you could have a given error message go to an
admin's terminal from 9-5 and to his pager and email in other hours.
the best part of this is that monitoring is totally isolated from log
entry transport and also from log entry processing. so you can design
new monitors without worrying about how to handle the entries - that is
done elsewhere and with configurations and not code. most monitoring
systems have poor transport and filtering capabilitied compared to their
monitoring abilities. stem's design makes this all balanced out. monitor
objects only have to focus on their own problem space. the filters and
actions can be designed later and changed easily via configuration or at
runtime.
note, that this works right now and needs NO new coding. it is all done
with configurations, logical log rules and actions. also you can create
custom rules and actions easily too so if the current system is not
powerful enough, you can roll your own and integrate them in without any
major effort. here are example code for rules:
'match_text' => sub { $_[0]->{'text'} =~ /$_[1]/ },
'env_gt_level' => sub { $_[0]->{'level'} < ( $Env{ $_[1] } || 0 ) },
the first runs a match against the text of a log entry. the second sees
if its severity level equals a stem environment variable.
i noticed that i don't have support for a regex that comes from a stem
environment variable. watch closely (new code here):
'match_env_text' => sub { $_[0]->{'text'} =~ /$Env{$_[1]}/ },
done. :) now you could add that log rule to any log configuration. this
is what i mean by a simple and clean API. and that is not a custom rule
either, it is a new generic one that is useful to have but i just
haven't done it yet.
and here are how these rules are configured:
'match_text' => 'nasty error message!',
'env_gt_level' => 'bar_status',
'match_env_text' => 'var_with_regex_in_it',
BTW i may be changing the ordering of the names. env_gt_level will
become level_gt_env since that puts the 'env' part nearest to the actual
env name in the configuration. these are the kind of things i get anal
about and it is early enough to change them without harm. actually i
could easily support both name forms for compatibility.
actions are configured just as simply:
file => 1,
forward => [ 'bar_stdout' ],
that says to write this entry into the log file and also to forward it
to another logical log.
this is all documented on the web site and in the tarball. i see that
aaron has downloaded it already. :)
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
