On 8 Dec 2011, at 00:40, Gregory Sloop wrote: Provided I understand these configs right, you've got: BC> AVERAGE 0.5 1 5040 #1008 5040 minutes of 1 min resolution data. (i.e. 84 hours or 3.5 days) BC> AVERAGE 0.5 12 21600 #4320 BC> MIN 0.5 12 21600 #4320 BC> MAX 0.5 12 21600 #4320 Then the next set is 12 minute steps, and you've got 180 days of 12min data. [These compress the prior 1 min steps by a factor or 1:12. Again, provided I understand correctly. This seems excessive - I'd probably keep 30 - 90 days of 12 min data. But I'm not sure what your goals are - perhaps that 12 minute data is more important than I realize. But I think I should catch most important stuff in 3 days, and after 30 days, the data's not terribly important for higher resolution needs.] BC> AVERAGE 0.5 144 3600 #720 BC> MAX 0.5 144 3600 #720 BC> MIN 0.5 144 3600 #720 Then 360 days of 144 minute (~2.3 hr resolution) data. --- Here's what I do: I keep one minute data too, and I use BC> AVERAGE 0.5 1 4320 #3 days, 60 sec resolution BC> AVERAGE 0.5 10 4320 #30 days at 10 min resolution BC> MIN 0.5 10 4320 # BC> MAX 0.5 10 4320 # [90 days might be better, but I don't often wish for more than 30-60 days] BC> AVERAGE 0.5 144 2400 #400 days at 2 hr resolution BC> MAX 0.5 144 2400 # BC> MIN 0.5 144 2400 # IIRC, this results in about 8.5MB rrd files for each monitored device. This seems like a pretty reasonable file size for me. I just calculated it, and this appears to use roughly 0.77 KB per row of data. [~770KB per 1000 RRD rows or ~1300 rows/MB.] HTH -Greg Hi Greg, Many thanks for this excellent reply. I can't find documentation that answers this question: If I adjust: *** Database *** step = 60 pings = 20 to different values do I have to adjust the # consfn mrhb steps total lines in step with the adjustments made to the step and pings? Thanks Brian |
I don't believe you have to do so. [I'm quite sure about this.]
...and I believe the graph outputs will display the highest resolution data it has available. [I'm not sure what happens if some of the selected data has high-res data and the rest doesn't...]
AFAIK, you only need adjust the RRD aggregation if the history windows for each level of aggregation don't match what you need/want, and/or the total RRD size is larger than you can accept.
[Option: I want high res data to quickly catch [for alerts primarily] high latency or packet loss, so I want 60 second steps. However, once that data is more than a few days old (and usually 12 hours old is good enough) I *could* take a big hit in resolution and feel fine about it. But, since the RRD's aren't so very big anyway - I'm more than willing to burn 8MB or even 20MB per RRD without worrying about it much. So, keeping more history at higher resolutions is just fine for my purposes.]
...and I don't know where I/O would become a problem - I'm running in a VM with MRTG and I'm not seeing any issues with I/O - but I'd guess that with hundreds to thousands of hosts to hit with fping or other probes, and large, high-res histories, then I/O, from writing the RRD data to disk, could become a problem.
I've not read of anyone who's actually hit that wall, but I'd guess it's happened before. [Hello SSD! would be my solution today.]
HTH
-Greg
_______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
