Posted by Tres
Sun, 20 Apr 2008 00:36:00 GMT
Here’s a little ruby hackery to do convert the output we got here into something like this:
MB total: 2432.0
MB used: 479.6953125
MB free: 1952.3046875
#!/usr/bin/env ruby
require 'optparse'
options = {}
outprint = {}
ot = String
opts = OptionParser.new do |opts|
opts.on("-p X", "--path X", String, "path to partition for host") do |path|
options[:path] = path
end
end
opts.parse!(ARGV)
output = `dumpe2fs -h #{options[:path]}`
output.squeeze!(" ")
output.each do | line |
line.grep(/Block count:/) { | total | outprint[:total_label] ,outprint[:total_data] = total.chomp.split(/\s*\:\s*/) }
line.grep( /Free blocks:/) { | free | outprint[:free_label], outprint[:free_data] = free.chomp.split(/\s*\:\s*/) }
line.grep(/Block size:/) { | size | outprint[:block_size_label], outprint[:block_size_data] = size.chomp.split(/\s*\:\s*/) }
line.grep(/Reserved block count:/) { | reserved | outprint[:reserved_label], outprint[:reserved_data] = reserved.chomp.split(/\s*\:\s*/) }
end
mb_available = ( outprint[:block_size_data].to_f / 1048576 * outprint[:total_data].to_f )
mb_free = ( outprint[:block_size_data].to_f / 1048576 * outprint[:free_data].to_f )
mb_used = ( mb_available.to_f - mb_free.to_f )
puts "MB total: #{mb_available}"
puts "MB used: #{mb_used}"
puts "MB free: #{mb_free}"
The ruby script takes a single argument, the path to the device that is going to be looked at. It can be passed with either a -p or –path.
Posted in Linux, Ruby, Sysadmin, Xen, Development | Tags DomU, memory, monitor, ruby, script, Xen
Posted by Tres
Sat, 12 Apr 2008 11:48:00 GMT
If you’re trying to monitor disk usage in a Xen domU and are using ext3fs formatted filesystems on LVM partitions, you can use dumpe2fs -h to get an idea of the current disk usage in domU from dom0.
[tres blas.phemo.us ~]$ sudo dumpe2fs -h /dev/vol00/xen_root_img
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:
Last mounted on:
Filesystem UUID: d18fab79-7123-4289-bd28-222ec8739874
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 311296
Block count: 622592
Reserved block count: 31129
Free blocks: 336965
Free inodes: 256927
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 151
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Tue Feb 5 18:57:47 2008
Last mount time: Fri Feb 15 14:42:15 2008
Last write time: Fri Feb 15 14:42:15 2008
Mount count: 6
Maximum mount count: 25
Last checked: Tue Feb 5 19:01:06 2008
Check interval: 15552000 (6 months)
Next check after: Sun Aug 3 20:01:06 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 32775
Default directory hash: tea
Directory Hash Seed: d3f9829f-e127-427b-be56-4e840a139ccf
Journal backup: inode blocks
Journal size: 64M
So amongst all of the output, there are three lines that provide the magic: Block count:, Block size: and Free blocks:.
It’s easy enough to grab the three lines and then process them however you need to. This is a link to a ruby script that will check domU disk usage from dom0
Posted in Ruby, Sysadmin, Xen | Tags disk, DomU, monitor, usage
Posted by Tres
Sun, 12 Nov 2006 09:41:00 GMT
OpenBSD has what is truly awesome system sensor integration.
Not only does it “just work” right out of the box, it also works for more hardware monitoring chipsets than any other *nix out there.
You can always check on current sensor status by using sysctl -a | grep sensor. Once you’ve got an idea of what’s being reported by your monitoring chipset, you can use sensorsd as the interface for monitoring.
Not only does sensorsd monitor these items and write to syslog, it can also be set up to run a script if there are problems found.
Example
We’re going to set up monitoring of a couple of different temperatures being monitored on our router. If there’s a problem found, we’ll have the script mail us.
-bash-3.1# sysctl -a | grep Temp
hw.sensors.24=lm2, Temp1, 39.00 degC
hw.sensors.25=lm2, Temp2, 30.50 degC
hw.sensors.26=lm2, Temp3, 33.00 degC
Use the hw.sensors.XX number to delineate the hardware sensor that will be monitored in sensorsd.conf. We want to monitor 24 and 25. On our hardware, 24 is the CPU sensor and 25 is the air intake sensor.
Here’s what /etc/sensorsd.conf looks like:
hw.sensors.24:high=60C:command=/root/scripts/senswarn.sh cpu_temperature %2 high %4
hw.sensors.25:high=32C:command=/root/scripts/senswarn.sh room_temperature %2 high %4
Now, if you check out man sensors.conf, it will give a pretty good explanation of what all this means. In short, what we’re doing is telling sensorsd to run /root/scripts/senswarn.sh if the temperature reaches above the high setting we’ve denoted in the conf file.
Here’s a look at /root/scripts/senswarn.sh
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
notify="me@blas.phemo.us"
hostname=`hostname`
condition=$1
current=$2
tholds=$3
high=$4
low=$5
mailNotification() {
tholdString=$1
message="
This is an automatic message sent because the system monitor found the $condition
is not normal on $hostname.
The current $condition on $hostname is $current.
$tholdString
"
echo "$message" | mail -s "System Monitor Error: $condition on $hostname" $notify
}
if [ $tholds = "high" ]
then
if [ $current -ge $high ]
then
tholdString="The high threshold: $high"
mailNotification "$tholdString"
fi
fi
if [ $tholds = "low" ]
then
if [ $current -le $low ]
then
tholdString="The low threshold: $low"
mailNotification "$tholdString"
fi
fi
if [ $tholds = "both" ]
then
if [ $current -le $low ]
then
tholdString="
The low threshold: $low
The high threshold: $high
"
mailNotification "$tholdString"
fi
if [ $current -ge $high ]
then
tholdString="
The low threshold: $low
The high threshold: $high
"
mailNotification "$tholdString"
fi
fi
We’ve got additional checks in the script itself to verify the temperature is outside the bounds required because we’ve found that at when started, the sensorsd process will send a notification.
Finally, we add a section to rc.local to ensure that sensorsd is started on boot:
if [ -e /etc/sensorsd.conf ]
then
echo -n " sensorsd"; /usr/sbin/sensorsd
fi
Posted in OpenBSD | Tags monitor, temperature