Partager via

Dépannage

  • Article

Vous rencontrez des difficultés pour configurer votre ordinateur ou exécuter un conteneur ? Nous avons créé un script PowerShell pour rechercher les problèmes courants. Commencez par le tester pour voir ce qu’il trouve, puis partagez vos résultats.

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

La liste de tous les tests qu’il exécute avec des solutions courantes est disponible dans le fichier Lisez-moi du script.

Si cela ne permet pas de trouver la source du problème, publiez la sortie de votre script sur le Forum sur les conteneurs. C’est l’endroit idéal pour obtenir de l’aide de la Communauté, notamment des Windows Insiders et des développeurs Windows.

Où trouver les journaux

Plusieurs services sont utilisés pour gérer les conteneurs Windows. Les sections suivantes indiquent où obtenir les journaux de chaque service.

Journaux de conteneur Docker

La docker logs commande extrait les journaux d’un conteneur à partir de STDOUT/STDERR, les emplacements de dépôt de journaux d’applications standard pour les applications Linux. En général, les applications Windows ne se connectent pas à STDOUT/STDERR ; au lieu de cela, ils se connectent à ETW, aux journaux des événements ou aux fichiers journaux, entre autres.

Log Monitor, un outil opensource pris en charge par Microsoft, est désormais disponible sur github. Log Monitor ponte les journaux d’application Windows sur STDOUT/STDERR. Log Monitor est configuré via un fichier de configuration.

Utilisation de Log Monitor

LogMonitor.exe et LogMonitorConfig.json doivent être inclus dans le même répertoire LogMonitor.

Log Monitor peut être utilisé dans un modèle d’utilisation shell :

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

Ou un modèle d’utilisation d’ENTRYPOINT :

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

Les deux exemples d’utilisation encapsulent l’application ping.exe. Autres applications (telles que IIS. ServiceMonitor) peut être imbriqué avec Log Monitor de la même manière :

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 démarre l’application encapsulée en tant que processus enfant et surveille la sortie STDOUT de l’application.

Notez que dans le modèle d’utilisation shell, l’instruction CMD/ENTRYPOINT doit être spécifiée dans le formulaire SHELL et non dans le formulaire d’exécution. Lorsque le formulaire d’exécution de l’instruction CMD/ENTRYPOINT est utilisé, SHELL n’est pas lancé et l’outil Log Monitor n’est pas lancé à l’intérieur du conteneur.

Vous trouverez plus d’informations sur l’utilisation sur le wiki Log Monitor. Vous trouverez des exemples de fichiers de configuration pour les principaux scénarios de conteneur Windows (IIS, etc.) dans le dépôt github. Vous trouverez un contexte supplémentaire dans ce billet de blog.

Moteur Docker

Les enregistrements du moteur Docker sont consignés dans le journal des événements des applications Windows, plutôt que dans un fichier. Ces enregistrements peuvent facilement être lus, triés et filtrés à l’aide de Windows PowerShell

Par exemple, cette commande affiche les enregistrements du moteur Docker des 5 dernières minutes en commençant par le plus ancien.

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

Ces enregistrements peuvent aussi être facilement redirigés dans un fichier CSV pour être lus par un autre outil ou une feuille de calcul.

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

Activation de la journalisation du débogage

Vous pouvez également activer la journalisation au niveau du débogage sur le moteur Docker. Cette opération peut être utile pour la résolution des problèmes si les journaux ordinaires ne contiennent pas suffisamment de détails.

Tout d’abord, ouvrez une invite de commandes avec élévation de privilèges, puis exécutez sc.exe qc docker pour obtenir la ligne de commande actuelle pour le service Docker. Exemple :

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

Prenez la valeur BINARY_PATH_NAME actuelle, puis modifiez-la :

  • Ajoutez -D à la fin
  • Placez chaque " dans une séquence d’échappement avec \
  • Placez l’ensemble de la commande entre "

Exécutez ensuite la commande sc.exe config docker binpath= suivie de la nouvelle chaîne. Par exemple :

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

Redémarrez maintenant le service Docker

sc.exe stop docker
sc.exe start docker

Beaucoup plus d’informations sont ainsi consignées dans le journal des événements de l’application. Il est donc préférable de supprimer l’option -D une fois la résolution des problèmes terminée. Suivez la même procédure que celle mentionnée ci-dessus sans -D et redémarrez le service pour désactiver la journalisation du débogage.

Vous pouvez aussi exécuter le démon Docker en mode débogage à partir d’une invite PowerShell avec élévation de privilèges, capturant ainsi la sortie directement dans un fichier.

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

Obtention d’un vidage de la pile

En règle générale, cela n’est utile que si le support Microsoft ou les développeurs Docker le demandent explicitement. Il peut être utilisé pour faciliter le diagnostic d’une situation dans laquelle docker semble s’être suspendu.

Télécharger docker-signal.exe.

Usage :

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

Le fichier de sortie se trouve dans le répertoire racine de données dans lequel Docker s’exécute. Le répertoire par défaut est C:\ProgramData\Docker. Le répertoire réel peut être confirmé en exécutant docker info -f "{{.DockerRootDir}}".

Le fichier sera goroutine-stacks-<timestamp>.log.

Notez que goroutine-stacks*.log ne contient pas d’informations personnelles.

Service de calcul hôte

Le moteur Docker dépend d’un service de calcul hôte spécifique à Windows. Il a des journaux distincts :

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

Elles sont visibles dans observateur d'événements et peuvent également être interrogées avec PowerShell.

Par exemple :

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

Enregistrement des journaux d’analyse/débogage HCS

Pour activer les journaux d’analyse/débogage de calcul Hyper-V et les enregistrer sur hcslog.evtx.

# 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

Capturer le suivi HCS en clair

En règle générale, cela n'est utile que si le support Microsoft le demande.

Télécharger HcsTraceProfile.wprp

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

# <reproduce your issue>

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

Fournir HcsTrace.etl à votre contact de support.