[users at i-scream] Possible issue with statgrab version 0.16 & 0.17

Moore, John D (Taylor Communications) john.moore at taylorcommunications.com
Wed Jul 27 18:39:29 BST 2016


I've been using statgrab for a while and recently inherited some
Solaris 10 servers that are global hosts for some virtual zones ..
I am also using Check_MK to monitor but find that these hosts are
timing out more often than not.  When exploring further with truss
I see that ANY option I pass to statgrab seems to be walking the
device trees for some reason .. and I suspect my device trees are
very broken ... there are over 5000 device links in my /dev/dsk
folder (and format shows > 800 disks, no way we are using that many
even with a number of SAN luns, powerpath devices, et cetera...)

But, just wondering *why* does statgrab  wade thru all of these
for anything other than the 'disk' keyword?

const. cpu. disk. general. mem. page. proc. swap. user.

...truss shows same behavior for any arg .. first has to sift thru all
the devices.

(abbreviating output )
# truss statgrab cpu.

[...]

stat("/dev/dsk/c1t5006016139A012D4d39s7", 0xFFBBF208) = 0
readlink("/dev/dsk/c1t5006016139A012D4d39s7", "../../devices/pci at 2,600000/SUNW,emlxs at 0/fp at 0,0/ssd at w5006016139a012d4,27:h", 1024) = 73
stat("/dev/dsk/c3t5006016839A012D4d14s3", 0xFFBBF208) = 0
readlink("/dev/dsk/c3t5006016839A012D4d14s3",

[...]

This takes a good 5 - 10 minutes to get thru before it actually gets to
reporting any cpu stats, by which time the Nagios check has timed out.

I tried upgrading to the latest Solaris package I could find - statgrab 0.17 -
but still does the same thing.

Any ideas?

Regards

[cid:image003.png at 01D1E80C.4C614630]

JOHN MOORE - Sr System Administrator, IT Infrastructure
Taylor Communications
600 Albany Street.  Dayton, OH 45417
Office:   937.221.2699 | Mobile:  937.367-9908
john.moore at taylorcommunications.com<mailto:john.moore at taylorcommunications.com>  |  www.taylorcommunications.com<http://www.taylorcommunications.com/>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
CONFIDENTIALITY NOTICE:  The information contained in this electronic mail transmission may contain privileged communications and/or confidential information intended only for the use of the named recipient(s). If the reader of this information is not the named recipient(s), or the employee or agent of the named recipient(s), you are hereby notified that any dissemination, distribution, copying or use of this information is strictly prohibited. If you received this transmission in error, please: (1) immediately notify us by return electronic transmission at john.moore at taylorcommunications.com<mailto:john.moore at taylorcommunications.com>; and (2) permanently delete this message from your computer and all servers and other storage devices.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.i-scream.org/pipermail/users/attachments/20160727/0e0ddb8d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 4031 bytes
Desc: image003.png
URL: <http://lists.i-scream.org/pipermail/users/attachments/20160727/0e0ddb8d/attachment.png>


More information about the users mailing list