Oh, ok, I think I got it. If you go back two weeks, you can't see hourly data anymore for one day, two weeks ago. I have thought I wanted that before, too. The notion that I might want to see highly granular data for a historical event is why I have set my HQ to store 7 days (max) of detailed data.
However, it does still store a couple peak/avg/low for each day two weeks and further back. To your concern about performance during peak hours, you would have data points showing maximum cpu/mem/etc. Not perfect, but ...
... Personally, I find that if I'm interested in performance at almost at any given time, I'm interested in how the performance compares *in context.* I want to see how last week performed in reference to the week before, and so far today. So in practice, I have actually never desired that kind of granularity, like hourly data from 8AM-8PM this day last month. I never look at it that way, even though I have sometimes thought I would.
In fact, in my previous life, as a dedicated "performance engineer," I developed a strategy for storing detailed data from several proprietary systems in a single MySQL table. It istill used today, and it has perhaps 100 million rows and the index is as big as a data 🙂 Point being, I built that more than 1 or 2 years ago, and I have never written a query to show me 5 minute data points for "2007-06-05 13:05" to "2007-06-05 15:15" 🙂
Now, that's not to say that it wouldn't be cool if HQ had a more easily configured data archive feature, maybe with an option to use Infobright Community Edition (http://www.infobright.org/) for a neat compressed warehouse of the data 🙂 But until I have time to fool with that and an archive of HQ's data... I'll probably set my detailed data range down to 3 or 4 days, just so I have detailed data on Monday for something weird on Friday 🙂
Cheers.
