I have installed and used mon for the past couple of weeks.
The system seems to be tailored for determining if hosts or services have
gone down or back up. I also am interested, however, in using monitors to
capture system information. Specifically, I want to have a common way to
capture events that are not available through the typical sysklogd
infrastructure. What about monitors which watched things like apache logs
for key events (like default.ida errors :>) or using the lm_sensors
(http://www.netroedge.com/~lm78/) package to monitor hardware health.
Before running across mon, i was brainstorming the design of a very similar
package which consisted of a sheduler (very like mon) but also supplied an
interface library so that the monitors all created events which then got
passed up to a separate layer. At this layer the alert scripts would hook
in for the events they are interested in (ex cpu_temp>X degrees). Keeping
the alerts at a logically separated layer would also make it easy for one
to change which alerts handle events while the system is running; add new
alerts for events that aren't currently being handled; or provide a default
alert for non-handled events (ex. log to syslog). Such a layout would also
facilitate asynchronous events (as mentioned in the past weeks) since
monitors can use the library, outside of normal scheduling, to inject
events into the system. This might require some common event format, but i
didn't get that far.
Does anyone see a similar need? That is, a need to get specific
information into a common stream which isn't necessarily binary (yes/no) in
nature.
Do we see mon ever going in this direction? I might be getting trapped by
the format of my original brainstorming; does mon already provide me with
all the capabilities i need? What do you think about a (monitor -> event
stream -> alert) layout as opposed to current the (monitor -> alert)
layout?
I realize that the first line of standard output from the monitor gets
passed to the alerts. I could make a blanket alert which then acted as my
"second layer" spawning off new alerts based upon the nature of the
message. This doesn't seem to be the most elegant design or use of mon.
dave o
