Monitoraggio di OpenStack Swift con Opsview

Come punto di partenza eseguiremo un controllo “front door” poiché questo dovrebbe funzionare indipendentemente dall’implementazione di Swift che stai utilizzando.

Nota che stiamo utilizzando la versione di autenticazione 2.0 con Keystone piuttosto che tempauth.

Le seguenti istruzioni presuppongono che tu abbia già configurato e avviato sia il server Opsview che OpenStack Object Storage (Swift).

Attività di configurazione preliminare

La macchina che esegue il controllo deve avere un client Swift e un agente Opsview. Se prevedi di monitorare da un server proxy Swift, dovresti aver bisogno solo di quest’ultimo; se prevedi di eseguire i controlli dal tuo server Opsview, allora avrai bisogno del primo.

Installazione del client Swift

Questo richiede che Python sia installato – scarica il sorgente da:

https://github.com/openstack/python-swiftclient.git
https://github.com/openstack/python-keystoneclient.git

sudo python setup.py install

(per entrambi)

Installazione dell’agente Opsview su Ubuntu

echo "deb http://downloads.opsview.com/opsview-core/latest/apt precise  
main" > /etc/apt/sources.list.d/opsview-core.list  
apt-get update  
apt-get install opsview-agent

Ottenere il controllo

I dettagli del plugin sono qui:
http://exchange.nagios.org/directory/Plugins/Clustering-and-High-2DAvailability/check_swift/details

Il link per il download diretto:
http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=3589&cf_id=30

Posiziona questo in /usr/local/nagios/libexec (sull’agente Opsview) e rendi il file eseguibile (

chmod +x check_swift

) e di proprietà di nagios (

chmod nagios:nagios check_swift

Variabili di ambiente

Se non hai già impostato le variabili di ambiente ST_AUTH (tenant), ST_USER e ST_KEY, potresti voler modificare il controllo di conseguenza (come da diff seguente):

diff check_swift.orig check_swift

52c52  
< export OS_AUTH_URL=$OPTARG  
> export ST_AUTH=$OPTARG  
55c55  
< export OS_USERNAME=$OPTARG  
---  
> export ST_USER=$OPTARG  
58c58  
< export OS_PASSWORD=$OPTARG  
---  
> export ST_KEY=$OPTARG

Configurazione di NRPE

Sebbene tu possa eseguire il controllo dal tuo server Opsview (se installi il client Swift), è più probabile che venga eseguito su un agente Opsview tramite NRPE.

Pertanto, dobbiamo aggiungere un comando di controllo del servizio alla configurazione NRPE sull’agente Opsview:

echo "command[check_swift]=/usr/local/nagios/libexec/check_swift \$ARG1\$" >> /usr/local/nagios/etc/nrpe_local/override.cfg  
/etc/init.d/opsview-agent restart

Configurazione del controllo

Sul tuo server Opsview dovrai definire un nuovo controllo del servizio, la Figura 1 mostra un esempio completato.

Figura 1 – Definizione del controllo del servizio

Se ti piace copiare e incollare, gli argomenti per check_nrpe sono:

-H \$HOSTADDRESS\$ -c check_swift -a '-V 2 -U admin:admin -A  
http://127.0.0.1:5000/v2.0/ -K secrete -c container'

Sostituisci i valori come applicabile o sovrascrivili a livello di host.

Il controllo in azione

La Figura 2 mostra la vista a livello di host del controllo del servizio (nota che sembra ignorare il valore -c container).

Figura 2 – Risultati del controllo del servizio

Ecco fatto, monitoraggio di base di OpenStack Swift rapido e semplice.

Risoluzione dei problemi

Se non funziona, controlla prima se puoi eseguire un upload utilizzando il client swift:

swift -V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete upload  
container check_swift

Il secondo test è verificare che il plugin Nagios restituisca un codice di uscita zero:

check_swift -V 2 -U admin:admin -A http://127.0.0.1:5000/v2.0/ -K secrete  
-c container  
echo \$?

Nota che il plugin reindirizza l’output a /dev/null quindi potresti dover modificare una copia dello script in modo da poter vedere i messaggi di errore swift se questo passaggio fallisce.

Infine, testa NRPE:

check_nrpe -H localhost -c check_swift -a '-V 2 -U admin:admin -A  
http://127.0.0.1:5000/v2.0/ -K secrete -c container -s 128'

Pubblicato da: Brian King