[ 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?

Ü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.