Hi Dan, On Thu, 12 Jun 2008, Dan Hamilton wrote:
> ... I think we really have two different discussions going on here: > > 1) issues with graph scaling > 2) issue of averaging of historical detail Agreed. > I don't know much about the inner workings of RRDtool, but would it be > possible to have the option of storing peak values rather than average It's possible. Read the man pages for rrdcreate etc. Several times. :) > I haven't played with the email alerts yet myself, but that would help > as well in providing notification of historic problems. Alerts by email are fine if you know in advance to what you will want the email alerts to alert you. I'm talking about looking over the graphs for the past few weeks to see if there's anything that strikes me as out of the ordinary. I think it's fair to say that, with current technology, the human eye is much better at doing that sort of thing than any software. The other day I saw the average RTT for a user's PC go from 200us to 2ms in a step change, and it stayed there. Had I been relying on email alerts configured to notify me of, for example, a high percentage of RTTs somewhere in the hundreds of milliseconds I might not have seen the change and I would have remained unaware of an unplanned and unauthorized hardware change for very much longer. It's difficult to see how I could I set an alert threshold to report this sort of event which would not give a large number of false alarms as the RTTs will routinely go sky-high when machines do nightly backups (high CPU activity) and/or big data transfers (high network activity). Maybe I'll have to go back to some of my old statistics tomes, or dig around in Wikipedia. I feel sure that the characteristics of the type of information that we're all dealing with here have been considered in excruciating detail by great mathematical minds, and that all that is needed is for someone to turn a few equations into Perl. It's just knowing which equations are appropriate, and when. :) > Regarding issue #1: I would love to have some config options to change > the way the graph scaling works: > > 1) the current method, with an arbitrary multiplier (ie, 1.5x median) > 2) scaled to accommodate the highest smoke value > 3) fixed scaling to an arbitrary value > > This way, everyone can display their data in the way that makes the most > sense for them. I modified Smokeping so the graphs have log scales which are adjusted to suit the data. I hard-coded crude but easily altered configuration values in the Perl modules. It would be easy to name these values in a configuration file, but I haven't done that. It does what I need. I'm happy with the graph scales now, so I won't be causing any more trouble here on that score. :) I posted a link to the modified Smokeping.pm here on 12 May 2008. YMMV. It did what?! -- 73, Ged. _______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
