5 Replies Latest reply on Jan 18, 2013 3:56 PM by Jorge Carrizosa

    Universal Device Poller - Counter not working as expected

    rjordan

      I'm trying to create a performance graph to show HTTP connections per second on our F5 LTM appliances. The OID (1.3.6.1.4.1.3375.2.1.1.2.1.56), reports the running total of HTTP requests. The actual value means very little to me since there is no defined time. The running total probably began last time the appliance was rebooted.

       

      I need the ability to get the delta between value of the current poll and the value of the previous poll and then divide by the interval. This would give me the number of requests per interval. I can then use a Transform to convert to requests per second. For example:

      Poll 1 (at 11:00am): 1.3.6.1.4.1.3375.2.1.1.2.1.56 --> 1230000000

      Poll 2:(at 11:02am): 1.3.6.1.4.1.3375.2.1.1.2.1.56 --> 1230360000

      Delta = 1230360000 - 1230000000 = 360000 requests

      360000 requests / 2 minutes = 180000 requests per minute or 3000 requests per second

       

      When I added the poller and checked the data, it showed the actual raw values from my F5 appliances. I thought setting the MIB value type to Counter would report the delta between the values but it doesn't. I played around with the different settings but couldn't find any option that would help. In the documentation, there is a speedometer example under the Counter section:

      As an example, a Counter value corresponds to the value, in miles, returned by a car odometer. To produce results equivalent to a speedometer‑type rate poller, create a clock poller that returns another Counter value, in hours, and then create a poller transform that divides the result of an odometer poller by the result of the clock poller.

       

      Applying that example to my case, I have the value in miles returned by the odometer (total HTTP requests). I have no clue what a clock poller or what the rest of that example means.

       

      Here is a snippet of my poll below:

       

      <CustomPollers version="9.0">

        <CustomPoller UniqueName="sysStatHttpRequests" Description="The total number of HTTP requests." OID="1.3.6.1.4.1.3375.2.1.1.2.1.56" MIB="F5-BIGIP-SYSTEM-MIB:sysStatHttpRequests" SNMPGetType="GetNext" NetObjectPrefix="N" GroupName="F5" PollerType="C" Parser="Counter" IncludeHistory="True" Unit="" TimeUnitId="0" TimeUnitQuantity="0" DefaultDisplayTimeUnitId="0" Formula="" LabelType="" LabelDetail="">

          <Enumerations />

        </CustomPoller>

      </CustomPollers>

        • Re: Universal Device Poller - Counter not working as expected
          JiriPsota

          I did a fast test with the same custom poller as you and the Counter works for me as expected. You have to check the values in database (CustomPollerStatistics.Status) or in chart on web page. In UnDP application we show the polled values, not the difference between two polls.

          • Re: Universal Device Poller - Counter not working as expected
            tdeeves

            You can do this by adding a transform.  Set the polling interval for the OID (myCounter) to some value, for example 10 minutes.  Then add a transform with the same polling interval.  The transform would be something like myCounter/600. This transform should contain the value you want in requests per second.

              • Re: Universal Device Poller - Counter not working as expected
                Jorge Carrizosa

                tdeeves, this doesn't make sense to me. The myCounter value is an aggregate number that keeps increasing over time since the lifetime of a system. If you just divide that value by a time unit it will return a value that is not a rate of change.

                 

                For instance, if myCounter is 1000 minute #1 your transform would make it 1000/60=16.6 items per second. If myCounter in minute #2 goes up to 2000 it means that another 1000 items were added, so the rate of change should still be 16.6 items per minute. But your transform would report 2000/60=33.3 items per second, which is not true. Like rjordan said, we'd need to find the delta (difference) between myCounter at the current poll minus myCounter at the last poll. Only then can you divide by a time unit to find a rate.

                  • Re: Universal Device Poller - Counter not working as expected
                    tdeeves

                    Jorge, you are correct that the values stored in the database are aggregate numbers that increases over time.  But what I found is that the value made available to the transform is in fact the delta of the current and preceding counter values.  So as long as the divisor is equivalent to the polling interval, then the result of the transform will be a rate of change.  In the example I used above, I have the polling interval for the OID set to 10 minutes, so the divisor is 10 * 60 = 600 seconds.

                    • Re: Universal Device Poller - Counter not working as expected
                      Jorge Carrizosa

                      Thanks tdeeves! I think I figured this out now. I confirmed what you said: I saw that the value displayed in the graphs IS the delta between the current and preceding values, but ONLY when selecting "counter" as MIB type. I was confused because rjordan's initial question was that even though he selected "counter" as MIB type, it still didn't give him a delta. I took him at his word, so I didn't even try that option. But it works for me just fine. I'm curious, rjordan, if you're still not seeing deltas when selecting "counter".

                       

                      So the solution I think is to make sure "counter" is the mib type selected, and Orion will by default do the necessary delta calculations. The confusing part is that, as rjordan said, the documentation is completely misleading and confusing. It starts talking about Transforms too early. A Transform is not at all neccesary to get a rate of change (selecting "counter" will do that). A Transform is only needed if one wants to convert an existing rate (as defined by the polling interval) into another unit, as tdeeves suggested.