The monitor class. This is the entity which contains the details of what is to be monitored, how it is to be monitored and what to do if a given condition arises.
Located in /monitor-defs.php (line 805)
Monitor highest priority condition
Address monitor messages come from
Address to email SMS txt messages
Address to email monitor messages
Threshold condition for emailing
Whether to emit a status message to stdout. If true the monitor will emit the current status, plus the message associated with the highest priority (most severe) condition in the monitor. Format will be: 'CRITICAL: some message goes here'.
Local hostname we are running monitor on
True if we are locked via lockfile
Monitor lockfile object
Monitor lockfile path
Monitor highest priority message
Array of monitors which do the work
The name of this monitor instance
Threshold condition for paging
Report staging for email
Schedule of named timeslots for this monitor
Report staging for SMS txt
Condition to stop on. If this condition is defined then we
The current Unix timestamp
Whether to use a lockfile
Create a new monitor object. This is the container for all of the monitors which you can define and use to monitor a complete system.
Add a new monitor. Eg. file_monitor, postgres_monitor etc. This just stuffs the object in an array ready to be checked.
Add a time slot to the schedule. This requires two times as per 24hr clock which define a time interval during the day, and gives it a name. You can define any number of these. Timeslots have to be in HH:MM format, separated by a dash "-", eg: '07:30-11:45'.
Check all monitors. Just iterate through them and raise the conditions
contained in the reports each one returns. After collecting the details, we notify anyone which needs to know. If any condition returned from a check is CRITICAL, then the rule is we stop processing any further checks. Processing is done in order of definition of the monitors added, so put your critical ones first. NOTE: This method always performs a lock() before processing all the monitors, then performs an unlock() at the end.
Iterate through all our monitors, checking in each case. Each monitor will implement its own kind of checking and set its condition afterward.
We also check to see if we have to abort monitor checking on a given monitor condition.
Raise a condition. The single parameter to this method is a monitor object which will have had its check() method called. This contains the resulting condition and any messages to notify.
Sets the threshold at which we will send messages to email & pager.
Any conditions equal or worse than the threshold will be sent if the message is not nullstring.
Control the emission of status and status message associated with the most sever monitor error. The monitor defaults to not doing this so you should call this method without parameters to turn it on.
Set the condition to stop checking monitor on. If this is set to something other than COND_NONE, then the first time a monitor is raised to this condition the checking process is stopped.
Documentation generated by phpDocumentor 1.3.0RC3