host info scripts?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

host info scripts?

Aaron Bush
Are there any scripts available that poll information from the host/hosts
that the rrd is on.  Such as recording CPU/disk/memory... usage into a rrd?

Aaron Bush
[hidden email]

--
* To unsubscribe from the rrd-users mailing list, send a message with the
  subject: unsubscribe to [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: host info scripts?

Blair Zajac
If you're on a Solaris box, check out Orca at

http://www.geocities.com/~bzking/

Blair


Aaron Bush wrote:

> Are there any scripts available that poll information from the host/hosts
> that the rrd is on.  Such as recording CPU/disk/memory... usage into a rrd?
>
> Aaron Bush
> [hidden email]
>
> --
> * To unsubscribe from the rrd-users mailing list, send a message with the
>   subject: unsubscribe to [hidden email]

bzajac.vcf (308 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: host info scripts?

Blair Zajac
Not yet.  I wish there was a general performance monitoring tool
that could do this.  Probably the closest thing is top, if that
could be modified to provide 5 minute statistics to files, then
Orca could read it.

Do you know of anything else that is pretty widely available on
different OSes?

Blair


Aaron Bush wrote:

>
> I saw this.
> I'm on a Linux box and HPUX.
> Anything in that dept. yet?
>
> Aaron Bush
>
> > If you're on a Solaris box, check out Orca at
> >
> > http://www.geocities.com/~bzking/
> >
> > Blair

bzajac.vcf (311 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: host info scripts?

Honermann Tom A.
In reply to this post by Aaron Bush
2 things:

1st, I've been working on a set of scripts that go out over ssh (could use
rsh) to a host, supplies a shell script to run (fsu, which stands for File
System Utilization) which gets the disk capacity, space in use, space
modified within the last 24 hours, number of files changed within the last
24 hours, etc...brings that info back and throws it into an rrd.  This is
still quite untested.  I am using it on Linux and have tested it (slightly)
on AIX.  Some support for Solaris is in it, but I don't think that currently
works.  If anyone is interested in playing with this, let me know.

2nd, I have it setup to run once a day here (The resolution of the data is
only 24 hours).  There is a problem with it that I am trying to work out
right now however.  The problem is this: rrd stores time in seconds since
Jan 1, 1970 00:00:00 GMT.  My time zone is CST6CDT which is 21600 seconds
behind GMT during CST and 18000 seconds behind GMT during CDT.  Rrd does
this somewhat neat thing of calculating time slots within the rrd by using
the remainder of a division of the number of seconds since the epoch in GMT
time and the update time so that the time stamps are stored in a nice, neat
format rounded to the nearest nice number in terms of the step time
(17:05:00 instead of 17:07:22 when a step of 300 is used).  This works great
until the time step starts getting over 3600 seconds (1 hour).  At this
point, some weird things happen, for example:  I am trying to enter in some
information at midnight every night.  (The scripts I run necessitate it
being done during off hours) so I create my rrd with a step of 86400, and a
start time of Jun 22, 1999 00:00:00 CDT.  (Note the CDT)  Rrd does the
rounding thing to come up with nice times and forces the start time to Jun
21, 1999 19:00:00 GMT.  (Note, these two times are equivalent)  When I try
and graph the results then, the data looks as though it were gathered at
19:00 hours of the day before instead of at midnight.

I'm just realizing right now, that probably the right way for me to fix this
now is to adjust all my time entries for GMT times.  That means always
having to specify what time slot should be used in the script which does the
update, or finding a way to specify an update time relative to GMT.  Doing
this however means that the time stored does not reflect the _actual_ time
the data was taken.

Is anyone else having problems with the step resolution and time zones?  I
suspect that the remainder time stamp tuning trick should be limited in
resolution to hours so as not to interfere with people's differing time
zones.  Comments?


---------------------------------------------------------------
Tom Honermann                  UW Health - UWHC
Systems Analyst                Information Systems
[hidden email]     610 North Whitney Way
Phone: (608) 265-3925          Suite 4200
Fax:   (608) 265-3920          Madison, WI  53705

---------------------------------------------------------------


--
* To unsubscribe from the rrd-users mailing list, send a message with the
  subject: unsubscribe to [hidden email]