[ English | Indonesia | Deutsch | 日本語 ]
Überwachung¶
Es gibt zwei Arten der Überwachung: die Überwachung auf Probleme und die Überwachung von Nutzungstrends. Erstere stellt sicher, dass alle Dienste einsatzbereit sind und bildet eine funktionale Cloud. Letzteres beinhaltet die Überwachung des Ressourcenverbrauchs im Laufe der Zeit, um fundierte Entscheidungen über mögliche Engpässe und Upgrades zu treffen.
Prozessüberwachung¶
Eine grundlegende Art der Alarmüberwachung besteht darin, einfach zu überprüfen, ob ein erforderlicher Prozess läuft. Stellen Sie beispielsweise sicher, dass der Dienst nova-api
auf dem Cloud-Controller läuft:
# ps aux | grep nova-api
nova 12786 0.0 0.0 37952 1312 ? Ss Feb11 0:00 su -s /bin/sh -c exec nova-api
--config-file=/etc/nova/nova.conf nova
nova 12787 0.0 0.1 135764 57400 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12792 0.0 0.0 96052 22856 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12793 0.0 0.3 290688 115516 ? S Feb11 1:23 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12794 0.0 0.2 248636 77068 ? S Feb11 0:04 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
root 24121 0.0 0.0 11688 912 pts/5 S+ 13:07 0:00 grep nova-api
Die zu überwachenden OpenStack-Prozesse hängen von der spezifischen Konfiguration der Umgebung ab, können aber auch Folgendes beinhalten:
Compute Dienst (nova)
nova-api
nova-scheduler
nova-conductor
nova-novncproxy
nova-compute
Block Storage service (cinder)
cinder-volume
cinder-api
cinder-scheduler
Netzwerkdienst (Neutron)**Netzwerkdienst (Neutron)**
neutron-server
neutron-openvswitch-agent
neutron-dhcp-agent
neutron-l3-agent
neutron-metadata-agent
Image service (glance)
glance-api
glance-registry
Identitätsdienst (keystone)
Die Keystone-Prozesse werden innerhalb des Apache als WSGI-Anwendungen ausgeführt.
Ressourcenalarmierung¶
Resourcenallarmierung liefert Benachrichtigungen, wenn eine oder mehrere Ressourcen kritisch niedrig sind. Obwohl die Überwachungsschwellenwerte auf Ihre spezifische OpenStack-Umgebung abgestimmt werden sollten, ist die Überwachung der Ressourcennutzung nicht spezifisch für OpenStack und jede generische Art von Warnungen funktioniert einwandfrei.
Einige der Ressourcen, die Sie überwachen möchten, sind unter anderem:
Festplattennutzung
Serverauslastung
Speicherverbrauch
Netzwerk-I/O
Verfügbare vCPUs
Telemetriedienst¶
Der Telemetriedienst (ceilometer) sammelt Mess- und Ereignisdaten zu OpenStack-Diensten. Die vom Telemetrieservice gesammelten Daten können für die Abrechnung verwendet werden. Abhängig von der Bereitstellungskonfiguration können die gesammelten Daten den Benutzern basierend auf der Bereitstellungskonfiguration zugänglich sein. Sie können mehr über das Modul im Ceilometer Administrator Guide oder im Ceilometer Contributor Guide lesen.
OpenStack-spezifische Ressourcen¶
Ressourcen wie Speicher, Festplatte und CPU sind generische Ressourcen, die alle Server (auch Nicht-OpenStack-Server) haben und für den allgemeinen Zustand des Servers wichtig sind. Wenn es um OpenStack geht, sind diese Ressourcen aus einem zweiten Grund wichtig: Sicherstellen, dass genügend verfügbar ist, um Instanzen zu starten. Es gibt einige Möglichkeiten, wie Sie die Nutzung von OpenStack-Ressourcen sehen können. Die erste ist durch den Befehl openstack:
# openstack usage list
Dieser Befehl zeigt eine Liste der laufenden Instanzen eines Mandanten und einige leichte Nutzungsstatistiken über die kombinierten Instanzen an. Dieser Befehl ist nützlich für einen schnellen Überblick über Ihre Cloud, aber er geht nicht wirklich auf viele Details ein.
Als nächstes enthält die nova
-Datenbank drei Tabellen, die Nutzungsinformationen speichern.
In den Tabellen nova.quotas
und nova.quota_usages
werden Quoteninformationen gespeichert. Wenn die Quote eines Mandanten von den Standardeinstellungen abweicht, wird seine Quote in der Tabelle nova.quotas
gespeichert. Zum Beispiel:
mysql> select project_id, resource, hard_limit from quotas;
+----------------------------------+-----------------------------+------------+
| project_id | resource | hard_limit |
+----------------------------------+-----------------------------+------------+
| 628df59f091142399e0689a2696f5baa | metadata_items | 128 |
| 628df59f091142399e0689a2696f5baa | injected_file_content_bytes | 10240 |
| 628df59f091142399e0689a2696f5baa | injected_files | 5 |
| 628df59f091142399e0689a2696f5baa | gigabytes | 1000 |
| 628df59f091142399e0689a2696f5baa | ram | 51200 |
| 628df59f091142399e0689a2696f5baa | floating_ips | 10 |
| 628df59f091142399e0689a2696f5baa | instances | 10 |
| 628df59f091142399e0689a2696f5baa | volumes | 10 |
| 628df59f091142399e0689a2696f5baa | cores | 20 |
+----------------------------------+-----------------------------+------------+
Die Tabelle nova.quota_usages
verfolgt, wie viele Ressourcen der Mandant derzeit nutzt:
mysql> select project_id, resource, in_use from quota_usages where project_id like '628%';
+----------------------------------+--------------+--------+
| project_id | resource | in_use |
+----------------------------------+--------------+--------+
| 628df59f091142399e0689a2696f5baa | instances | 1 |
| 628df59f091142399e0689a2696f5baa | ram | 512 |
| 628df59f091142399e0689a2696f5baa | cores | 1 |
| 628df59f091142399e0689a2696f5baa | floating_ips | 1 |
| 628df59f091142399e0689a2696f5baa | volumes | 2 |
| 628df59f091142399e0689a2696f5baa | gigabytes | 12 |
| 628df59f091142399e0689a2696f5baa | images | 1 |
+----------------------------------+--------------+--------+
Wenn Sie das harte Limit eines Mandanten mit seinem aktuellen Ressourcenverbrauch vergleichen, können Sie seinen prozentualen Verbrauch erkennen. Wenn dieser Mandant zum Beispiel 1 von 10 Floating IP verwendet, dann nutzt er 10 Prozent seiner Floating IP-Quoten. Anstatt die Berechnung manuell durchzuführen, können Sie SQL oder die Skriptsprache Ihrer Wahl verwenden und einen formatierten Bericht erstellen:
+----------------------------------+------------+-------------+---------------+
| some_tenant |
+-----------------------------------+------------+------------+---------------+
| Resource | Used | Limit | |
+-----------------------------------+------------+------------+---------------+
| cores | 1 | 20 | 5 % |
| floating_ips | 1 | 10 | 10 % |
| gigabytes | 12 | 1000 | 1 % |
| images | 1 | 4 | 25 % |
| injected_file_content_bytes | 0 | 10240 | 0 % |
| injected_file_path_bytes | 0 | 255 | 0 % |
| injected_files | 0 | 5 | 0 % |
| instances | 1 | 10 | 10 % |
| key_pairs | 0 | 100 | 0 % |
| metadata_items | 0 | 128 | 0 % |
| ram | 512 | 51200 | 1 % |
| reservation_expire | 0 | 86400 | 0 % |
| security_group_rules | 0 | 20 | 0 % |
| security_groups | 0 | 10 | 0 % |
| volumes | 2 | 10 | 20 % |
+-----------------------------------+------------+------------+---------------+
Die vorhergehenden Informationen wurden mit einem benutzerdefinierten Skript generiert, das Sie unter GitHub finden.
Bemerkung
Dieses Skript ist spezifisch für eine bestimmte OpenStack-Installation und muss an Ihre Umgebung angepasst werden. Die Logik sollte jedoch leicht übertragbar sein.
Intelligente Alarmierung¶
Intelligente Alarmierung kann als eine Form der kontinuierlichen Integration für den Betrieb betrachtet werden. Sie können beispielsweise leicht überprüfen, ob der Abbilddienst betriebsbereit ist, indem Sie sicherstellen, dass die Prozesse glance-api
und glance-registry
laufen, oder indem Sie sehen, ob glance-api
auf Port 9292 reagiert.
Aber woher wissen Sie, ob Abbilder erfolgreich in den Abbilddienst hochgeladen werden? Vielleicht ist die Festplatte, auf der der Abbilddienst die Abbilder speichert, voll oder das S3-Backend ist ausgefallen. Sie können dies natürlich durch einen schnellen Abbildupload überprüfen:
#!/bin/bash
#
# assumes that reasonable credentials have been stored at
# /root/auth
. /root/openrc
wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
openstack image create --name='cirros image' --public \
--container-format=bare --disk-format=qcow2 \
--file cirros-0.3.5-x86_64-disk.img
Indem Sie dieses Skript in eine Warnung für Ihr Überwachungssystem (z.B. Nagios) verwandeln, haben Sie nun eine automatisierte Möglichkeit, sicherzustellen, dass Abbilduploads in den Image Catalog funktionieren.
Bemerkung
Sie müssen das Abbild nach jedem Test entfernen. Noch besser ist es, zu testen, ob Sie ein Abbild erfolgreich aus dem Abbilddienst löschen können.
Die intelligente Alarmierung benötigt wesentlich mehr Zeit für die Planung und Umsetzung als die anderen in diesem Kapitel beschriebenen Alarme. Ein guter Überblick zur Implementierung von intelligenter Alarmierung ist:
Überprüfen Sie allgemeine Aktionen in Ihrer Cloud.
Erstellen Sie Möglichkeiten, diese Aktionen automatisch zu testen.
Rollen Sie diese Tests in ein Alarmsystem.
Einige weitere Beispiele für Intelligent Alerting sind:
Können Instanzen gestartet und zerstört werden?
Können Benutzer angelegt werden?
Können Objekte gespeichert und gelöscht werden?
Können Datenträger erstellt und vernichtet werden?
Beliebt¶
Trending kann Ihnen einen guten Einblick in die tägliche Performance Ihrer Cloud geben. Sie können z.B. erfahren, ob ein arbeitsreicher Tag einfach ein seltenes Ereignis war oder ob Sie neue Compute-Knoten hinzufügen sollten.
Der Trend verfolgt einen etwas anderen Ansatz als die Alarmierung. Während die Alarmierung an einem binären Ergebnis interessiert ist (ob eine Prüfung erfolgreich ist oder nicht), zeichnet der Trend den aktuellen Zustand von etwas zu einem bestimmten Zeitpunkt auf. Sobald genügend Zeitpunkte erfasst wurden, können Sie sehen, wie sich der Wert im Laufe der Zeit verändert hat.
Alle zuvor genannten Alarmtypen können auch für das Trendberichtswesen verwendet werden. Einige andere Trendbeispiele sind:
Anzahl der Instanzen auf jedem Compute-Knoten
Die Arten von Varianten, die verwendet werden
Die Anzahl der verwendeten Datenträger
Die Anzahl der Objektspeicheranforderungen pro Stunde
Die Anzahl der
nova-api
Anfragen pro StundeDie I/O-Statistiken Ihrer Speicherdienste
Als Beispiel kann die Aufzeichnung der nova-api
Nutzung ermöglichen, dass Sie die Notwendigkeit der Skalierung Ihres Cloud Controllers verfolgen können. Indem Sie die Anfragen von nova-api
im Auge behalten, können Sie bestimmen, ob Sie weitere nova-api
Prozesse erzeugen müssen oder sogar einen völlig neuen Server für den Betrieb von nova-api
einführen. Um eine ungefähre Anzahl der Anfragen zu erhalten, suchen Sie nach Standard INFO-Meldungen in /var/log/nova/nova/nova-api.log
:
# grep INFO /var/log/nova/nova-api.log | wc
Weitere Statistiken erhalten Sie, indem Sie nach der Anzahl der erfolgreichen Anfragen suchen:
# grep " 200 " /var/log/nova/nova-api.log | wc
Indem Sie diesen Befehl regelmäßig ausführen und das Ergebnis protokollieren, können Sie einen Trendbericht erstellen, der zeigt, ob Ihre nova-api
Nutzung zunimmt, abnimmt oder konstant bleibt.
Ein Tool wie collectd kann verwendet werden, um diese Informationen zu speichern. Obwohl collectd außerhalb des Umfangs dieses Buches liegt, wäre ein guter Ausgangspunkt, collectd zu verwenden, um das Ergebnis als COUNTER-Datentyp zu speichern. Weitere Informationen finden Sie in der Dokumentation von collectd.
Überwachungswerkzeuge¶
Nagios¶
Nagios ist ein Open Source Überwachungsdienst. Es ist in der Lage, beliebige Befehle auszuführen, um den Status von Server- und Netzwerkdiensten zu überprüfen, beliebige Befehle direkt auf Servern aus der Ferne auszuführen und es Servern zu ermöglichen, Benachrichtigungen in Form von passiver Überwachung zurückzuschicken. Nagios gibt es seit 1999. Obwohl neuere Überwachungsdienste verfügbar sind, ist Nagios ein bewährtes Systemadministrations-Tool.
Mit Nagios und NRPE können Sie automatisierte Warnmeldungen für kritische Prozesse erstellen. Um beispielsweise sicherzustellen, dass der Prozess nova-compute
auf den Compute-Knoten läuft, erstellen Sie eine Warnung auf Ihrem Nagios-Server:
define service {
host_name c01.example.com
check_command check_nrpe_1arg!check_nova-compute
use generic-service
notification_period 24x7
contact_groups sysadmins
service_description nova-compute
}
Erstellen Sie auf dem Knoten Compute die folgende NRPE-Konfiguration:
command[check_nova-compute]=/usr/lib/nagios/plugins/check_procs -c 1: -a nova-compute
Nagios überprüft, ob mindestens ein ``nova-compute``Dienst jederzeit läuft.
Für Ressourcenalarmierung, z.B. die Überwachung der Festplattenkapazität auf einem Compute-Knoten mit Nagios, fügen Sie Folgendes zu Ihrer Nagios-Konfiguration hinzu:
define service {
host_name c01.example.com
check_command check_nrpe!check_all_disks!20% 10%
use generic-service
contact_groups sysadmins
service_description Disk
}
Fügen Sie auf dem Compute-Knoten Ihrer NRPE-Konfiguration Folgendes hinzu:
command[check_all_disks]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -e
Nagios warnt Sie mit einer WARNING, wenn ein Laufwerk auf dem Compute-Knoten zu 80 Prozent voll und zu 90 Prozent kritisch ist.
StackTach¶
StackTach ist ein Tool, das die von nova gesendeten Benachrichtigungen sammelt und meldet. Benachrichtigungen sind im Wesentlichen die gleichen wie Protokolle, können aber viel detaillierter sein. Fast alle OpenStack-Komponenten sind in der Lage, Benachrichtigungen zu generieren, wenn signifikante Ereignisse eintreten. Benachrichtigungen sind Nachrichten, die auf der OpenStack-Warteschlange (in der Regel RabbitMQ) für den Verbrauch durch nachgelagerte Systeme platziert werden. Eine Übersicht über die Benachrichtigungen finden Sie unter Systemnutzungsdaten.
Um nova das Senden von Benachrichtigungen zu ermöglichen, fügen Sie Folgendes zur Konfigurationsdatei nova.conf
hinzu:
notification_topics=monitor
notification_driver=messagingv2
Sobald nova Benachrichtigungen sendet, installieren und konfigurieren Sie StackTach. StackTach arbeitet für den Queue-Verbrauch und die Pipeline-Verarbeitung sind so konfiguriert, dass sie diese Benachrichtigungen von RabbitMQ-Servern lesen und in einer Datenbank speichern. Benutzer können Instanzen, Anforderungen und Server abfragen, indem sie die Browseroberfläche oder das Befehlszeilentool Stacky verwenden. Da StackTach relativ neu ist und sich ständig ändert, werden Installationsanweisungen schnell veraltet. Anweisungen sowie ein Demovideo finden Sie im StackTach Git-Repository. Weitere Details zu den neuesten Entwicklungen finden Sie auf der offiziellen Seite
Logstash¶
Logstash ist eine leistungsstarke Indexierungs- und Suchmaschine für Protokolle. Protokolle aus Jenkins Testläufen werden an logstash gesendet, wo sie indiziert und gespeichert werden. Logstash ermöglicht das Überprüfen von Protokollen aus mehreren Quellen in einem einzigen Testlauf, das Suchen nach Fehlern oder bestimmten Ereignissen innerhalb eines Testlaufs und das Suchen nach Trends bei Protokollereignissen über Testläufe hinweg.
Es gibt vier Hauptebenen im Logstash-Setup, nämlich:
Log Pusher
Log Indexer
ElasticSearch
Kibana
Jede Ebene skaliert horizontal. Wenn die Anzahl der Logs wächst, können Sie mehr Log-Pushers, mehr Logstash-Indexer und mehr ElasticSearch-Knoten hinzufügen.
Logpusher ist ein Paar Python-Skripte, die zuerst auf Jenkins Build-Ereignisse hören und sie dann in Gearman-Jobs konvertieren. Gearman bietet ein generisches Anwendungs-Framework, um Arbeiten an andere Maschinen oder Prozesse auszulagern, die besser geeignet sind, diese Arbeiten auszuführen. Es ermöglicht Ihnen, parallel zu arbeiten, die Lastausgleichsverarbeitung durchzuführen und Funktionen zwischen den Sprachen aufzurufen. Später führt Logpusher Gearman-Aufträge aus, um Logdateien in den Logstash zu verschieben. Der Logstash-Indexer liest diese Protokollereignisse, filtert sie, um unerwünschte Zeilen zu entfernen, komprimiert mehrere Ereignisse zusammen und analysiert nützliche Informationen, bevor er sie an ElasticSearch zum Speichern und Indizieren sendet. Kibana ist ein logstashorientierter Webclient für ElasticSearch.