Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les métriques de la plateforme de comptes Azure Batch fournissent des informations sur les pools, nœuds, cœurs, jobs et tâches. Pour surveiller les performances du système d’exploitation invité, telles que l’utilisation du CPU, de la mémoire, du disque et du réseau, installez Azure Monitor Agent (AMA) sur les nœuds de calcul du pool.
Cet article montre comment :
- Créez un pool Batch avec une identité managée attribuée par l’utilisateur et un AMA.
- Créez une règle de collecte de données (DCR) pour les compteurs de performance Linux et le Syslog.
- Associez le DCR à la ressource du pool de batch.
- Vérifiez les données dans Log Analytics et Azure Monitor Metrics.
Les exemples utilisent Azure CLI et un pool Linux. La même architecture prend en compte les pools Windows avec l’extension Windows AMA et les sources de données Windows.
Important
La surveillance des nœuds de calcul du pool Batch avec AMA n’est prise en charge que pour les comptes Batch qui utilisent le mode d’allocation du pool abonnement utilisateur. En mode allocation de pool de services batch, les nœuds de calcul sont créés dans des abonnements gérés par lots auxquels les clients ne peuvent pas accéder.
Comment fonctionne la surveillance des nœuds
Un pool Batch surveillé utilise les ressources suivantes :
- Un compte Batch en mode allocation de pool d’abonnement utilisateur.
- Un pool Batch qui possède une identité managée attribuée par l’utilisateur.
- L’extension Azure Monitor Agent installée lors de la création du pool.
- Un DCR qui spécifie les données à collecter et les destinations.
- Une association DCR dont la cible est la ressource Azure Resource Manager du Batch pool.
- Un espace de travail Log Analytics pour les données de journal et, en option, Azure Monitor Metrics pour les indicateurs invités.
Associez le DCR à l’identifiant de ressource du pool Batch :
/subscriptions/<subscription-id>/resourceGroups/<resource-group>/
providers/Microsoft.Batch/batchAccounts/<batch-account>/pools/<pool-name>
N’associez pas le DCR uniquement à l’ensemble d’échelle de la machine virtuelle que Batch crée pour le pool. Le lot gère le cycle de vie de cet ensemble d’échelle. Lorsqu’un pool évolue vers zéro nœud, Batch peut supprimer le jeu d’échelle et en créer un nouveau lors d’un redimensionnement ultérieur.
Les enregistrements Log Analytics conservent l’identifiant de ressource de la ressource de calcul créée par Batch. Les métriques de l’invité sont disponibles sur le groupe identique de machines virtuelles actuel créé par Batch dans l’espace de noms azure.vm.linux.guestmetrics pour Linux, ou dans l’espace de noms Virtual Machine Guest (Windows) pour Windows.
Prerequisites
Avant de commencer, vous avez besoin des éléments suivants :
- Un compte Azure Batch en mode d’allocation du pool d’abonnement utilisateur.
- Permission de créer des pools en utilisant le plan de gestion Batch.
- Un espace de travail Log Analytics.
- Une identité gérée attribuée par l’utilisateur dans le même tenant Microsoft Entra que le compte Batch.
- Permission de créer des DCR et des associations DCR. Pour plus de détails, voir Créer et modifier les règles de collecte de données dans Azure Monitor.
- Azure CLI installée et authentifiée à l’abonnement.
Créez le DCR, l’espace de travail Log Analytics et le pool de batch dans la même région Azure. Si le pool utilise un réseau virtuel avec un accès sortant restreint, examinez les exigences réseau d’Azure Monitor Agent.
Tip
Les pools avec extensions doivent utiliser la configuration de la machine virtuelle. Vous ne pouvez pas ajouter d’extensions à une piscine existante. Pour ajouter, supprimer ou mettre à jour un AMA, créez un nouveau pool. Pour plus d’informations, voir Utiliser les extensions avec les pools Batch.
Définir des variables d’environnement
Définissez des variables pour vos ressources. Remplacez les valeurs d’espace réservé.
subscriptionId="<subscription-id>"
resourceGroup="<resource-group>"
location="<location>"
batchAccount="<batch-account-name>"
poolName="<pool-name>"
workspaceName="<log-analytics-workspace-name>"
identityName="<managed-identity-name>"
dcrName="<data-collection-rule-name>"
az account set --subscription "$subscriptionId"
identityId=$(az identity show \
--resource-group "$resourceGroup" \
--name "$identityName" \
--query id \
--output tsv)
workspaceId=$(az monitor log-analytics workspace show \
--resource-group "$resourceGroup" \
--workspace-name "$workspaceName" \
--query id \
--output tsv)
batchAccountId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Batch/batchAccounts/$batchAccount"
poolResourceId="$batchAccountId/pools/$poolName"
dcrId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Insights/dataCollectionRules/$dcrName"
Créer une règle de collecte de données
La règle de collecte de données (DCR) suivante collecte les compteurs de performance Linux courants toutes les 60 secondes. Il envoie les compteurs à la fois vers la table Perf de Log Analytics et vers Azure Monitor Metrics. Il envoie également à Log Analytics des enregistrements Syslog d’avertissement et de gravité supérieure.
Azure Monitor Metrics comme destination des compteurs de performances des invités est en préversion. Pour les limitations actuelles, voir Collecter les compteurs de performance avec Azure Monitor Agent.
Créez un fichier nommé dcr.json. Remplacez <location> et <workspace-resource-id> par vos valeurs.
{
"location": "<location>",
"kind": "Linux",
"properties": {
"dataSources": {
"performanceCounters": [
{
"name": "batchNodePerformance",
"streams": [
"Microsoft-Perf",
"Microsoft-InsightsMetrics"
],
"samplingFrequencyInSeconds": 60,
"counterSpecifiers": [
"\\Processor(*)\\% Processor Time",
"\\Processor(*)\\% User Time",
"\\Processor(*)\\% Privileged Time",
"\\Processor(*)\\% Idle Time",
"\\Memory\\% Available Memory",
"\\Memory\\Used Memory MBytes",
"\\Memory\\% Used Memory",
"\\Logical Disk(*)\\% Free Space",
"\\Logical Disk(*)\\Free Megabytes",
"\\Logical Disk(*)\\Disk Reads/sec",
"\\Logical Disk(*)\\Disk Writes/sec",
"\\Logical Disk(*)\\Disk Read Bytes/sec",
"\\Logical Disk(*)\\Disk Write Bytes/sec",
"\\Network(*)\\Total Bytes Transmitted",
"\\Network(*)\\Total Bytes Received",
"\\Network(*)\\Total Bytes",
"\\System\\Uptime"
]
}
],
"syslog": [
{
"name": "batchNodeSyslog",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"auth",
"authpriv",
"cron",
"daemon",
"kern",
"syslog",
"user"
],
"logLevels": [
"Warning",
"Error",
"Critical",
"Alert",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"name": "batchMonitorWorkspace",
"workspaceResourceId": "<workspace-resource-id>"
}
],
"azureMonitorMetrics": {
"name": "azureMonitorMetrics-default"
}
},
"dataFlows": [
{
"streams": [
"Microsoft-Perf"
],
"destinations": [
"batchMonitorWorkspace"
]
},
{
"streams": [
"Microsoft-InsightsMetrics"
],
"destinations": [
"azureMonitorMetrics-default"
]
},
{
"streams": [
"Microsoft-Syslog"
],
"destinations": [
"batchMonitorWorkspace"
]
}
]
}
}
Créez ou mettez à jour le DCR :
az rest \
--method put \
--url "https://management.azure.com${dcrId}?api-version=2022-06-01" \
--body @dcr.json
Pour des informations sur la sélection des compteurs et le contrôle du coût d’ingestion, voir Collecter les compteurs de performance avec l’agent Azure Monitor.
Créer un pool avec Azure Monitor Agent
Créez un fichier nommé pool.json. L’exemple suivant utilise Ubuntu 22.04 et installe l’extension Linux AMA. Remplacez <managed-identity-resource-id> par la valeur de $identityId.
{
"name": "<pool-name>",
"type": "Microsoft.Batch/batchAccounts/pools",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"<managed-identity-resource-id>": {}
}
},
"properties": {
"vmSize": "STANDARD_D2S_V3",
"taskSlotsPerNode": 1,
"taskSchedulingPolicy": {
"nodeFillType": "Pack"
},
"deploymentConfiguration": {
"virtualMachineConfiguration": {
"imageReference": {
"publisher": "canonical",
"offer": "0001-com-ubuntu-server-jammy",
"sku": "22_04-lts",
"version": "latest"
},
"nodeAgentSkuId": "batch.node.ubuntu 22.04",
"extensions": [
{
"name": "AzureMonitorAgent",
"publisher": "Microsoft.Azure.Monitor",
"type": "AzureMonitorLinuxAgent",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"enableAutomaticUpgrade": true,
"settings": {
"authentication": {
"managedIdentity": {
"identifier-name": "mi_res_id",
"identifier-value": "<managed-identity-resource-id>"
}
}
}
}
]
}
},
"scaleSettings": {
"fixedScale": {
"targetDedicatedNodes": 1,
"targetLowPriorityNodes": 0,
"resizeTimeout": "PT15M"
}
}
}
}
Créez le pool en utilisant l’API de gestion par lots :
az rest \
--method put \
--url "https://management.azure.com${poolResourceId}?api-version=2024-07-01" \
--body @pool.json
Pour un pool Windows, utilisez :
- Type d’extension
AzureMonitorWindowsAgent. - Une image Windows et un SKU d’agent de nœud Batch compatible.
- Un DCR Windows avec
kinddéfini àWindows. - Compteurs de performance Windows et, si nécessaire, collecte d’événements Windows au lieu de Syslog.
N'utilisez pas un seul DCR pour les compteurs Windows et Linux. Certains noms de compteurs peuvent correspondre à la même métrique et provoquer une collecte en double.
Associez le DCR au pool Batch
Créez l’association au niveau de la ressource de pool Batch :
az monitor data-collection rule association create \
--name "batch-pool-monitoring" \
--resource "$poolResourceId" \
--rule-id "$dcrId"
Confirmez l’association :
az monitor data-collection rule association list \
--resource "$poolResourceId" \
--output table
L’association reste associée au pool lorsque des nœuds sont retirés ou remplacés. Ne le remplacez pas par une association qui vise uniquement l’ensemble d’échelles de machines virtuelles créé par Batch.
Vérifier la collecte de l’agent et des journaux
Laissez jusqu’à cinq minutes après que le nœud ait atteint l’état d’inactivité pour que les premiers enregistrements arrivent.
Vérifiez le battement de cœur de l’agent
Exécutez la requête suivante dans l’espace de travail Log Analytics :
Heartbeat
| where TimeGenerated > ago(30m)
| summarize
Samples = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
AgentVersion = any(Version)
by Computer, _ResourceId
Un agent opérationnel envoie normalement un battement de cœur par minute.
Vérifier les compteurs de performance
Perf
| where TimeGenerated > ago(30m)
| summarize
Samples = count(),
Average = avg(CounterValue),
P95 = percentile(CounterValue, 95),
Maximum = max(CounterValue)
by Computer, ObjectName, CounterName, InstanceName
| order by ObjectName asc, CounterName asc
Les compteurs logiques de disque Linux incluent plusieurs instances de points de montage. Appliquez un filtre sur InstanceName lors de la création de graphiques ou d’alertes afin que les points de montage en lecture seule et les points de montage temporaires ne faussent pas le résultat.
Vérifier syslog
Syslog
| where TimeGenerated > ago(30m)
| project
TimeGenerated,
Computer,
Facility,
SeverityLevel,
ProcessName,
SyslogMessage,
_ResourceId
| order by TimeGenerated desc
Afficher les métriques des invités
Si le DCR envoie le Microsoft-InsightsMetrics flux vers la destination Azure Monitor Metrics, les métriques invitées apparaissent sur l’ensemble d’échelles de machines virtuelles créées par lots en cours.
- Dans le portail Azure, ouvrez le groupe de machines virtuelles identiques qu’a créé Batch pour le pool.
- Sélectionnez Métriques.
- Pour l’espace de noms métrique, sélectionnez
azure.vm.linux.guestmetricsLinux ou Invité de machine virtuelle (Windows) pour Windows. - Sélectionnez une métrique et une agrégation.
Vous pouvez localiser l’ID actuel de la ressource de calcul à partir des enregistrements récents Perf :
Perf
| where TimeGenerated > ago(30m)
| summarize arg_max(TimeGenerated, _ResourceId) by Computer
Note
Lorsqu’un pool évolue vers zéro nœud, Batch peut supprimer son ensemble d’échelle de machine virtuelle de soutien. La ressource de la métrique invitée n’est pas disponible tant que le jeu d’échelle n’existe pas. Les données Log Analytics déjà collectées dans l’espace de travail restent disponibles selon les paramètres de conservation de l’espace de travail.
Surveillez les métriques de la plateforme Batch avec les données des nœuds
Les données invités de Node complètent les métriques de la plateforme de comptes Batch collectées automatiquement. Utilisez les deux sources :
- Utilisez des métriques de comptes batch telles que
TotalNodeCount,RunningNodeCount,IdleNodeCount,UnusableNodeCount,TaskStartEvent, , etTaskCompleteEventpour surveiller l’état du service et de la planification. - Utilisez des compteurs de performance invités pour étudier les conditions du CPU, de la mémoire, du disque et du réseau sur les nœuds de calcul.
- Utilisez les journaux du service Batch afin de corréler les événements du cycle de vie des pools, des travaux et des tâches avec le comportement des nœuds.
Pour les définitions métriques et les conseils d’agrégation, voir Azure Batch monitoring data reference et Monitor Azure Batch.
Résoudre les problèmes de collecte de données
Utilisez les vérifications suivantes lorsque les données n’arrivent pas :
| Symptôme | Contrôles |
|---|---|
| Aucun signal de pulsation | Confirmez que l’extension AMA a été provisionnée avec succès, que l’identité attribuée par l’utilisateur est attachée au pool et référencée dans les paramètres de l’extension, et que les points d’accès Azure Monitor requis sont accessibles. |
| L’AMA rapporte que la ressource n’est pas associée à un DCR | Confirmez que l’association DCR cible l’identifiant de ressource du pool Batch. Une association uniquement sur l’ensemble d’échelle de la machine virtuelle de support ne remplace pas l’association du pool. |
Le signal de pulsation arrive, mais Perf est vide |
Confirmez que Microsoft-Perf est présent à la fois dans la source de données de compteur de performances et dans un flux de données qui cible Log Analytics. Vérifiez les chemins des compteurs et le type de système d’exploitation du DCR. |
| L’espace de noms de métriques invitées n’est pas disponible | Confirmez ces Microsoft-InsightsMetrics cibles azureMonitorMetrics-default, prévoyez plusieurs minutes pour l’agrégation, et confirmez que le pool dispose actuellement de nœuds et d’un ensemble d’échelle de soutien. |
| Enregistrements en double | Vérifiez la présence de plusieurs DCR qui collectent les mêmes données du pool. La collecte en double augmente le coût d’ingestion. |
Pour connaître les emplacements des journaux de l’AMA et la configuration requise pour le disque, consultez Configuration requise pour Azure Monitor Agent. Pour l’allocation de pool et les défaillances de nœud, consultez Pools Azure Batch et erreurs de nœud.
Considérations relatives aux coûts
Les frais Azure Monitor peuvent s’appliquer à l’ingestion, à la rétention, aux alertes et à d’autres fonctionnalités activées de Log Analytics. Pour contrôler les coûts :
- Collectez uniquement les compteurs et journaux nécessaires à vos objectifs de surveillance.
- Utilisez une fréquence d’échantillonnage adaptée à votre charge de travail.
- Filtrez les données disque par instances significatives de points de montage dans les requêtes et alertes.
- Évitez d’associer des DCR qui se chevauchent au même pool.
- Passez en revue les paramètres de rétention de l’espace de travail.
Pour plus d’informations, consultez Azure Monitor coût et utilisation ainsi que Planifier la gestion des coûts pour Azure Batch.
Nettoyer les ressources
Quand vous n’avez plus besoin du pool surveillé, supprimez le pool et toutes les ressources de surveillance qui ne sont pas partagées avec d’autres charges de travail.
Pour conserver la configuration du pool sans continuer à faire tourner les nœuds de calcul, redimensionnez le pool à zéro :
az batch account login \
--resource-group "$resourceGroup" \
--name "$batchAccount"
az batch pool resize \
--pool-id "$poolName" \
--target-dedicated-nodes 0 \
--target-low-priority-nodes 0
Une mise à l’échelle à zéro peut supprimer le groupe de machines virtuelles identiques sous-jacent. Les données déjà stockées dans Log Analytics restent disponibles selon les paramètres de rétention de l’espace de travail.