Überwachung von OpenStack Pt.2

In meinem letzten Blogbeitraghabe ich darüber gesprochen, wie man RabbitMQ als zentralisiertes Message Q von OpenStack überwachen kann. Nun, das ist ziemlich wichtig, aber das Endziel einer Cloud ist die Instanz auf der Maschine. Die meisten von euch und vor allem die Infrastrukturtypen, die sich mit der Überwachung beschäftigen, werden wissen, was die wichtigsten Komponenten sind, auf die man achten muss.

Der Grund für die Überwachung ist eine vernünftige Planung, die in einer Cloud-Umgebung, in der Sie eine große Anzahl von virtuellen Maschinen oder Containern erstellen müssen, wahrscheinlich die Regel ist. Auf der anderen Seite ist es sehr einfach, die Daten auf einen Blick zu haben, um die Zuverlässigkeit zu erhöhen, die Betriebszeit zu planen, die Architektur zu verbessern und die Engpässe Ihres Setups zu identifizieren.21JULMeineWahl in Bezug auf Cloud-Monitoring und DevOps ist, wie ich im vorherigen Beitrag erwähnt habe, Icinga2. Ich werde versuchen, im Detail zu erklären, warum und wie es mich beeindruckt hat, aber lassen Sie uns auf die Überwachung von virtuellen Maschinen und KVM-Instanzen konzentrieren. Zuallererst werde ich damit beginnen, was das Wichtigste ist, das überwacht werden muss und die Hauptmerkmale definieren. Eine gute Vorbereitung bringt die besten Ergebnisse!

HOST-ÜBERWACHUNG

Es gibt in der Tat zwei Perspektiven, die wir betrachten können. Die erste und wahrscheinlich sehr wichtige und interessante Perspektive ist die des Host-Betriebssystems. Aus diesem Blickwinkel sehen wir den KVM-Rechner als einen einzelnen Prozess, der auf ihm läuft. Etwa so:

qemu     32381     1  9 Jul14 ?        14:41:20 /usr/libexec/qemu-kvm -name instance-000000c9 -S -machine pc-i440fx-rhel7.0.0

Dieser qemu-Prozess stellt die virtuelle Maschine dar und alle Parameter definieren sie. Das ist doch hilfreich, oder? Wir müssen
einen Prozess überwachen und von hier aus können wir unsere Statistiken zur Überwachung erstellen:

- VSZ - Größe des virtuellen Speichers eines Prozesses
- Größe des residenten Speichers des Prozesses
- Prozentsatz der CPU
- Prozessexistenz (Instanzname wäre der beste Filter dafür)

Das Nagios-Plugin, das diese Aufgabe erleichtert, ist check_procs.
Bei letzterem ist es nicht so einfach zu ermitteln, welche Maschine welcher Instanz-ID entspricht. Normalerweise können Sie dies in
libvirt.conf innerhalb der nova-Instanzen abgleichen und den Namen Ihrer Instanz erhalten.
Ein weiteres nützliches Tool zur Überprüfung des Maschinenstatus ist virsh. Sie können den Status des Rechners abfragen und nach abgestürzten Rechnern suchen:

 Id Name Staat
----------------------------------------------------
 39 instance-000000c8 läuft
 40 instance-000000c9 läuft
 41 instance-000000bb läuft

Normalerweise sind die Zustände von KVM-Rechnern wie folgt:

running - Zustand, in dem die Instanz läuft und betriebsbereit ist
paused - in der Openstack-Terminologie: angehalten
inaktiv - angehalten oder abgeschaltet
abgestürzt - beim Starten ist ein Fehler aufgetreten

Am besten ist es, nach "crashed" zu suchen und dann nach dem Grund für den Absturz zu suchen.
virsh list | grep crashed
Eine weitere Abkürzung ist die Verwendung des check_libvirt nagios-Plugins, das eine Menge leistet.
Der andere Aspekt der Überwachung ist natürlich die Betrachtung des Gastes. Es gibt einige Parameter, die
mit der vorherigen Überwachung korreliert sein könnten, aber es gibt immer noch wesentliche Unterschiede:

- Speichernutzung des Servers
- CPU-Auslastung und Wartezeiten
- Festplatten-E/A
- Festplattennutzung

SPEICHER

Beginnen wir mit einem nach dem anderen. Der erste, recht wichtige und nicht so leicht zu verfolgende Punkt ist die Speichernutzung.

              insgesamt verwendet freier gemeinsamer Buff/Cache verfügbar
Speicher: 74053676 19262360 377524 3720412 54413792 50583164
Swap: 978940 107552 871388

Die meisten Infrastrukturtypen oder die besseren kennen den Befehl "free". Nun, das bedeutet, dass der freie Speicher im Vergleich zu den anderen sehr klein ist. Der Grund dafür ist die Art und Weise, wie Linux mit Speicher umgeht, um viele Disk I/O Operationen zu sparen. Also berechnen wir freien und zwischengespeicherten Speicher als eine gemeinsame Metrik. Ein nettes Plugin dafür gibt es hier.

Es funktioniert wirklich gut und liefert Leistungsdaten für schöne Diagramme.
Beispiel:

check_mem.pl -f -C -w 20 -c 10

PROZESSORLAST UND -AUSLASTUNG

Eine weitere sehr gute Metrik für Ihr Dashboard und die Alarmierung ist die CPU-Last. Die Last kann aus vielen Gründen hoch sein, wie z.B. Iowait, Prozess erschöpft die CPU usw...
Sie können die check_load Funktion verwenden, die standardmäßig mit Nagios Plugins geliefert wird.
Wenn Sie die Wartezeiten anhand der CPU-Statistiken überwachen möchten, können Sie das Modul in Nagios Exchange verwenden, um die CPU-Statistiken zu überprüfen. Stellen Sie sicher, dass sysstat oder iostat auf dem Zielsystem installiert ist.

Server. Hier ist ein Beispiel für eine Metrik:

check_cpu_stats.sh -w 20 -c 30

DISK I/O

Hier können Sie die Metrik verwenden, um Probleme bei der zugrunde liegenden Speicherung zu finden. Zusammen mit den Leistungsdaten erhalten Sie noch mehr Statistiken darüber, wie die Daten sich verhalten.

check_io -d sda -w 40,400,400 -c 100,700,700

DISK-NUTZUNG

Zu guter Letzt können Sie mit check_disk die Nutzung aller Festplatten überprüfen.