Integrazione di Ubuntu Landscape con Opsview Enterprise

Recentemente abbiamo esaminato il set di strumenti di Ubuntu delineato nel discorso di apertura di Openstack di quest’anno da Mark Shuttleworth – di particolare interesse era Ubuntu Landscape; il loro strumento di gestione dei sistemi e dei server che consente di applicare patch e gestire migliaia di server Ubuntu da un’unica console.

La bellezza di Landscape è che se hai 1000 server Ubuntu puoi aggiornare il software e applicare le patch al volo da un’unica vista, puoi anche cliccare su ciascun server per ottenere gli inventari hardware e software, vedere i rapporti su quali processi stanno utilizzando la CPU, ecc. tutto da un unico strumento.

Un elemento interessante da una prospettiva di Opsview è che contiene una scheda “monitoraggio” per dispositivo. Questa scheda è rudimentale in quanto mostra solo le basi del monitoraggio (utilizzo delle risorse, throughput di rete, ecc) come di seguito:

Questo viene presumibilmente acquisito / interrogato tramite il client Landscape in esecuzione sul server Ubuntu e utilizzando i soliti output di “carico” ecc. che vengono analizzati e modificati. Questo dettaglio è piuttosto basilare, tuttavia, è improbabile che molte persone lo utilizzino come strumento unico per il monitoraggio rispetto a Opsview – è più un utile componente aggiuntivo che ti consente di controllare la salute di ‘X’ mentre sei nel dashboard di Landscape.

Tuttavia, questo ci ha fatto pensare – e se potessimo comunque utilizzare Opsview come nostro principale strumento di monitoraggio, che consente ai clienti di accedere per visualizzare i propri sistemi tramite un dashboard, inviare rapporti via email, inviare avvisi SMS, ecc., ma integrare questi dati di Opsview nel dashboard di Landscape – in modo che sia possibile cliccare su “Server100” in Opsview e “Server100” in Landscape, e vedere gli stessi grafici. Questo potrebbe permetterci di vedere la salute del server, indipendentemente dallo strumento che stiamo utilizzando.

Per fare questo in Landscape è in realtà abbastanza semplice (una volta che ti abitui alle sfumature del sistema). Innanzitutto, dalla nostra console principale dobbiamo navigare su “Grafici personalizzati” come di seguito:

Successivamente dobbiamo cliccare su “Aggiungi grafico personalizzato” che apre una pagina come di seguito (abbiamo risparmiato tempo popolando già il campo):

Poiché potrebbe essere difficile leggere nell’immagine, il “codice” è incollato qui sotto:

#!/bin/bash 
cd /usr/local/nagios/bin 
./opsview_rest --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview' | grep value | sed -e 's/value => //g' | sed -e 's/,//g' | sed 's/ //g'

Questo utilizza fondamentalmente il comando opsview_rest per connettersi al sistema di monitoraggio Opsview e ottenere la metrica “max_used_connections” dall’host “opsview” e poi fa alcune operazioni di modifica/analisi per darci un valore grafico, cioè “28”, piuttosto che “value=>28;21;s…” che Ubuntu non gradisce :)

Ciò che questo ci consente di fare è avere il nostro sistema di monitoraggio Opsview aggiunto come host di Landscape e ci consente di monitorare la salute del sistema di monitoraggio tramite Landscape, insieme alla salute di qualsiasi altro host monitorato dal sistema Opsview – e qualsiasi controllo di servizio in esecuzione contro di esso. Possiamo ottenere queste informazioni eseguendo il comando:

opsview_rest --username=admin --password=initial --pretty GET /rest/status/performancemetric/?hostname=opsview

Dove “?hostname” è l’host di cui stiamo cercando di visualizzare i dati sulle prestazioni. Una volta configurato e salvato come da screenshot precedente, dobbiamo impostare il nostro “esegui come utente:” (o root o un altro utente) e il “Titolo dell’asse Y” (secondi, connessioni db, temperatura, ecc). Una volta fatto, clicchiamo su “Salva” e questo sarà applicato a tutti gli host (se hai selezionato la casella).

Poi, dopo un giorno o giù di lì, possiamo andare all’host e visualizzare la scheda “monitoraggio” e vedere i nostri grafici personalizzati:

…e questo è come possiamo integrare Opsview con Ubuntu Landscape.

La Sfida

La sfida successiva è stata che il dispositivo gestito da Landscape esegue il comando:

./opsview_rest --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview'

