Partager via

Dépannage

  • Article

Vous rencontrez des problèmes lors de la configuration de votre ordinateur ou de l’exécution d’un conteneur ? Nous avons créé un script PowerShell pour rechercher des problèmes courants. Donnez-lui un coup d’abord pour voir ce qu’il trouve et partager vos résultats.

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

La liste de tous les tests qu'elle exécute, ainsi que les solutions courantes, se trouve dans le fichier README pour le script.

Si cela n’aide pas à trouver la source du problème, veuillez poursuivre et publier la sortie de votre script sur le Container Forum. C’est le meilleur endroit pour obtenir de l’aide de la communauté, y compris les Windows Insiders et les développeurs.

Recherche des journaux de bord

Il existe plusieurs services utilisés pour gérer les conteneurs Windows. Les sections suivantes indiquent où obtenir les journaux d’activité pour chaque service.

Journaux de conteneurs Docker

La commande docker logs extrait les journaux d’activité d’un conteneur à partir de STDOUT/STDERR, les emplacements de dépôt du journal des applications standard pour les applications Linux. Les applications Windows ne se connectent généralement pas à STDOUT/STDERR ; au lieu de cela, ils se connectent à ETW, aux journaux d’é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 relie les journaux d’application Windows à STDOUT/STDERR. Le moniteur de journal est configuré via un fichier de configuration.

Utilisation du moniteur de journal

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

Le moniteur de journaux 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 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) peuvent être imbriquées avec Log Monitor similairement.

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 exec. Lorsque la forme d’exécution de l’instruction CMD/ENTRYPOINT est utilisée, SHELL n’est pas lancé et l’outil Moniteur de journal ne sera pas lancé à l’intérieur du conteneur.

Vous trouverez plus d’informations sur l’utilisation du wiki Log Monitor. Des exemples de fichiers de configuration pour les scénarios de conteneur Windows clés (IIS, etc.) peuvent être trouvés dans le dépôt GitHub . Vous trouverez un contexte supplémentaire dans ce billet de blog .

Moteur Docker

Le moteur Docker se connecte au journal des événements Windows « Application », plutôt qu’à un fichier. Ces journaux peuvent facilement être lus, triés et filtrés à l’aide de Windows PowerShell

Par exemple, cela affiche les journaux 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

Cela peut également être facilement redirigé vers un fichier CSV à lire par un autre outil ou 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 de débogage

Vous pouvez également activer la journalisation au niveau du débogage sur le moteur Docker. Cela peut être utile pour résoudre les problèmes si les journaux réguliers n’ont pas suffisamment de détails.

Tout d’abord, ouvrez une invite de commandes avec des privilèges élevés, puis exécutez la commande sc.exe qc docker obtenir la ligne de commande actuelle du 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 le BINARY_PATH_NAMEactuel et modifiez-le :

  • Ajouter un -D à la fin
  • Échapper chaque " avec \
  • Placez la commande entière dans «

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

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

À présent, redémarrez le service Docker

sc.exe stop docker
sc.exe start docker

Cela permet de journaliser beaucoup plus dans le journal des événements d’application. Il est donc préférable de supprimer l’option -D une fois que vous avez terminé la résolution des problèmes. Utilisez les mêmes étapes mentionnées ci-dessus sans -D et redémarrez le service pour désactiver la journalisation du débogage.

Une alternative à ce qui précède est d'exécuter le démon Docker en mode débogage depuis une invite PowerShell avec des privilèges élevés, en enregistrant directement la sortie dans un fichier.

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

Obtention d’un vidage de pile

En règle générale, cela n'est utile que si c'est explicitement demandé par le support Microsoft ou les développeurs Docker. Il peut être utilisé pour faciliter le diagnostic d'une situation où Docker semble être figé.

Téléchargez 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 l’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

Capture des journaux d’analyse/débogage de HCS

Pour activer les journaux d’analyse/de débogage pour Hyper-V Compute et les enregistrer dans 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

Capture du suivi détaillé de HCS

En règle générale, elles sont uniquement utiles si le support Microsoft les 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"

Fournissez HcsTrace.etl à votre contact de support.