Is there a more direct hook to kernel stats on HP-UX?

[Ralph Grothe]

Hello,

I am currently writing a couple of Munin plug-ins for our HP-UX boxes,
to have the performance metrics collected and charted centrally.
Whereas this was a straight task for our Linux and Solaris boxes thanks to their beautiful interfaces procfs and kstat,
it is annoyingly circuitious on HP-UX.
Because I know that some of the HP boxes are susceptible to disk I/O hogs I need to get I/O stats, best for the volumes.
The iostat command seems defunct and unreliable on HP-UX.
Besides sorting of hundreds of disks would be a mess.
On our Solaris boxes with VxVM there is a nice tool vxstat that could be used there.
However, since disks are organized in LVM objects on the HP boxes I unfortunately cannot use this tool, and it aborts with IPC error probably because of a not running vxconfigd.
I could produce a temporal extract from the MWA round robin log, but I think this sucks because it's too time consuming and clumsy considering the extra parsing and external storage.
e.g.

# extract -xp -f /tmp/lvsum.xtr,Purge -Z -b +$(date +%x) 14:40
Writing LVOLUME data to file /tmp/lvsum.xtr

Because the Munin agent collects every 5 minutes this also requires additional date juggling because extract doesn't accept epoch seconds as input for -b.

Since we got this MWA stuff there must be a more direct interface to fetch the kernel stats.

Another way would be to set up advisor syntax files and run glance in advisor-only mode.
But this also is too much fuss.

Are there better ways?

Regards
Ralph

[rick jones]

if you are making kstat calls - or are you only running kstat the command? you might look into using the pstat family of calls.

[Ralph Grothe]

Hi Rick,

for the kstat calls I was using the kstat Perl interface.
Because I lack practise system coding in C it would be nice if it could be done scriptically.
Thanks for pointing me to pstat.
In its manpage I discovered a pstat_getlv() call which looks promising.
My problem or restriction is that I haven't got an hpux system at my disposal in my spare time, and tinkering with the C libs would be too time consuming to have it done at work (that's why I prefer Perl for most of the tasks, adhering to the quick'n'dirty principle).
I don't know how much the Linux pstat calls differ, but I doubt, even though they have LVM support integrated in the kernel, that they have something comparable to the hpux pstat_getlv.
Even if, chances are they define different structs or objects.
I really would like to try to integrate the hpux special calls in some Perl module,
and modules like Inline::C have made the task so much easier than messing around with Perl's XS so that they are even now tractable by folks like me.

[James R. Ferguson]

Hi Ralph:

Perhaps you could look at Perl's 'syscall'. While this brings you very close to C, you might be able to make the 'pstat' calls you want and massage the returned data in the manner we like.

There was an intriguing use of just this mechanism in a thread about 15-months ago, here:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=851889

Regards!

...JRF...

[rick jones]

And WRT access to the HP-UX system, there is always http://testdrive.hp.com - I will say though that I'm not sure which of the pstat calls might require root privs and if one can get those on a testdrive system.

New rx1620's are reasonably (well, I suppose that is subjective :) inexpensive and would get you on IA64 (Itanium). Otherwise, a second-hand rx2600 or rx1600 would do nicely. In the PA-RISC space you could go with an rp3XXX, or an old rp24XX/A500 The "four digit" PA-RISC workstations would work for some stuff, but there later versions of the OS might "work" but would not be "supported"

$ cat /home/raj/usenet_replies/supported_spectrum

Supported, known to work -> warm fuzzies all around
Supported, not known to not work -> an HPite may be in trouble
Supported, known to not work -> an HPite is in trouble
Unsupported, known to work -> lucky today, unlucky tomorrow?
Unsupported, not known to not work -> there but for the grace of Turing
Unsupported, known to not work -> no, it was not deliberate ;-)