*_ops metric values

[#1]

Hi,

I use SDK v5.1 to  query a bunch of FAS32{50,70} running OnTAP 8.1.X, what I'm after at this point  is " *_ops " metrics of "perf-object-get-instances-iter-start" object eg total_ops, fcp_ops, iscsi_ops etc.

Here is a discrepancy I observe for "iscsi_ops" :

SDK call output - ~100000
CLI's sysstat output - ~4000

So something is about of factor 2.5 .. does anyone have an idea why?

The SDK doc says "*ops" metrics are of unit type "per_sec", I'd say this is "OPS per sec" in this case, but apparently it's not. Any hints are appreciated.

Cheers,
Vladimir

[#2]

Hi Vladimir,

The SDK typically returns raw values (not a rate).  Check this guide for more info.  If you're still stuck let me know!

Cheers,

Chris Madden

Storage Architect, NetApp EMEA

[#3]

Hi Chris,

Thanks for the tip. Yes, I'm aware about raw values. I'm using derivative function to get "rate" value.

Here is an example of what I get:

[2013-08-07 10:11:41,905] [Thread-1] pathname: storage.ontap.filer-dqs-201.system.system.iscsi_ops, raw value: 13505653235

[2013-08-07 10:12:42,503] [Thread-1] pathname: storage.ontap.filer-dqs-201.system.system.iscsi_ops, raw value: 13505891169

[2013-08-07 10:12:42,641] [Thread-1] key storage.ontap.filer-dqs-201.system.system.iscsi_ops, derivative[key] 87162.6869319, time_delta 2.72976899147, multiplier 1, prettyname iscsi_iops, device filer-dqs-201

So derivative[key] = (13505891169 - 13505653235) / time_delta  = 87162.6869319

But when I run "stats show -i 60 system::iscsi_ops" via CLI on the same filer (I believe it fetches the same counter) I get something like:

Instance iscsi_ops
                /s
  system      6779
  system      5576
  ...

So not even close to the value I got via API call.

And by the way, the document you are referring to is from 2008, I'd think it's outdated by now, is there anything newer than that?

Cheers,
Vladimir

[#4 · Accepted solution]

Hi Vladimir,

Are you sure your time_delta is correct?  In the API response you have a timestamp and details for each instance.  So compare the timestamp values, and the iscsi_ops values, and you get your rate.

I don't see the timestamp values from the API response in your log output, but just using the logger timestamp wouldn't the time_delta be more like 60 (and not 2.7)?

I did a test in my lab (DOT 8.1.3 7-mode) and from CLI, PowerShell na-invoke-sysstat, and ZAPI API all gave consistent results.  We did have bug 444125 whereby we lacked latency reporting for large LUNs (> 2TB LUN size) but I haven't heard of problems with with iops counters.  That said, a bug is always possible.

Regarding the documentation, I'm not aware of any update.  The counter subsystems itself hasn't changed in years...counters, yes, subsystem, no.

Cheers,
Chris Madden
Storage Architect, NetApp EMEA

[#5]

Hey Chris,

> Are you sure your time_delta is correct?  In the API response you  have a timestamp and details for each instance.  So compare the  timestamp values, and the iscsi_ops values, and you get your rate.

I think you've got the point, let me check my routines to measure "time_delta" .. it looks wrong indeed.

Thanks!

Vladimir

[#6]

Hi Chris,

Thanks a lot for helping me out with this =) It was indeed a bug with some of procedures in my script.

Cheers,

Vladimir