..che utilizza “opsview_rest” tramite bash e viene eseguito localmente. Ciò che sarebbe ideale è eseguire questo da qualsiasi luogo (cioè il server che stiamo gestendo in Landscape) ma comunque eseguire contro il nostro sistema Opsview. Quest’ultimo è facile; possiamo aggiungere un prefisso come di seguito:

./opsview_rest *--url-prefix=monitoringtool.company.com* --username=admin --password=initial --pretty GET '/rest/status/performancemetric?order=metricname&order=hostname&metricname=Max_used_connections&hostname=opsview'

…ma questo si basa ancora sul comando “opsview_rest”, che ovviamente deve essere disponibile sulla macchina locale poiché i grafici personalizzati eseguono lo script localmente sul sistema gestito da Ubuntu Landscape. E inoltre questo espone il nome utente e la password al server host, cioè il tuo server web ora ha i dettagli di accesso a Opsview. Tuttavia, possiamo limitare quest’ultimo problema consentendo a quel ruolo di avere accesso molto specifico solo in lettura, e solo in lettura a pochi elementi specifici.

Ciò di cui abbiamo bisogno è la possibilità di avere l’host monitorato da Opsview e gestito da Ubuntu Landscape, di avere la possibilità di interrogare Opsview tramite l’API REST riguardo alla propria salute - in modo che possa fornire queste informazioni a Landscape per la grafica. Tuttavia, non possiamo distribuire opsview_rest a causa di problemi con Perl, dipendenze, ecc., quindi cosa possiamo fare?

L’unico elemento che sembra funzionare o soddisfare i nostri criteri è utilizzare check_nrpe nel “modo non tradizionale”. Ciò che intendo dire è che tradizionalmente NRPE è un programma lato client che viene interrogato da Opsview per informazioni – cioè “Quanto è occupata la tua CPU? Quanto sono pieni i tuoi dischi?”. Questi valori vengono quindi restituiti a Opsview e memorizzati per rapporti, dashboard e simili e utilizzati per l’allerta.

Ciò che abbiamo scoperto in questo esempio è che potremmo installare il Client NRPE (Opsview Agent) sull’host monitorato/gestito e usarlo per interrogare NRPE in esecuzione sul master Opsview.

Su questo master Opsview, specificheremmo i nostri comandi NRPE in “/usr/local/nagios/etc/nrpe_local/overrides.cfg” (questo file non esiste, devi crearlo) e aggiungere le righe come di seguito:

############################################################################
# File di configurazione NRPE aggiuntivo per Opsview
############################################################################
check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl $ARG1$ $ARG2$

Dove “get_rest” è il comando che chiameremo da remoto, e qualsiasi cosa “a est dell’uguale” è il comando effettivo che viene eseguito localmente.

Puoi vedere da quanto sopra, che stiamo eseguendo qualcosa chiamato “landscape_monitor.pl” – uno script Perl che abbiamo scritto per prendere l’argomento host (cioè $ARG1$ potrebbe essere “server00156” o “networkswitch-X624” in Opsview (l’ ‘hostname’)). Questo significa che invece di dover creare un check_command per ciascuno, cioè:

check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl server1 
check_command[get_rest2]=/usr/local/nagios/bin/landscape_monitor.pl server2 
check_command[get_rest3]=/usr/local/nagios/bin/landscape_monitor.pl server3

Possiamo semplicemente usare $ARG1$ e far sì che il nostro script Perl lo aspetti. Successivamente, abbiamo lo script effettivo (questo utilizza JSON e IPC quindi abbiamo bisogno dei seguenti pacchetti installati sul sistema Opsview: libipc-run-perl libjson-any-perl)

#!/usr/bin/perl Shell
use strict;
use warnings;
use IPC::Run qw(run);
use JSON; 
my $hostname = $ARGV[0] || ''; 
my $perf_metric = $ARGV[1] || '';
my @cmd = qw(/usr/local/nagios/bin/opsview_rest --username admin --password initial --data-format json GET);
push @cmd, '/rest/status/performancemetric?order=metricname&order=hostname&metricname='. $perf_metric .'&hostname='. $hostname; 
run \\@cmd, \\undef, \\my $out;
my $data = decode_json($out);
print $data->{list}->[0]->{value};

