[ English | Indonesia | Deutsch | 日本語 ]
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.
Knotentyp |
Dienst |
Protokollstandort |
|---|---|---|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
|
|
Cloud controller |
horizon |
|
Alle Knoten |
misc (swift, dnsmasq) |
|
Compute-Knoten |
libvirt |
|
Compute-Knoten |
Konsole (Boot-Up-Meldungen) für VM-Instanzen: |
|
Blockspeicher-Knoten |
cinder-volume |
|
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.
