* Paul Ebersman <list-log-analysisat_private> [2002-08-20T12:09-0700]: > Those are pretty easy to come up with and alarm on. The tricky part is > noticing *changes* and deciding which changes are worth worrying > about. If I normally get 200 ssh probes an hour and I suddenly go down > to 20, what happened? If the number of incoming HTTP requests triples > in 20 minutes, what happened? Why usually requires a human ("ergh, being /.'ed"). To be notified of changes, facts would need to be logged at small enough time intervals so that something running calculations on the facts could report on the changes over time, and the rate of change. I have not looked at doing this seriously, but I have seen MRTG graphs of a server room whose cooling failed-- they had thresholds set, which triggered the alarm-- but there was a definite curve on the graph before the threshold was hit that should have been warned about. For less dramatic situations, one could set a threshold, and have the calculating agent tell you how long it would be before the threshold is hit at the current rate. This would be better for areas that change slowly (disk space usage, for instance), or in the case of the temperature example where the room might be sneaking up on the threshold due to a partial failure of chilling-- one could see that the temperature slope has been positive for the last N minutes. -- Jeremy Mates http://www.sial.org/ OpenPGP: 0x11C3D628 (4357 1D47 FF78 24BB 0FBF 7AA8 A846 9F86 11C3 D628) _______________________________________________ LogAnalysis mailing list LogAnalysisat_private https://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Tue Aug 20 2002 - 21:54:37 PDT