Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Performance Analysis - Filter for buisness hours

So we are trying to baseline/trend a server with PerfStack, however as I'm looking at my graphs, the Average Memory and CPU are base-lining off hours, (I'm trying to do a 6 month trend), which skews my report to management to be able add more resources to my server. Is there a way to get more granular with showing only 7am-5pm business hours for the past 6 months?

Thanks,

MSFADMIN

Find more posts tagged with

Accepted answers

All comments

mesverrum

Perfstack doesn't include any time filtering capabilities right now, so thats out. You could use a custom chart but unless your company changed your retention settings you wouldn't have anything more granular than hourly data available beyond the detailed retention period, which defaults to 7 days and hourly averages only extend back 30 days, everything back further than that is daily averages which are near useless for this kind of thing.

The way I typically solve problems with the retention periods without making the database giant and killing app performance is to make sure that there is an alert whenever my device crosses the threshold that I'm worried about, for example upon CPU going over critical. Then you could use SQL to write a report against the alert history tables tracking how long that alert was active during business hours, sum those events all up, divide by the total time in my report and get something that says "Server X was above 90% cpu load for 80% of the time during business hours last month." Alert history also only has 30 days retention by default, but I find that extending this table to a year is a LOT more efficient on the db than extending all metrics to the maximum (and detailed stats won't allow you to go above 6 months anyway).

Unfortunately that's all totally custom SQL stuff so it would be hard to present an example for you here, but that's what I do based on dealing with this kind of problem for lots of clients over the years. The other scenario I've seen sometimes is to set up a sort of data warehouse for archiving all your detailed metrics and the just run these long term reports against that, but that's kind of a lot of hassle too and puts a lot of burden on your DBA to manage that thing.