Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Glusterfs, while being a nice distributed filesystem, provides almost no way to monitor it's integrity. Servers can come and go, bricks might get stale or fail and I afraid to know about that when it is probably too late.

Recently we had an strange failure when everything appeared working, but one brick fell out from the volume (found by pure coincidence).

Is there a simple and reliable way (cron script?) that will let me know about health status of my GlusterFS 3.2 volume?

share|improve this question
    
For now we use an dirty shell script based monitoring: check_gluster.sh –  Arie Skliarouk Aug 1 '11 at 16:56
    
Have a look at glfs-health.sh. –  quanta Aug 1 '11 at 17:12
    
I checked the glfs-health.sh and it looks like it is for old versions of glusterfs, which were configuration-file controlled. I will clarify my question to represent glusterfs 3.2. –  Arie Skliarouk Aug 3 '11 at 13:34
add comment

4 Answers

Please check the attached script at http://gluster.org/pipermail/gluster-users/2012-June/010798.html for gluster 3.3; it's probably easily adaptable to gluster 3.2.

share|improve this answer
add comment

This has been a request to the GlusterFS developers for a while now and there is nothing out-of-the-box solution you can use. However, with a few scripts it's not impossible.

Pretty much entire Gluster system is managed by a single gluster command and with a few options, you can write yourself health monitoring scripts. See here for listing info on bricks and volumes -- http://gluster.org/community/documentation/index.php/Gluster_3.2:_Displaying_Volume_Information

To monitor performance, look at this link -- http://gluster.org/community/documentation/index.php/Gluster_3.2:_Monitoring_your_GlusterFS_Workload

UPDATE: Do consider upgrading to http://gluster.org/community/documentation/index.php/About_GlusterFS_3.3

You are always better off with being on the latest release since they seem to have more bug fixes and well supported. Ofcourse, run your own tests before moving to a newer release -- http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ :)

There is an admin guide with specific section for monitoring your GlusterFS 3.3 installation in Chapter 10 -- http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US.pdf

See here for another nagios script -- http://code.google.com/p/glusterfs-status/

share|improve this answer
    
Thanks Chida, I guess what's got me hung up is that some folks (github.com/semiosis/puppet-gluster) are monitoring gluster via the proc table ('--with-brick', etc) and logfiles (egrep ' E ' for error), and some people are using the CLI and I have no idea which is more likely to accurately report gluster's state. –  r_2 Aug 14 '12 at 16:44
    
I'd recommend using the CLI since that's the one GlusterFS recommends and is bound to be up-to-date. –  Chida Aug 14 '12 at 16:51
add comment

There is a nagios plugin available for monitoring. You may have to edit it for your version though.

share|improve this answer
add comment

@Arie Skliarouk, your check_gluster.sh has a typo—on the last line, you grep for exitst instead of exist. I went ahead and rewrote it to be a bit more compact, and to remove the requirement for a temporary file.

#!/bin/bash

# Ensure that all peers are connected
gluster peer status | grep -q Disconnected && echo "Peer disconnected." && exit 1

# Ensure that all bricks have a running log file (i.e., are sending/receiving)
for vol in $(gluster volume info | awk '/Volume Name/ {print $3}'); do
  for brick in $(gluster volume info "$vol" | awk '/^Brick[0-9]*:/ {print $2}'); do
    gluster volume log locate "$vol" "$brick";
  done;
done |
 grep -qE "does not (exist|exitst)" &&
 echo "Log file missing - $vol/$brick ." &&
 exit 1
share|improve this answer
    
The "exitst" typo is what is written in the logs. I don't buy the "compact" advantage - the script is much harder to understand when lines are overloaded. Temporary file is cheap price to pay for the easy-to-understand code. –  Arie Skliarouk Feb 20 '13 at 16:13
    
@ArieSkliarouk: Updated to cover both cases, but be forewarned that the relevant message was removed in November 2011; see git.gluster.org/… . Thus, this is likely not going to work on newer Glusters. If you find the shorter code harder to understand, that's fine, but it is significantly more robust than using a temporary file, so consider refactoring it for readability instead of dismissing it for perceived lack of that attribute. –  BMDan Mar 18 '13 at 15:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.