Integration von Ubuntu Landscape mit Opsview Enterprise

Kürzlich haben wir uns mit dem Ubuntu-Toolset beschäftigt, das in der Openstack-Keynote-Rede in diesem Jahr von Mark Shuttleworth vorgestellt wurde – von besonderem Interesse war Ubuntu Landscape; ihr System- und Servermanagement-Tool, das das Patchen und Verwalten von Tausenden von Ubuntu-Servern von einer einzigen Konsole aus ermöglicht.

Die Schönheit von Landscape besteht darin, dass Sie, wenn Sie 1000 Ubuntu-Server haben, die Software und Patches unterwegs aus einer einzigen Ansicht aktualisieren können. Sie können sogar auf jeden Server klicken, um die Hardware- und Softwareinventare zu erhalten, die Berichte darüber zu sehen, welche Prozesse die CPU nutzen usw., alles von einem einzigen Tool aus.

Ein interessanter Punkt aus der Perspektive von Opsview ist, dass es pro Gerät einen “Überwachungs”-Tab enthält. Dieser Tab ist rudimentär, da er nur die Grundlagen der Überwachung (Ressourcennutzung, Netzwerkdurchsatz usw.) wie unten zeigt:

Dies wird vermutlich über den Landscape-Client, der auf dem Ubuntu-Server läuft, abgerufen / abgefragt und verwendet die üblichen “Last”- usw. Ausgaben, die geparst und bearbeitet werden. Dieses Detail ist jedoch recht grundlegend, daher ist es unwahrscheinlich, dass viele Leute dies als ihr einziges Überwachungstool im Gegensatz zu Opsview verwenden – es ist eher ein nützliches Add-On, das es Ihnen ermöglicht, die Gesundheit von ‘X’ zu überprüfen, während Sie im Landscape-Dashboard sind.

Das brachte uns jedoch zum Nachdenken – was wäre, wenn wir Opsview weiterhin als unser Hauptüberwachungstool verwenden könnten, das es Kunden ermöglicht, sich einzuloggen, um ihre Systeme über ein Dashboard zu sehen, E-Mail-Berichte zu erhalten, SMS-Benachrichtigungen zu senden usw., aber diese Opsview-Daten in das Landscape-Dashboard integrieren – sodass es möglich ist, auf “Server100” in Opsview und “Server100” in Landscape zu klicken und die gleichen Grafiken zu sehen. Dies könnte es uns ermöglichen, die Gesundheit des Servers zu sehen, egal welches Tool wir verwenden.

Um dies in Landscape zu tun, ist es tatsächlich recht einfach (sobald Sie sich an die Feinheiten des Systems gewöhnt haben). Zunächst müssen wir von unserer Hauptkonsole aus zu “Benutzerdefinierte Grafiken” navigieren, wie unten:

Als nächstes müssen wir auf “Benutzerdefinierte Grafik hinzufügen” klicken, was eine Seite wie unten öffnet (wir haben Zeit gespart, indem wir das Feld bereits ausgefüllt haben):

Da es auf dem Bild möglicherweise schwer zu lesen ist, ist der “Code” unten eingefügt:

#!/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'

Dies verwendet im Grunde den opsview_rest-Befehl, um sich mit dem Opsview-Überwachungssystem zu verbinden und die Metrik “max_used_connections” vom Host “opsview” abzurufen und führt dann einige Sedding/Grep-Vorgänge durch, um uns einen grafischen Wert zu geben, d.h. “28”, anstatt “value=>28;21;s…”, was Ubuntu nicht mag :)

Was uns dies ermöglicht, ist, unser Opsview-Überwachungssystem als Landscape-Host hinzuzufügen und uns zu ermöglichen, die Gesundheit des Überwachungssystems über Landscape zu überwachen, zusammen mit der Gesundheit jedes anderen Hosts, der vom Opsview-System überwacht wird – und jeder Dienstprüfung, die dagegen ausgeführt wird. Wir können diese Informationen abrufen, indem wir den Befehl ausführen:

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

Wo “?hostname” der Host ist, dessen Leistungsdaten wir anzeigen möchten. Sobald dies konfiguriert und gemäß dem vorherigen Screenshot gespeichert ist, müssen wir unseren “ausführen als Benutzer:” (entweder root oder einen anderen Benutzer) und “Y-Achsentitel” (Sekunden, DB-Verbindungen, Temperatur usw.) festlegen. Sobald dies erledigt ist, klicken wir auf “Speichern”, und dies wird auf alle Hosts angewendet (wenn Sie das Kästchen angekreuzt haben).

