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

Alert for percent change for Interface receive and transmit bps

Trying to use time-of-day for thresholds is not a good method for me to monitor if issues have occured on our high bandwidth interfaces. Our graphs show a nice bell curve during a 24 hr period, but the bandwidth highs and lows decrease during the week. I would like to have the ability to have an Alert that is triggered when the transmit or receive bandwidth increases or decreases by a chosen percentage (e.g. 5%) from one poll to the next.

-John

Find more posts tagged with

Accepted answers

All comments

adam-b

John,

I am trying to do the same. Did you ever find out a way to do this?

Thanks,

Adam

FormerMember

I don't know of any way to make the alert engine alert on this kind of precise change.

qle

Not necessarily in its current form but is there no way to store a prior polled value in order to compare the current polled value to it? Couldn't the database schema be modified to support prior values? Granted, it would increase the size of the database so perhaps a compromise could be made. How about storing the prior values of key statistics such as receive and transmit bps for interfaces and response time for nodes?

FormerMember

Oh, it could be done. As developers often tell me, it's software, you can do anything. But what's the cost? And not just cost in terms development but in terms of performance. So storing prior values is something we might do to solve a bunch of cases.

But even then, this particular scenario seems extra challenging. You're not just saving the IOS version or a serial number, you're trying to keep comparing the latest data point to a rolling value. In the IOS case, we can expand the schema to save the prior data, but to alert on a % change in a value, would we code to this specific case? Or make it more general, providing a way to look at change for any of a number of values? I'm not saying we couldn't do it, or that we won't do it; my reaction is that it smells harder than the average feature. And I don't recall hearing this request before, nor can I find it in our database. So, hard feature + few requests = lower likelihood of getting this into the product any time soon. But if I were to hear more requests, the calculus would change.