Azure Automation : diagnostiquer un Hybrid Runbook Worker qui ne prend plus les jobs

Un job Azure Automation reste en file d’attente, échoue avec un worker indisponible ou passe en Running sans produire de sortie. Le runbook fonctionnait la veille. La tentation est immédiate : relancer le job, redémarrer la VM, réinstaller l’extension ou ajouter un worker. Ces actions peuvent restaurer le service, mais elles effacent aussi la distinction essentielle entre un défaut de distribution, un runtime bloqué et un script qui a déjà commencé à modifier la production.

Le cas d’usage est un groupe de Hybrid Runbook Workers basés sur extension, hébergés sur des VM Azure ou des serveurs Azure Arc. Ils exécutent des tâches qui doivent atteindre un réseau privé : rotation locale, maintenance applicative, collecte, redémarrage borné ou changement d’infrastructure. L’objectif du runbook est de décider si le job peut être repris, s’il faut réparer le worker, réduire la charge, corriger le réseau ou conserver le job bloqué jusqu’à preuve de son état.

Figer l’incident avant toute relance

Commencez par conserver l’identifiant du job, le runbook publié, ses paramètres, le groupe ciblé et les heures UTC. Un job Queued, Running, Failed ou Suspended ne raconte pas la même panne. Notez aussi les effets déjà possibles : le job peut ne produire aucune sortie tout en ayant appelé une API, écrit un fichier ou redémarré un service.

Incident: inc-20260814-017
Automation Account: aa-platform-prod
Runbook: Invoke-PrivateMaintenance
Job ID: 00000000-0000-0000-0000-000000000000
Worker group: hrw-prod-weu
Requested at: 2026-08-14T15:10:00Z
Last known output: none
Expected target: srv-app-07 / service api-orders

Questions avant action
Le job a-t-il ete distribue a un worker ?
Un processus de runtime a-t-il demarre ?
Une ecriture distante ou locale a-t-elle deja eu lieu ?
Le meme groupe prend-il encore des jobs canary ?
Quel changement recent touche VM, Arc, extension, proxy ou firewall ?

Interdits temporaires
Pas de relance du job metier
Pas de reinstallation de l'extension
Pas d'elargissement RBAC ou firewall
Pas de suppression des logs locaux

Récupérez les flux Output, Error, Warning et Verbose, même s’ils sont vides. L’absence de sortie est une donnée : elle peut indiquer que le worker n’a jamais pris le job, que le processus n’a pas démarré ou que le script n’émet rien avant sa première action.

Séparer distribution et exécution

Le premier embranchement est simple. Si aucun worker n’a pris le job, examinez le groupe, le heartbeat, l’extension et la connectivité vers Azure Automation. Si un worker l’a pris, examinez le runtime, les modules, le compte d’exécution, les ressources locales et les dépendances du script.

Queued puis erreur worker indisponible
Priorite: heartbeat, service hwd/HybridWorkerService, extension, sortie TCP 443

Running sans premiere trace applicative
Priorite: lancement du runtime, quota CPU, compte local, module ou binaire

Running avec checkpoint applicatif
Priorite: dependance cible, verrou, timeout, idempotence avant stop

Failed ou Suspended avec sortie
Priorite: contrat du runbook, identite, permissions, code retour

Plusieurs jobs touches sur le meme groupe
Priorite: worker, capacite ou chemin reseau partage

Un seul runbook touche sur plusieurs workers
Priorite: script, module, parametre ou dependance specifique

Cette matrice empêche de traiter tous les symptômes comme un problème de VM. Un worker sain peut distribuer correctement un script dont le module manque. À l’inverse, publier une nouvelle version du runbook ne corrigera pas un service local arrêté ou un proxy qui bloque le point de terminaison Automation.

Vérifier le groupe, le worker et l’extension