Dann, nach einem Tag oder so, können wir zum Host gehen und den “Überwachungs”-Tab anzeigen und unsere benutzerdefinierten Grafiken sehen:

… und so integrieren wir Opsview mit Ubuntu Landscape.

Die Herausforderung

Die nächste Herausforderung bestand darin, dass das von Landscape verwaltete Gerät den Befehl ausführt:

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

.. was “opsview_rest” über Bash verwendet und lokal ausgeführt wird. Ideal wäre es, dies von überall aus (d.h. dem Server, den wir in Landscape verwalten) auszuführen, aber dennoch gegen unser Opsview-System zu laufen. Letzteres ist einfach; wir können ein Präfix wie unten hinzufügen:

./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'

… aber dies hängt immer noch vom Befehl “opsview_rest” ab, der offensichtlich auf der lokalen Box verfügbar sein muss, da die benutzerdefinierten Grafiken das Skript lokal auf dem von Ubuntu Landscape verwalteten System ausführen. Und auch dies gibt den Benutzernamen und das Passwort an den Host-Server weiter, d.h. Ihr Webserver hat jetzt Anmeldedaten für Opsview. Wir können jedoch das letztere Problem einschränken, indem wir dieser Rolle sehr spezifischen Zugriff nur auf Lesezugriff gewähren und nur auf einige spezifische Elemente.

Was wir benötigen, ist die Fähigkeit, dass der Host, der von Opsview überwacht und von Ubuntu Landscape verwaltet wird, die Möglichkeit hat, Opsview über die REST-API nach seiner eigenen Gesundheit zu befragen – damit er diese Informationen an Landscape zurückgeben kann, um sie zu grafisch darzustellen. Wir können opsview_rest jedoch aufgrund von Perl-Problemen, Abhängigkeiten usw. nicht verteilen, also was können wir tun?

Das einzige Element, das zu funktionieren scheint oder unsere Kriterien erfüllt, ist die Verwendung von check_nrpe auf die “nicht-traditionelle Weise”. Was ich damit meine, ist, dass NRPE traditionell ein Client-seitiges Programm ist, das von Opsview nach Informationen abgefragt wird – d.h. “Wie beschäftigt ist Ihre CPU? Wie voll sind Ihre Festplatten?”. Diese Werte werden dann an Opsview zurückgegeben und für Berichte, Dashboards und Ähnliches gespeichert und zur Alarmierung verwendet.

Was wir in diesem Beispiel festgestellt haben, ist, dass wir den NRPE-Client (Opsview-Agent) auf dem überwachten/verwalteten Host installieren und diesen verwenden können, um NRPE, das auf dem Opsview-Master läuft, abzufragen.

Auf diesem Opsview-Master würden wir unsere NRPE-Befehle in “ /usr/local/nagios/etc/nrpe_local/overrides.cfg” angeben (diese Datei existiert nicht, Sie müssen sie erstellen) und die Zeilen wie unten hinzufügen:

############################################################################
# Zusätzliche NRPE-Konfigurationsdatei für Opsview
############################################################################
check_command[get_rest]=/usr/local/nagios/bin/landscape_monitor.pl $ARG1$ $ARG2$

Wo “get_rest” der Befehl ist, den wir remote aufrufen werden, und alles “östlich des Gleichheitszeichens” der tatsächliche Befehl ist, der lokal ausgeführt wird.

Wie Sie oben sehen können, führen wir etwas namens “landscape_monitor.pl” aus – ein Perl-Skript, das wir geschrieben haben, um das Host-Argument zu übernehmen (d.h. $ARG1$ könnte “server00156” oder “networkswitch-X624” in Opsview (der ‘Hostname’) sein). Das bedeutet, dass wir nicht für jeden einen check_command erstellen müssen, d.h.:

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

