Come monitorare i volumi dei glusterfs


12

Glusterfs, pur essendo un bel filesystem distribuito, non fornisce quasi alcun modo per monitorarne l'integrità. I server possono andare e venire, i mattoni potrebbero diventare stantii o fallire e temo di saperlo quando probabilmente è troppo tardi.

Di recente abbiamo avuto uno strano fallimento quando tutto sembrava funzionare, ma un volume è caduto dal volume (trovato per pura coincidenza).

Esiste un modo semplice e affidabile (cron script?) Che mi farà conoscere lo stato di integrità del mio volume GlusterFS 3.2 ?


Per ora usiamo un monitoraggio basato su script di shell sporca: check_gluster.sh
Arie Skliarouk

Dai un'occhiata a glfs-health.sh .
quanta

1
Ho controllato glfs-health.sh e sembra che sia per le vecchie versioni di glusterfs, che erano controllate dal file di configurazione. Chiarirò la mia domanda per rappresentare glusterfs 3.2.
Arie Skliarouk,

Risposte:


3

Questa è una richiesta per gli sviluppatori GlusterFS da un po 'di tempo e non c'è nulla di pronto all'uso che puoi usare. Tuttavia, con alcuni script non è impossibile.

Praticamente l'intero sistema Gluster è gestito da un singolo comando gluster e con alcune opzioni, è possibile scrivere script di monitoraggio dell'integrità. Vedi qui per informazioni sull'elenco di mattoni e volumi - http://gluster.org/community/documentation/index.php/Gluster_3.2:_Displaying_Volume_Information

Per monitorare le prestazioni, guarda questo link: http://gluster.org/community/documentation/index.php/Gluster_3.2:_Monitoring_your_GlusterFS_Workload

AGGIORNAMENTO: prendere in considerazione l'aggiornamento a http://gluster.org/community/documentation/index.php/About_GlusterFS_3.3

Stai sempre meglio con la versione più recente poiché sembrano avere più correzioni di bug e ben supportati. Naturalmente, esegui i tuoi test prima di passare a una versione più recente - http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ :)

C'è una guida per l'amministratore con una sezione specifica per il monitoraggio dell'installazione di GlusterFS 3.3 nel Capitolo 10 - http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US .PDF

Vedi qui per un altro script nagios: http://code.google.com/p/glusterfs-status/


Grazie Chida, suppongo che ciò che mi ha fatto riattaccare sia che alcune persone ( github.com/semiosis/puppet-gluster ) stiano monitorando il gluster tramite la tabella proc ('--with-brick', ecc.) E file di log (egrep 'E' per errore) e alcune persone utilizzano l'interfaccia della riga di comando e non ho idea di quale sia la probabilità più probabile di segnalare accuratamente lo stato del gluster.
r_2,

Consiglio di utilizzare l'interfaccia della riga di comando poiché è quella consigliata da GlusterFS ed è destinata ad essere aggiornata.
Chida,


2

Si prega di controllare lo script allegato su https://www.gluster.org/pipermail/gluster-users/2012-June/010709.html per gluster 3.3; è probabilmente facilmente adattabile a gluster 3.2.

#!/bin/bash

# This Nagios script was written against version 3.3 of Gluster.  Older
# versions will most likely not work at all with this monitoring script.
#
# Gluster currently requires elevated permissions to do anything.  In order to
# accommodate this, you need to allow your Nagios user some additional
# permissions via sudo.  The line you want to add will look something like the
# following in /etc/sudoers (or something equivalent):
#
# Defaults:nagios !requiretty
# nagios ALL=(root) NOPASSWD:/usr/sbin/gluster peer status,/usr/sbin/gluster volume list,/usr/sbin/gluster volume heal [[\:graph\:]]* info
#
# That should give us all the access we need to check the status of any
# currently defined peers and volumes.

# define some variables
ME=$(basename -- $0)
SUDO="/usr/bin/sudo"
PIDOF="/sbin/pidof"
GLUSTER="/usr/sbin/gluster"
PEERSTATUS="peer status"
VOLLIST="volume list"
VOLHEAL1="volume heal"
VOLHEAL2="info"
peererror=
volerror=

# check for commands
for cmd in $SUDO $PIDOF $GLUSTER; do
    if [ ! -x "$cmd" ]; then
        echo "$ME UNKNOWN - $cmd not found"
        exit 3
    fi
done

# check for glusterd (management daemon)
if ! $PIDOF glusterd &>/dev/null; then
    echo "$ME CRITICAL - glusterd management daemon not running"
    exit 2
fi

# check for glusterfsd (brick daemon)
if ! $PIDOF glusterfsd &>/dev/null; then
    echo "$ME CRITICAL - glusterfsd brick daemon not running"
    exit 2
fi

# get peer status
peerstatus="peers: "
for peer in $(sudo $GLUSTER $PEERSTATUS | grep '^Hostname: ' | awk '{print $2}'); do
    state=
    state=$(sudo $GLUSTER $PEERSTATUS | grep -A 2 "^Hostname: $peer$" | grep '^State: ' | sed -nre 's/.* \(([[:graph:]]+)\)$/\1/p')
    if [ "$state" != "Connected" ]; then
        peererror=1
    fi
    peerstatus+="$peer/$state "
done

# get volume status
volstatus="volumes: "
for vol in $(sudo $GLUSTER $VOLLIST); do
    thisvolerror=0
    entries=
    for entries in $(sudo $GLUSTER $VOLHEAL1 $vol $VOLHEAL2 | grep '^Number of entries: ' | awk '{print $4}'); do
        if [ "$entries" -gt 0 ]; then
            volerror=1
            let $((thisvolerror+=entries))
        fi
    done
    volstatus+="$vol/$thisvolerror unsynchronized entries "
done

# drop extra space
peerstatus=${peerstatus:0:${#peerstatus}-1}
volstatus=${volstatus:0:${#volstatus}-1}

# set status according to whether any errors occurred
if [ "$peererror" ] || [ "$volerror" ]; then
    status="CRITICAL"
else
    status="OK"
fi

# actual Nagios output
echo "$ME $status $peerstatus $volstatus"

# exit with appropriate value
if [ "$peererror" ] || [ "$volerror" ]; then
    exit 2
else
    exit 0
fi


1

@Arie Skliarouk, hai check_gluster.shun errore di battitura: sull'ultima riga, fai il grep exitstinvece di exist. Sono andato avanti e l'ho riscritto per essere un po 'più compatto e per rimuovere il requisito per un file temporaneo.

#!/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 list); 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

1
L'errore di battitura "exitst" è ciò che è scritto nei registri. Non compro il vantaggio "compatto": lo script è molto più difficile da capire quando le linee sono sovraccaricate. Il file temporaneo è un prezzo economico da pagare per il codice di facile comprensione.
Arie Skliarouk,

@ArieSkliarouk: aggiornato per coprire entrambi i casi, ma tieni presente che il messaggio pertinente è stato rimosso nel novembre 2011; vedi git.gluster.org/… . Pertanto, questo probabilmente non funzionerà con i nuovi Gluster. Se ritieni che il codice più breve sia più difficile da capire, va bene, ma è significativamente più robusto rispetto all'utilizzo di un file temporaneo, quindi considera di rifattorizzarlo per leggibilità invece di scartarlo per mancanza percepita di quell'attributo.
BMDan,

1
Un editor anonimo ha notato che gluster volume info | awk ...può essere abbreviato gluster volume list.
Lekensteyn,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.