[ English | 日本語 | Deutsch | Indonesia ]

Protokollierung

Wo sind die Protokolle?

Die meisten Dienste verwenden die Konvention, ihre Protokolldateien in Unterverzeichnisse des /var/log-Verzeichnisses zu schreiben, wie in Tabelle OpenStack-Protokollspeicherorte aufgeführt.

Tabelle OpenStack-Protokollspeicherorte

Knotentyp

Dienst

Protokollstandort

Cloud controller

nova-*

/var/log/nova

Cloud controller

glance-*

/var/log/glance

Cloud controller

cinder-*

/var/log/cinder

Cloud controller

keystone-*

/var/log/keystone

Cloud controller

neutron-*

/var/log/neutron

Cloud controller

horizon

/var/log/apache2/

Alle Knoten

misc (swift, dnsmasq)

/var/log/syslog

Compute-Knoten

libvirt

/var/log/libvirt/libvirtd.log

Compute-Knoten

Konsole (Boot-Up-Meldungen) für VM-Instanzen:

/var/lib/nova/instances/instance-<instance id>/console.log

Blockspeicher-Knoten

cinder-volume

/var/log/cinder/cinder-volume.log

Lesen der Protokolle

OpenStack-Dienste verwenden die Standard-Protokollierungsebenen mit zunehmendem Schweregrad: TRACE, DEBUG, INFO, AUDIT, WARNUNG, ERROR und KRITISCH. Das heißt, Nachrichten erscheinen in den Protokollen nur, wenn sie „schwerer“ sind als die jeweilige Protokollebene, wobei DEBUG alle Protokollanweisungen durchlässt. Beispielsweise wird TRACE nur protokolliert, wenn die Software über einen Stack-Trace verfügt, während INFO für jede Nachricht protokolliert wird, einschließlich derjenigen, die nur zur Information dienen.

Um die Protokollierung auf DEBUG-Ebene zu deaktivieren, bearbeiten Sie die Datei /etc/nova/nova.conf wie folgt:

debug=false

Keystone wird etwas anders behandelt. Um die Protokollierungsstufe zu ändern, bearbeiten Sie die Datei /etc/keystone/logging.conf und schauen Sie sich die Abschnitte logger_root und handler_file an.

Die Protokollierung für den Horizont ist unter /etc/openstack_dashboard/local_settings.py konfiguriert. Da Horizon eine Django-Webanwendung ist, folgt sie den Konventionen des Django Logging Frameworks.

Der erste Schritt zum Auffinden der Fehlerursache ist in der Regel die Suche nach einer CRITICAL oder ERROR Meldung im Protokoll, beginnend am Ende der Protokolldatei.

Hier ist ein Beispiel für eine Logmeldung mit dem entsprechenden ERROR (Python-Traceback) unmittelbar danach:

2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server [req-c0b38ace-2586-48ce-9336-6233efa1f035 6c9808c2c5044e1388a83a74da9364d5 e07f5395c
2eb428cafc41679e7deeab1 - default default] Exception during message handling
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server Traceback (most recent call last):
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 4366, in create_volume
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     allow_reschedule=allow_reschedule, volume=volume)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 634, in create_volume
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     _run_flow()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 626, in _run_flow
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     flow_engine.run()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 247, in run
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     for _state in self.run_iter(timeout=timeout):
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     failure.Failure.reraise_if_any(er_failures)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/types/failure.py", line 336, in reraise_if_any
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     failures[0].reraise()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/types/failure.py", line 343, in reraise

In diesem Beispiel konnte cinder-volumes nicht gestartet werden und hat eine Stapelverfolgung bereitgestellt, da sein Volume Backend das Speichervolumen nicht einrichten konnte - wahrscheinlich, weil das LVM-Volume, das von der Konfiguration erwartet wird, nicht existiert.

Hier ist ein Beispiel für ein Fehlerprotokoll:

2013-02-25 20:26:33 6619 ERROR nova.openstack.common.rpc.common [-] AMQP server on localhost:5672 is unreachable:
 [Errno 111] ECONNREFUSED. Trying again in 23 seconds.

In diesem Fehler konnte sich ein nova-Dienst nicht mit dem RabbitMQ-Server verbinden, weil er einen Fehler erhalten hat, der die Verbindung verweigert hat.

Verfolgung von Instanzanforderungen

Wenn sich eine Instanz nicht ordnungsgemäß verhält, müssen Sie oft die mit dieser Instanz verbundenen Aktivitäten über die Protokolldateien verschiedener ``nova-*``Dienste und sowohl über den Cloud Controller als auch über Compute-Knoten verfolgen.

Der typische Weg ist, die einer Instanz zugeordnete UUID über die Serviceprotokolle zu verfolgen.

Betrachten Sie das folgende Beispiel:

