for us snmp does all we need. (mostly freespace, cpu-load for alerts and
together with cricket, we are plotting networktraffic, diskusage,...)
if you want to parse through log files for special events, i have a mon
with which you can do what ever you want (such as grep through a file)
and
the output is written to file and will trigger an alert i'm just
rewriting
it and will then send it to andrew for the contrib section. we're using
it to monitor the status of our drbd-devices on our clusters and grep
through
the syslogs for machine check exceptions.
stefan
David Oleszkiewicz wrote:
>
> 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
--
system engineering +43-1-718-98-80
CUBiT IT Solutions http://www.cubit.at
