6 Replies Latest reply on May 13, 2010 10:25 PM by bwicks

    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

        • Re: Alert for percent change for Interface receive and transmit bps

          John,

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

           

          Thanks,

           

          Adam

            • Re: Alert for percent change for Interface receive and transmit bps
              denny.lecompte

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

                • Re: Alert for percent change for Interface receive and transmit bps
                  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?

                    • Re: Alert for percent change for Interface receive and transmit bps
                      denny.lecompte

                      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.

                        • Re: Alert for percent change for Interface receive and transmit bps
                          Simplexity

                          Wow, I posted that request over two years ago from my last job at Netsol and I can't believe there aren't more people who could use something like this.  I understand how it could be difficult to code and not seriously degrade the performance on the NPM, but the data is already in the DB for the historical graphing, so can't the Advanced Alert Engine just compare the last two values?

                          Maybe just wishful thinking :)

                          John

                            • Re: Alert for percent change for Interface receive and transmit bps
                              bwicks

                              I believe we are going to be looking into the same thing -  a interface variance alarm.  Example the rx interface utillization dropped or rose by 10% from the previous poll.    I am going to start by writing a sql query that updates a interface custom property column say to a 1 where an interface is in alarm.  Then will be easy to use the advanced alert engine to send a SNMP trap when interface custom property is "1"