Un Hybrid Runbook Worker basé sur extension dépend de l’état de la machine, de son identité managée système, de l’extension et de son enregistrement dans le groupe. Comparez tous les workers du groupe au lieu d’en inspecter un seul : version d’extension, état de provisioning, dernier ping, OS, charge et changements récents.

RG="rg-automation-prod"
VM="vm-hrw-prod-01"

az vm get-instance-view --resource-group "$RG" --name "$VM" --query '{power:instanceView.statuses[].displayStatus,extensions:instanceView.extensions[].{name:name,status:statuses[0].displayStatus,message:statuses[0].message}}' --output json

az vm identity show --resource-group "$RG" --name "$VM" --query '{type:type,principalId:principalId,tenantId:tenantId}' --output json

Pour une machine Arc, faites la même lecture sur la ressource Connected Machine et ses extensions. Ne confondez pas deux identités : l’identité de la machine permet notamment à l’extension de fonctionner, tandis que le runbook doit authentifier explicitement ses propres actions. Avant d’ajouter un rôle, prouvez l’identité réellement obtenue par le script et le scope exact de l’autorisation manquante.

Le métrique HybridWorkerPing aide à repérer une rupture de heartbeat. Comparez la fenêtre de l’incident avec la santé de la VM et les changements d’extension. Un worker arrêté longtemps, supprimé du groupe ou sans ping ne doit pas être réparé en rejouant les jobs qui le ciblaient.

Prouver le chemin sortant vers Azure Automation

Le worker initie une connexion sortante en HTTPS. Une VM joignable en RDP ou SSH peut donc être incapable de recevoir des jobs. Récupérez la valeur AutomationHybridServiceUrl dans les propriétés du compte Automation ou dans les paramètres de l’extension, puis testez ce nom précis depuis la machine. Un test depuis le poste d’un administrateur ne prouve rien sur le chemin du worker.

$AutomationHost = "replace-with-account-endpoint.azure-automation.net"

Resolve-DnsName $AutomationHost
Test-NetConnection $AutomationHost -Port 443

Get-NetIPConfiguration | Select-Object InterfaceAlias,IPv4Address,DNSServer
Get-NetRoute -AddressFamily IPv4 |
Where-Object DestinationPrefix -eq "0.0.0.0/0" |
Select-Object InterfaceAlias,NextHop,RouteMetric

# Conserver aussi les refus proxy, firewall et TLS sur la meme fenetre UTC.

Contrôlez DNS, proxy système, inspection TLS, UDR, NSG et firewall sans ouvrir globalement 443. Si une politique n’autorise que des FQDN ou des service tags, comparez la destination effective aux règles déployées. Le résultat attendu n’est pas seulement « le port répond », mais « le worker résout le bon nom, sort par le chemin prévu et termine TLS sans interception incompatible ».

Lire les journaux locaux avant de redémarrer

Sur Windows, vérifiez HybridWorkerService, le journal Microsoft-SMA/Operational et les logs de l’extension sous C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows*. Sur Linux, vérifiez hwd.service, /home/hweautomation/run/worker.log et /var/log/azure/Microsoft.Azure.Automation.HybridWorker.HybridWorkerForLinux.

sudo systemctl status hwd.service --no-pager
sudo journalctl -u hwd.service --since "2026-08-14 14:55:00 UTC" --until "2026-08-14 15:30:00 UTC" --no-pager

sudo tail -n 250 /home/hweautomation/run/worker.log
sudo find /var/log/azure/Microsoft.Azure.Automation.HybridWorker.HybridWorkerForLinux -type f -mmin -180 -maxdepth 3 -print

ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 25
df -h
free -m

Copiez les journaux et leur empreinte avant un restart. Cherchez une rupture de ping, une erreur de téléchargement du job, un échec de création de processus, une limite CPU, un manque de disque, un module absent ou un refus local. Sur Linux, le runtime d’extension utilise le compte hweautomation : une commande qui fonctionne en root ne prouve pas que le job peut lire le fichier, charger le binaire ou écrire dans le répertoire attendu.

