Freigeben über


Problembehandlung

Haben Sie Probleme beim Einrichten Ihres Computers oder beim Ausführen eines Containers? Wir haben ein PowerShell-Skript entwickelt, das nach häufigen Problemen sucht. Bitte probieren Sie es erst aus, um zu sehen, was es findet, und geben Sie Ihre Ergebnisse frei.

Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression

Eine Liste aller Tests, die das Skript ausführt sowie allgemeine Lösungen, finden Sie in der Readme-Datei des Skripts.

Wenn das nicht hilft, suchen Sie die Quelle des Problems, posten Sie die Ausgabe Ihres Skripts im Containerforum. Dies ist der beste Ort, um Hilfe von der Community zu erhalten, zu der auch Windows Insiders und Entwickler gehören.

Suchen von Protokollen

Es gibt mehrere Dienste, die zum Verwalten von Windows-Containern verwendet werden. Im nächsten Abschnitt wird gezeigt, wie Sie Protokolle für jeden Dienst erhalten.

Docker-Containerprotokolle

Der docker logs Befehl ruft die Protokolle eines Containers von STDOUT/STDERR ab, den Standardspeicherorten des Anwendungsprotokolls für Linux-Anwendungen. Windows-Anwendungen melden sich in der Regel nicht bei STDOUT/STDERR. stattdessen melden sie sich unter anderem bei ETW, Ereignisprotokollen oder Protokolldateien an.

Log Monitor, ein von Microsoft unterstütztes OpenSource-Tool, ist jetzt auf github verfügbar. Protokollmonitor überbrückt Windows-Anwendungsprotokolle mit STDOUT/STDERR. Der Protokollmonitor wird über eine Konfigurationsdatei konfiguriert.

Protokollüberwachungsverwendung

LogMonitor.exe und LogMonitorConfig.json sollten beide im selben LogMonitor-Verzeichnis enthalten sein.

Protokollmonitor kann entweder in einem SHELL-Nutzungsmuster verwendet werden:

SHELL ["C:\\LogMonitor\\LogMonitor.exe", "cmd", "/S", "/C"]
CMD c:\windows\system32\ping.exe -n 20 localhost

Oder ein ENTRYPOINT-Verwendungsmuster:

ENTRYPOINT C:\LogMonitor\LogMonitor.exe c:\windows\system32\ping.exe -n 20 localhost

Beide Beispielverwendungen umschließen die ping.exe-Anwendung. Andere Anwendungen (z . B. IIS). ServiceMonitor) kann mit Log Monitor auf ähnliche Weise geschachtelt werden:

COPY LogMonitor.exe LogMonitorConfig.json C:\LogMonitor\
WORKDIR /LogMonitor
SHELL ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe"]

