Thursday, August 05, 2004
Tracking disk-space usage
One of the themes management is singing these days is better management of our disk-space resources. One of the areas that needs improvement is better tracking of usage trends. In the past disk-quotas have been restrictive enough that we've had the luxury of not having to be day-to-day obsessive over how much space is left on the various volumes.
At OldJob, we didn't have disk-quotas, so we had day-to-day obsession over how much we had. One of my better ideas (I'm proud of this one) was to come up with a perl script that checks the available space of the various volumes, and dumps the data into a database table. This table then has reports run against it to make pretty pictures. Get enough time into the table (like say... 4 years) and you can get some real trending information. This was a VERY valuable tool when it came time for budgets as I was able to say things like:
I have all of two days of stuff in it, so it's hard to look at. But the next step is writing reports. I have one version that looks to do good, but the real test will be running them three months from now when we have much denser data.
At OldJob, we didn't have disk-quotas, so we had day-to-day obsession over how much we had. One of my better ideas (I'm proud of this one) was to come up with a perl script that checks the available space of the various volumes, and dumps the data into a database table. This table then has reports run against it to make pretty pictures. Get enough time into the table (like say... 4 years) and you can get some real trending information. This was a VERY valuable tool when it came time for budgets as I was able to say things like:
See this line here? If this trend continues [draws line] we should hit the roof about 9 months from now. Now, we know that when we start hitting our heads on the roof, the users start to complain; but we can resist that for a few months. So we add a few months here. So we have 12 months until we hit the point where our good rep goes down the tubes. From the looks of things, another 125gb should keep us for 2-3 years. Perhaps we should put that in the budget?Very nice to have that data, and we're not tracking it yet. There are plans to have Zen for Servers do that for us, but that's months away. So yesterday I took out my old script and hacked at it. I had to remove the db-dump module as I don't have a database I can dump so, and replaced it with dumping to a CSV file instead. The conversion took about four hours. Also added was an edit to track only specific volumes, which is needed to track resources in the cluster. So the old script is currently monitoring our Netware disk-usage through this script (which uses SNMP to query, by the way).
I have all of two days of stuff in it, so it's hard to look at. But the next step is writing reports. I have one version that looks to do good, but the real test will be running them three months from now when we have much denser data.
<permalink> posted by riedesg : 12:30 PM
Comments:
<< Home
If you'd like to keep the information in a database, but don't want to deal with installing an actual database, take a look at DBD-SQLLite instead: http://search.cpan.org/~msergeant/DBD-SQLite-1.02/lib/DBD/SQLite.pm - the database is kept in a physical disk file.
I would be interested in seeing your script. We're currently using a combination of Vol_Info from JRB Software, a batch file, and Perl to do our monitoring.
John
I would be interested in seeing your script. We're currently using a combination of Vol_Info from JRB Software, a batch file, and Perl to do our monitoring.
John
<permalink> posted by 
: 1:45 PM
: 1:45 PM
Finding the OID's to query for what I need took some doing, so I feel fine sharing that particular module.
Sub moduleThat's the module in my script that queries the Netware server and drops the data into a CSV file. It takes arguments from above, and still contains some left-overs of the SQL history (just in case I actually get a database to throw it against again).
Post a Comment
Sub moduleThat's the module in my script that queries the Netware server and drops the data into a CSV file. It takes arguments from above, and still contains some left-overs of the SQL history (just in case I actually get a database to throw it against again).
<< Home
