Scripting Xsan monitoring

gsullivan318's picture

This is a bash script I wrote for automating notifications for things that Xsan doesn't notify you about by itself. 318 has quite a few Xsan deployments to keep an eye on, and this helps get a quick overview of volume status and latency for them, so we know which ones need a little extra attention.

Lithium and other similar applications can do some of what we're doing here, but this is a quick way to do it without licensing.

Here's what it does:

  1. Grabs volume names by looking at the directories in
    /Library/Filesystems/Xsan/data
  2. Runs cvfsck -nv on the volumes it finds, extracting the Volume Status (Clean or Dirty)
  3. Looks through the volumes' current cvlog for hourly latency summaries from the current day, pulling out sysavg
  4. f the volume is Dirty, or any of the syavg numbers are above a predefined level, sends a notification email

  Options:

   -h

   Prints a usage summary.

   -l [Latency Level]

   Sets your acceptable latency level. Default is 500. You'll probably want to set that higher, especially if you've got a Promise instead of an Xserve RAID.

   -a [email address]

   Specify the address you want to send notifications to. Default is "root@localhost". You'll probably want to change that too.

I created an installer package, that installs both the script and a launch daemon that runs daily at 11 PM. Or you can just grab the script, sans installer.

Comments

3
Moe's picture

Thanks for the script

It seems to work fine
one bug ( or a feature :) I found is that complains if the xsan directories /Library/Filesystems/Xsan/ and /Library/Filesystems/Xsan/data contains .DS_Store files
solution was to remove these files

techychic's picture

Yeah..it's working fine. Thanks for the information, such a great help. Keep it up and more power!

koppenhoefer's picture

hiya...

I haven't played with the script yet.. but I'm worried about all the .DS_Store files we have that will affect it. I can't go around cleaning those up!

Background:
I read that copying files with extended attributes (e.g., resource forks) to an XSan volume causes the creation of AppleDouble files (filename the same but prepended with ._ ) and that this is made transparent to the users.
http://mvgfr-geek.blogspot.com/2007/12/few-random-xsan-tips-and-tricks.html

I've also seen the occasional ._DS_Store file here and there on the XSan filespace. I assume that those were .DS_Store files with resource links causing the creation of ._DS_Store files which when the original .DS_Store file got removed, became orphaned. Who knows. Is this a catastrophe waiting to happen? Should we somehow be housecleaning these?

---
___
find me on Twitter: http://twitter.com/drkosx