# Start IIS Remote Management and monitor IIS
ENTRYPOINT      Start-Service WMSVC; `
                    C:\ServiceMonitor.exe w3svc;

Log Monitor startet die umschlossene Anwendung als untergeordneten Prozess und überwacht die STDOUT-Ausgabe der Anwendung.

Beachten Sie, dass im SHELL-Verwendungsmuster die CMD/ENTRYPOINT-Anweisung im SHELL-Formular und nicht im Exec-Formular angegeben werden sollte. Wenn die Ausführungsform der CMD/ENTRYPOINT-Anweisung verwendet wird, wird SHELL nicht gestartet, und das Protokollüberwachungstool wird nicht im Container gestartet.

Weitere Informationen zur Verwendung finden Sie im Log Monitor-Wiki. Beispielkonfigurationsdateien für wichtige Windows-Containerszenarien (IIS usw.) finden Sie im Github-Repository. Zusätzlichen Kontext finden Sie in diesem Blogbeitrag.

Docker-Engine

Die Docker-Engine protokolliert in das Windows-„Anwendungsereignisprotokoll“, statt in eine Datei. Diese Protokolle können mithilfe von Windows PowerShell einfach gelesen, sortiert und gefiltert werden.

Beispielsweise werden dadurch die Protokolle der Docker-Engine der letzten fünf Minuten angezeigt, angefangen mit dem ältesten.

Get-EventLog -LogName Application -Source Docker -After (Get-Date).AddMinutes(-5) | Sort-Object Time

Dies könnte auch einfach in eine CSV-Datei weitergeleitet werden, um dort von einem anderen Tool oder Arbeitsblatt gelesen zu werden.

Get-EventLog -LogName Application -Source Docker -After (Get-Date).AddMinutes(-30)  | Sort-Object Time | Export-CSV ~/last30minutes.CSV

Aktivieren der Debugprotokollierung

Sie können auch die Protokollierung auf Debugebene in der Docker-Engine aktivieren. Dies kann für die Problembehandlung hilfreich sein, wenn reguläre Protokolle nicht genügend Informationen enthalten.

Öffnen Sie zunächst eine Eingabeaufforderung mit erhöhten Rechten, führen Sie dann sc.exe qc docker aus, um die aktuelle Befehlszeile für den Docker-Dienst zu erhalten. Beispiel:

C:\> sc.exe qc docker
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: docker
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : "C:\Program Files\Docker\dockerd.exe" --run-service
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Docker Engine
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

Modifizieren Sie den aktuellen BINARY_PATH_NAME:

  • Fügen Sie -D am Ende hinzu
  • Fügen Sie für " das Escapezeichen \ hinzu
  • Schließen Sie den gesamten Befehl in Anführungszeichen (") ein

Führen Sie anschließend sc.exe config docker binpath=, gefolgt von der neuen Zeichenfolge, aus. Beispiel:

sc.exe config docker binpath= "\"C:\Program Files\Docker\dockerd.exe\" --run-service -D"

Starten Sie nun den Docker-Dienst neu.

sc.exe stop docker
sc.exe start docker

Dadurch wird viel mehr im Anwendungsereignisprotokoll protokolliert. Deshalb ist es von Vorteil, die Option -D zu entfernen, wenn Sie mit der Problembehandlung fertig sind. Führen Sie die gleichen Schritte wie oben aus, jedoch ohne -D, und starten Sie den Dienst neu, um die Debugprotokollierung zu deaktivieren.

Eine andere Möglichkeit ist, den Docker Daemon im Debugmodus mithilfe einer PowerShell-Eingabeaufforderung mit erhöhten Rechten auszuführen, die die Ausgabe direkt in einer Datei aufzeichnen.

sc.exe stop docker
<path\to\>dockerd.exe -D > daemon.log 2>&1

Abrufen von Stapelabbild

Im Allgemeinen ist dies nur nützlich, wenn dies explizit vom Microsoft-Support oder docker-Entwicklern angefordert wird. Es kann verwendet werden, um die Diagnose einer Situation zu unterstützen, in der Docker scheinbar aufgehängt zu sein scheint.

Herunterladen von Docker-Signal.exe.

Syntax:

docker-signal --pid=$((Get-Process dockerd).Id)

Die Ausgabedatei befindet sich im Datenstammverzeichnis, in dem Docker ausgeführt wird. Das Standardverzeichnis ist C:\ProgramData\Docker. Das aktuelle Verzeichnis kann durch Ausführen von docker info -f "{{.DockerRootDir}}" bestätigt werden.

Die Datei ist goroutine-stacks-<timestamp>.log.

Beachten Sie, dass goroutine-stacks*.log keine persönlichen Informationen enthält.

Hostcomputedienst

Das Docker-Modul ist von einem Windows-spezifischen Hostcomputedienst abhängig. Dieser verfügt über separate Protokolle:

  • Microsoft-Windows-Hyper-V-Compute-Admin
  • Microsoft-Windows-Hyper-V-Compute-Operational

Sie sind in Ereignisanzeige sichtbar und können auch mit PowerShell abgefragt werden.

Beispiel:

Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Compute-Admin
Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Compute-Operational

Erfassen von HCS Analyse-/Debug-Protokollen

Um Analyse-/Debug-Protokolle für Hyper-V-Compute zu aktivieren und auf hcslog.evtx zu speichern.

# Enable the analytic logs
wevtutil.exe sl Microsoft-Windows-Hyper-V-Compute-Analytic /e:true /q:true

# <reproduce your issue>

# Export to an evtx
wevtutil.exe epl Microsoft-Windows-Hyper-V-Compute-Analytic <hcslog.evtx>

# Disable
wevtutil.exe sl Microsoft-Windows-Hyper-V-Compute-Analytic /e:false /q:true

Aufzeichnen ausführlicher HCS-Protokollierung

In der Regel ist sie nur dann nützlich, wenn sie vom Microsoft Support angefordert wird.

HcsTraceProfile.wprp herunterladen

# Enable tracing
wpr.exe -start HcsTraceProfile.wprp!HcsArgon -filemode

# <reproduce your issue>

# Capture to HcsTrace.etl
wpr.exe -stop HcsTrace.etl "some description"

Bereitstellen von HcsTrace.etl an die Supportkontaktperson.