Distinguer saturation, runtime et identité

Chaque worker actif interroge périodiquement le service et prend un nombre borné de jobs. Une rafale de schedules peut donc ressembler à une panne alors que le groupe est saturé ou déséquilibré. Mesurez les arrivées de jobs, leur âge en file, les exécutions simultanées, CPU, mémoire et disque. Ajouter un worker n’est justifié que si le heartbeat est sain, le chemin réseau est prouvé et la demande dépasse réellement la capacité.

Si le job est pris mais bloque ensuite, comparez l’environnement local avec le contrat du runbook : version de PowerShell ou Python, modules, variables d’environnement, compte local, accès au chemin privé et identité Azure. Ne réinstallez pas l’extension pour corriger un module applicatif ; ne donnez pas Contributor pour masquer une identité différente de celle attendue.

Cause retenue: service hwd arrete apres mise a jour OS
Preuves
HybridWorkerPing absent depuis 14:58Z
Aucun job distribue au worker apres 14:58Z
Sortie TCP 443 et resolution DNS conformes
journalctl montre l'echec de demarrage du service
Les autres workers du groupe prennent un job canary

Cause ecartee: runbook
Meme version publiee executee par le canary
Aucun effet metier observe sur le job bloque

Action bornee
Corriger l'unite systemd puis redemarrer hwd.service
Ne pas relancer le job metier avant validation du worker

Valider avec un canary sans effet métier

Après correction, n’utilisez pas le job incident comme test. Publiez ou conservez un runbook canary qui écrit un identifiant de corrélation, expose le nom du worker et du runtime, teste une dépendance non destructive, puis termine. Ciblez le même groupe et observez un cycle complet : prise du job, démarrage, sortie, fin et nouveau heartbeat.

Le canary doit échouer fermé. Il ne redémarre aucun service, ne modifie aucun rôle et ne traite aucune file métier. S’il passe sur un worker mais pas sur un autre, gardez le worker défaillant hors rotation et corrigez-le séparément. S’il échoue partout, revenez au service partagé : compte Automation, groupe, réseau ou publication du runbook.

Décider reprise, réparation ou rollback

La remise en service se termine par une décision explicite. Avant toute relance métier, recherchez les effets partiels avec l’identifiant du job et la fenêtre UTC. Un job non idempotent n’est relancé que si l’état cible prouve qu’aucune première action n’a abouti ou si une clé d’idempotence protège la reprise.

Reprendre le job
Worker et heartbeat valides
Canary termine sur le meme groupe
Aucun effet partiel ou reprise idempotente prouvee
Identite, modules et dependances conformes

Reparer sans rejouer
Extension, service local ou sortie reseau explique la panne
Etat metier du job incident reste incertain
Les preuves sont conservees avant restart

Retirer un worker de la rotation
Defaut limite a une machine
Les autres workers absorbent la charge
Aucun elargissement de droits ou de firewall requis

Rollback
Revenir sur la derniere version d'extension, regle proxy ou configuration OS prouvee
Restaurer le chemin sortant precedent
Rejouer le canary puis verifier HybridWorkerPing
Garder le job metier bloque si ses effets restent inconnus

Conclusion

Un Hybrid Runbook Worker qui ne prend plus les jobs doit être diagnostiqué comme une chaîne de production : distribution Azure Automation, heartbeat, extension, service local, sortie HTTPS, capacité, runtime, identité et dépendance métier. Redémarrer ou relancer trop tôt mélange ces plans et peut rejouer une action déjà partiellement exécutée.

La bonne sortie d’incident est vérifiable : une cause appuyée par les journaux, une correction bornée, un canary sans effet métier, puis une décision documentée sur le job initial. Le worker redevient exploitable lorsque la prise de job est prouvée et que la reprise reste maîtrisée, pas simplement lorsque son statut repasse au vert.