snmp statistics for 'disk-busy'

[jasonwu]

Hi  There,

Is there anyway to get disk-busy statistics by snmp trap? something like 'disk utilization' by sysstat command .

Thanks and Regards,

Jason

[anthonyfeigl]

Hey Jason,

You can determine disk busy by looking at the sysstat in the following manner.

As you can see below my Disk util hit 27%.  If this number is high (like 80%) than your disks (spindles/aggrs) are getting hammered.

That would be when you would want to look at doing a wafl reallocate or to rebuild the aggr.

I am not sure how to SNMP this, but you could write a script to rsh into the filer and pull the stats regularly and email them to you.

ANTHONYS-FILER> sysstat -s -x 1
CPU   NFS  CIFS  HTTP   Total    Net kB/s   Disk kB/s     Tape kB/s Cache Cache  CP   CP Disk    FCP iSCSI   FCP  kB/s
                                  in   out   read  write  read write   age   hit time  ty util                 in   out
  0%     0     0     0       0     8     0    132      0     0     0   >60  100%   0%  -    6%      0     0     0     0
  0%     0     0     0       0     4     0    128      0     0     0   >60   98%   0%  -    2%      0     0     0     0
  1%     0     0     0       0     4     0      4      0     0     0   >60  100%   0%  -    4%      0     0     0     0
  0%     0     0     0       0     5     0    132      0     0     0   >60  100%   0%  -    7%      0     0     0     0
  0%     0     0     0       0     6     0    128      0     0     0   >60  100%   0%  -    6%      0     0     0     0
  1%     0     0     0       0     5     1    744    684     0     0   >60  100%  30%  T   27%      0     0     0     0
  0%     0     0     0       0     4     0    124      0     0     0   >60  100%   0%  -    4%      0     0     0     0
  0%     0     0     0       0     5     0    128      0     0     0   >60  100%   0%  -    4%      0     0     0     0
  0%     0     0     0       0    12     0    132      0     0     0   >60  100%   0%  -    4%      0     0     0     0
  0%     0     0     0       0     9     0    128      0     0     0   >60  100%   0%  -    5%      0     0     0     0
  0%     0     0     0       0    12     0    128      0     0     0   >60  100%   0%  -    5%      0     0     0     0
  0%     0     0     0       0    12     0    124      0     0     0   >60  100%   0%  -    8%      0     0     0     0
  1%     0     0     0       0     6     0    140      0     0     0   >60  100%   0%  -    6%      0     0     0     0
--
Summary Statistics (   13 samples  1 secs/sample)
CPU   NFS  CIFS  HTTP   Total    Net kB/s   Disk kB/s     Tape kB/s Cache Cache  CP   CP Disk    FCP iSCSI   FCP  kB/s
                                  in   out   read  write  read write   age   hit time  ty util                 in   out
Min
  0%     0     0     0       0     4     0      4      0     0     0   >60   98%   0%  *   2%       0     0     0     0
Avg
  0%     0     0     0       0     7     0    167     52     0     0   >60  100%   2%  *   6%       0     0     0     0
Max
  1%     0     0     0       0    12     1    744    684     0     0   >60  100%  30%  *  27%       0     0     0     0

Hope this helps.

Anthony Feigl

[brianBOFH]

Also, be aware that the disk util% Anthony is referring to above only shows the single most busy disk in the system and should not be used as an authoritative data point.

Capturing a statit during a period of expected load will give you a much better indication of what your disk performance looks like overall.

[ensenda_na]

After loading the MIB in our SNMP trap server I found that all the items for sysStat.cp.xxxxxxx would trap the disk-busy stats. You have to interpret them though.

IE:

.1.3.6.1.4.1.789.1.2.6.7.0 MIB OID = enterprises.netapp.netapp1.sysStat.cp.cpFromCpOps.0. The count on this = 2559

This would technically be the CP TY that = B for back to back CP's

.1.3.6.1.4.1.789.1.2.6.2.0 MIB OID = enterprises.netapp.netapp1.sysStat.cp.cpFromTimerOps.0. The count for this is 4209037

This CP TY would = T

Search for the OID's that contain sysStat in them and you'll find em.