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

[Jens Rehsack]

Without any further analyze: Please retry using a recent version of libstatgrab.


> Am 27.07.2016 um 19:39 schrieb Moore, John D (Taylor Communications) <john.moore at taylorcommunications.com>:
> 
> 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
> 
> <image003.png>
> 
> 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  |  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; and (2) permanently delete this message from your computer and all servers and other storage devices.
> 
> 
> _______________________________________________
> users mailing list
> users at i-scream.org
> https://lists.i-scream.org/mailman/listinfo/users

--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.i-scream.org/pipermail/users/attachments/20160727/f10434cb/attachment.bin>