Come possiamo vedere sopra, prendiamo una variabile (l’hostname) e la aggiungiamo al comando opsview_rest che stiamo costruendo. Prendiamo anche la metrica delle prestazioni e dopo aver eseguito il comando costruito, stampiamo l’output del comando dal formato JSON – “23” nel nostro esempio. Questo ci fa risparmiare di dover analizzare / modificare eccessivamente per ottenere il valore effettivo che Landscape può utilizzare.

Quindi, una volta che hai aggiunto il tuo script “landscape_monitor.pl” a /usr/local/nagios/bin/, e chmod / chown’d it – puoi procedere a creare il file overrides.cfg e aggiungere la riga come sopra.

Infine, avvia NRPE sul dispositivo monitorato/gestito – e siamo pronti a riposare come di seguito.

Scenario

Fase 1: Abbiamo l’ambiente di monitoraggio standard; Opsview monitora “Server A” e richiede informazioni come statistiche DB, statistiche apache, ecc. e visualizza queste informazioni nei dashboard per gli utenti tramite l’interfaccia grafica, invia avvisi via email/sms, ecc. quando si verificano problemi.

Fase 2: Ora che Opsview sta raccogliendo migliaia di metriche e statistiche dai nostri server, possiamo utilizzare l’API REST per interrogare quelle statistiche dal server monitorato, cioè “Server A”, utilizzando lo script perl sopra. Per fare ciò, eseguiamo semplicemente i comandi come di seguito:

./check_nrpe -H opsview-master-server -c get_rest -a serverA Max_used_connections

ubuntuserver@serverA:/usr/local/nagios/libexec$ ./check_nrpe -H opsview-master-server -c get_rest -a serverA Max_used_connections  
23  
ubuntuserver@serverA:/usr/local/nagios/libexec$

Utilizzando check_nrpe su ServerA e passando il nostro hostname, cioè “ServerA”, possiamo vedere il valore max_db_connections che Opsview ha per noi.

Fase 3: Poiché ora abbiamo la possibilità per il dispositivo monitorato, di conoscere le proprie metriche – le possibilità di ciò che possiamo fare sono infinite. Nel nostro esempio, vogliamo semplicemente utilizzare Landscape per graficare le nostre metriche raccolte da Opsview in modo da avere accesso ai grafici “a colpo d’occhio” nel nostro sistema Landscape insieme alla possibilità di approfondire Opsview per vedere rapporti / dashboard e gli elementi più specifici del monitoraggio. Tuttavia, non c’è nulla che ci impedisca di utilizzare questa tecnologia per integrare Opsview con altri strumenti di grafico, ecc.

Per integrare questo con Landscape, è molto semplice. Dobbiamo semplicemente creare un altro “Grafico Personalizzato” come abbiamo delineato in precedenza nel documento, e nella casella di testo aggiungere:

#!/bin/bash
cd /usr/local/nagios/bin
./check_nrpe –H opsviewserver –c get_rest -a servername max_used_connections

Infine, applichiamo questo grafico all’unico host che vogliamo – e voilà, ora stiamo monitorando le “max DB connections” del server, tramite Landscape. Possiamo quindi costruire su questo, cambiare la metrica, ecc. in modo che in sostanza tu possa vedere tutte le metriche raccolte da Opsview, all’interno di Ubuntu Landscape, RH Satellite, ecc.

Uno sguardo finale

Quindi in teoria, ora abbiamo il seguente scenario:

100 server Ubuntu gestiti e patchati ecc. da Ubuntu Landscape.
100 server Ubuntu monitorati e avvisati ecc. da Opsview Enterprise.

Avremmo gli host aggiunti sia a Landscape che a Opsview, e useremmo Opsview per il livello di monitoraggio più granulare, avvisi, rapporti, dashboard, NetFlow, ecc. e poi assorbire le metriche particolarmente interessanti “a colpo d’occhio” nella pagina Landscape di quegli host.

Host in Opsview

L’host è aggiunto in Opsview come sopra – possiamo vedere tutte le metriche, graficarle, controllare quando vengono monitorate, cambiare le metriche in base al periodo di tempo, ecc.

Host in Landscape

Abbiamo anche l’host in Landscape – da questa vista possiamo vedere l’asset (hardware, ecc.), aggiornare i pacchetti, vedere rapporti sulla salute del sistema, ecc. Possiamo anche cliccare su “Monitoraggio”, e vedere le nostre informazioni raccolte da Opsview “a colpo d’occhio”, all’interno di Landscape, come di seguito:

(sebbene, un server Apache molto poco utilizzato! ^_^ ).

Prova Opsview Enterprise ›

Prova Ubuntu Landscape ›