$ openstack server list
+--------------------------------+--------+--------+--------------------------+------------+
| ID                             | Name   | Status | Networks                 | Image Name |
+--------------------------------+--------+--------+--------------------------+------------+
| fafed8-4a46-413b-b113-f1959ffe | cirros | ACTIVE | novanetwork=192.168.100.3| cirros     |
+--------------------------------------+--------+--------+--------------------+------------+

Hier lautet die der Instanz zugeordnete ID faf7ded8-4a46-413b-b113-f19590746ffe. Wenn Sie nach dieser Zeichenkette auf dem Cloud-Controller in den Dateien /var/log/nova-*.log suchen, erscheint sie in nova-api.log` und nova-scheduler.log`. Wenn Sie dies auf den Compute-Knoten in /var/log/nova-*.log suchen, erscheint es in nova-compute.log. Wenn keine ERROR oder CRITICAL Meldungen angezeigt werden, kann der letzte Protokolleintrag, der dies meldet, einen Hinweis darauf geben, was falsch gelaufen ist.

Hinzufügen von benutzerdefinierten Protokollierungsanweisungen

Wenn nicht genügend Informationen in den vorhandenen Protokollen vorhanden sind, müssen Sie möglicherweise Ihre eigenen benutzerdefinierten Protokollanweisungen zu den ``nova-*``Diensten hinzufügen.

Die Quelldateien befinden sich in /usr/lib/python2.7/dist-packages/nova.

Um Protokollierungsanweisungen hinzuzufügen, sollte die folgende Zeile am Anfang der Datei stehen. Für die meisten Dateien sollten diese bereits vorhanden sein:

from nova.openstack.common import log as logging
LOG = logging.getLogger(__name__)

Um eine DEBUG-Protokollanweisung hinzuzufügen, würden Sie dies tun:

LOG.debug("This is a custom debugging statement")

Sie werden feststellen, dass allen vorhandenen Protokollnachrichten ein Unterstrich vorangestellt und z.B. von Klammern umgeben ist:

LOG.debug(_("Logging statement appears here"))

Diese Formatierung wird verwendet, um die Übersetzung von Logging-Meldungen in verschiedene Sprachen mit Hilfe der gettext Internationalization Library zu unterstützen. Sie müssen dies nicht für Ihre eigenen benutzerdefinierten Protokollmeldungen tun. Wenn Sie jedoch den Code wieder in das OpenStack-Projekt einbringen möchten, das Protokollanweisungen enthält, müssen Sie Ihre Protokollnachrichten mit Unterstrichen und Klammern umgeben.

RabbitMQ Web Management Interface oder rabbitmqctl

Abgesehen von Verbindungsausfällen sind RabbitMQ-Protokolldateien im Allgemeinen nicht nützlich für die Fehlersuche bei OpenStack-bezogenen Problemen. Stattdessen empfehlen wir Ihnen, die Web-Management-Schnittstelle von RabbitMQ zu verwenden. Aktivieren Sie es auf Ihrem Cloud-Controller:

# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart

Die Web-Management-Schnittstelle von RabbitMQ ist auf Ihrem Cloud-Controller unter http://localhost:55672 zugänglich.

Bemerkung

Ubuntu 12.04 installiert RabbitMQ Version 2.7.1, die Port 55672 verwendet. RabbitMQ Versionen 3.0 und höher verwenden stattdessen Port 15672. Sie können überprüfen, welche Version von RabbitMQ Sie auf Ihrem lokalen Ubuntu-Rechner ausgeführt haben, indem Sie dies tun:

$ dpkg -s rabbitmq-server | grep "Version:"
Version: 2.7.1-0ubuntu4

Eine Alternative zur Aktivierung der RabbitMQ-Webmanagement-Schnittstelle ist die Verwendung der Befehle rabbitmqctl. Zum Beispiel zeigt rabbitmqctl list_queues| grep cinder alle Nachrichten an, die in der Warteschlange verbleiben. Wenn es Nachrichten gibt, ist es ein mögliches Zeichen dafür, dass sich die Aschendienste nicht richtig mit rabbitmq verbunden haben und neu gestartet werden müssen.

Zu den zu überwachenden Elementen für RabbitMQ gehören die Anzahl der Elemente in jeder der Warteschlangen und die Verarbeitungszeitstatistiken für den Server.

Zentrale Verwaltung von Protokollen

Da Ihre Cloud höchstwahrscheinlich aus vielen Servern besteht, müssen Sie die Protokolle auf jedem dieser Server überprüfen, um ein Ereignis richtig zusammenzusetzen. Eine bessere Lösung ist es, die Protokolle aller Server an einen zentralen Ort zu senden, so dass auf sie alle aus dem gleichen Bereich zugegriffen werden kann.

Die Wahl der zentralen Protokollierungs-Engine hängt vom verwendeten Betriebssystem und den organisatorischen Anforderungen an die Protokollierungswerkzeuge ab.

Syslog-Auswahlen

Es gibt eine große Anzahl von Syslog-Engines, die jeweils unterschiedliche Fähigkeiten und Konfigurationsanforderungen haben.