> I think it's a great idea. > I mean it's very valuable information to have the time when a critical value > has been reached. When measuring multiple observables it's even more > interesting to compare the timestamps > I couldn't agree more! Without drifting from RRD's primary focus, I think that the ability to track peak values (accurately as well) can be very valuable. We're having to write custom scripts to track our values, count value occurance frequencies, and then draw ascii histograms to identify which values occur most frequently. This is easy and helpful when there are only a few values that occur frequently, but when the peak values are several hundred or thousand this because difficult to visualize. RRDTool's storage and graphing don't support unsmoothed values, so it would be helpful to atleast track values and times for particular number ranges (i.e. for CPU tracking, we want to see dates/times for all 90-100% occurances, or for bandwidth, any time we go above 1mbit). When you're talking about hundreds of nodes and potentially thousands of services, we start to see that we're tracking potentially millions of frequently occuring values, and this seems redundant to do it outside of rrd.
If we can't get rrdtool to prevent smoothing, it should be able to atleast store precise values of particular events (multiple events, not just a single max), and then tell us a little more about it. This would be invaluable, and help us correlate events across devices, networks, and services! To end this off properly, we have the deepest gratitude for RRDTool and other projects that use it, and have saved countless hours using it over the years. Thank you! Regards, Kevin Kevin Elliott DHAP Digital, Inc -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-users WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