Wir können einfach $ARG1$ verwenden und unser Perl-Skript darauf vorbereiten. Als nächstes haben wir das eigentliche Skript (dies verwendet JSON und IPC, daher müssen wir die folgenden Pakete auf dem Opsview-System installieren: 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, \

ew $out;
my $data = decode_json($out);
print $data->{list}->[0]->{value};

Wie wir oben sehen können, nehmen wir eine Variable (den Hostnamen) und fügen sie dem opsview_rest-Befehl hinzu, den wir erstellen. Wir nehmen auch die Leistungsmetrik und drucken nach dem Ausführen des erstellten Befehls die Ausgabe des Befehls im JSON-Format – “23” in unserem Beispiel. Dies erspart uns, es zu greppen/sed zu bearbeiten, um den tatsächlichen Wert zu erhalten, den Landscape verwenden kann.

Sobald Sie Ihr Skript “landscape_monitor.pl” in /usr/local/nagios/bin/ hinzugefügt und chmod / chown’d haben – können Sie die overrides.cfg-Datei erstellen und die Zeile wie oben hinzufügen.

Schließlich starten Sie NRPE auf dem überwachten/verwalteten Gerät – und wir sind bereit, wie unten zu ruhen.

Szenario

Phase 1: Wir haben die Standardüberwachungsumgebung; Opsview überwacht “Server A” und fragt Informationen wie DB-Statistiken, Apache-Statistiken usw. ab und zeigt diese Informationen in Dashboards für Benutzer über die GUI an, sendet E-Mail/SMS-Benachrichtigungen, Alarme usw., wenn Probleme auftreten.

Phase 2: Jetzt, da Opsview Tausende von Metriken und Statistiken von unseren Servern sammelt, können wir die REST-API verwenden, um diese Statistiken vom überwachten Server, d.h. “Server A”, mit dem obigen Perl-Skript abzufragen. Dazu führen wir einfach die Befehle wie unten aus:

./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$

Indem wir check_nrpe auf ServerA verwenden und unseren Hostnamen übergeben, d.h. “ServerA”, können wir den max_db_connections-Wert sehen, den Opsview für uns hat.

Phase 3: Da wir jetzt die Möglichkeit haben, dass das überwachte Gerät seine eigenen Metriken kennt – sind die Möglichkeiten, was wir tun können, endlos. In unserem Beispiel möchten wir einfach Landscape verwenden, um unsere von Opsview gesammelten Metriken zu grafisch darzustellen, damit wir Zugriff auf die Grafiken “auf einen Blick” in unserem Landscape-System haben, zusammen mit der Möglichkeit, in Opsview zu tauchen, um Berichte/Dashboards und die spezifischeren Überwachungselemente zu sehen. Es gibt jedoch nichts, was uns daran hindert, diese Technologie zu nutzen, um Opsview mit anderen Grafikanwendungen usw. zu integrieren.

Um dies mit Landscape zu integrieren, ist es sehr einfach. Wir müssen einfach eine weitere “Benutzerdefinierte Grafik” erstellen, wie wir zuvor im Dokument beschrieben haben, und im Textfeld hinzufügen:

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

Schließlich wenden wir diese Grafik auf den einen Host an, den wir möchten – und voila, wir überwachen jetzt die “max DB-Verbindungen” des Servers über Landscape. Wir können dann darauf aufbauen, die Metrik ändern usw., sodass Sie im Wesentlichen alle von Opsview gesammelten Metriken innerhalb von Ubuntu Landscape, RH Satellite usw. sehen können.

Ein letzter Blick

Theoretisch haben wir jetzt folgendes Szenario:

100 Ubuntu-Server, die von Ubuntu Landscape verwaltet und gepatcht werden.
100 Ubuntu-Server, die von Opsview Enterprise überwacht und alarmiert werden.

Wir hätten die Hosts sowohl zu Landscape als auch zu Opsview hinzugefügt, und wir würden Opsview für die detailliertere Überwachung, Alarmierung, Berichte, Dashboards, NetFlow usw. verwenden und dann die besonders interessanten “auf einen Blick”-Metriken in die Landscape-Seite dieses Hosts einfügen.

Host in Opsview

Der Host wird in Opsview wie oben hinzugefügt – wir können alle Metriken sehen, sie grafisch darstellen, steuern, wann sie überwacht werden, Metriken basierend auf Zeiträumen ändern usw.

Host in Landscape

Wir haben auch den Host in Landscape – von dieser Ansicht aus können wir das Asset (Hardware usw.) sehen, Pakete aktualisieren, Berichte über die Gesundheit des Systems sehen usw. Wir können auch auf “Überwachung” klicken und unsere von Opsview gesammelten “auf einen Blick”-Informationen innerhalb von Landscape sehen, wie unten:

(auch wenn es sich um einen viel zu wenig genutzten Apache-Server handelt! ^_^ ).

Versuchen Sie Opsview Enterprise ›

Versuchen Sie Ubuntu Landscape ›