Software Development Kit (SDK) and API Discussions
Software Development Kit (SDK) and API Discussions
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
Solved! See The 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
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
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
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
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
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