Partage via


Superviser des machines virtuelles avec Azure Monitor : Collecter des données

Cet article fait partie du guide Analyse des machines virtuelles et de leurs charges de travail dans Azure Monitor. Cela explique comment configurer la collecte de données après avoir déployé l’agent Azure Monitor sur vos machines virtuelles Azure et hybrides dans Azure Monitor.

Cet article fournit des conseils sur la collecte des types de données de télémétrie les plus courants à partir de machines virtuelles. La configuration exacte que vous choisissez dépend des charges de travail que vous exécutez sur vos ordinateurs. Chaque section contient des exemples d’alertes de recherche dans les journaux que vous pouvez utiliser avec ces données.

Notes

Ce scénario décrit comment mettre en œuvre l’analyse complète de votre environnement Azure et de votre machine virtuelle hybride. Pour commencer à surveiller votre première machine virtuelle Azure, consultez Surveiller des machines virtuelles Azure.

Règles de collecte des données

La collecte de données à partir de l’agent Azure Monitor est définie par une ou plusieurs règles de collecte de données (DCR) stockées dans votre abonnement Azure et associées à vos machines virtuelles.

Pour les machines virtuelles, les contrôleurs de domaine définissent des données telles que des événements et des compteurs de performances pour collecter et spécifier les espaces de travail Log Analytics vers lesquels les données doivent être envoyées. La DCR peut également utiliser des transformations pour filtrer les données indésirables et ajouter des colonnes calculées. Une seule machine peut être associée à plusieurs contrôleurs de domaine et une seule DCR peut être associée à plusieurs machines. Les DCR sont remis à toutes les machines auxquelles elles sont associées où l’agent Azure Monitor les traite.

Afficher des règles de collecte de données

Vous pouvez afficher les DCR dans votre abonnement Azure à partir de Règles de collecte des données dans le menu Surveiller du Portail Azure. Les DCR prennent en charge d’autres scénarios de collecte des données dans Azure Monitor, de sorte que tous vos DCR ne soient pas nécessairement destinées aux machines virtuelles.

Capture d’écran montrant des règles de collecte de données dans le portail Azure.

Créer des règles de collecte de données

Il existe plusieurs méthodes pour créer des DCR en fonction du scénario de collecte de données. Dans certains cas, le portail Azure vous guide tout au long de la configuration. D’autres scénarios vous obligent à modifier une DCR directement. Lorsque vous configurez VM insights, une DCR préconfigurée est automatiquement créée pour vous. Les sections suivantes identifient les données courantes à collecter et comment configurer la collecte de données.

Dans certains cas, vous devrez peut-être modifier une DCR existante pour ajouter des fonctionnalités. Par exemple, vous pouvez utiliser le portail Azure pour créer une DCR qui collecte des événements Windows ou Syslog. Vous souhaitez ensuite ajouter une transformation à cette DCR pour filtrer les colonnes dans les événements que vous ne souhaitez pas collecter.

Au fur et à mesure que votre environnement mûrit et augmente en complexité, vous devez mettre en place une stratégie d’organisation de vos DCR pour faciliter leur gestion. Pour obtenir des conseils sur les différentes stratégies, consultez Bonnes pratiques pour la création et la gestion des règles de collecte de données dans Azure Monitor.

Contrôle des coûts

Puisque votre coût Azure Monitor dépend de la quantité de données que vous collectez, assurez-vous que vous ne collectez pas plus que nécessaire pour répondre à vos besoins de supervision. Votre configuration est un équilibre entre votre budget et la quantité d’informations nécessaires sur le fonctionnement de vos machines virtuelles.

Conseil

Pour connaître les stratégies de réduction de vos coûts Azure Monitor, consultez Optimisation des coûts et Azure Monitor.

Une machine virtuelle génère généralement entre 1 Go et 3 Go de données par mois. Cette taille dépend de la configuration de l’ordinateur, des charges de travail qui s’y exécutent et de la configuration de vos DCR. Avant de configurer la collecte de données sur l’ensemble de votre environnement de machines virtuelles, commencez la collecte sur certaines machines représentatives pour une meilleure estimation des coûts lors du déploiement dans votre environnement. Utilisez Insights de l’espace de travail Log Analytics ou des requêtes de journal dans Volume de données par ordinateur pour déterminer la quantité de données facturables collectées pour chaque machine et ajuster en conséquence.

Évaluez les données collectées et filtrez toutes les données qui répondent aux critères suivants pour réduire vos coûts. Chaque source de données que vous collectez peut avoir une méthode différente pour filtrer les données indésirables. Pour plus d’informations sur chacune des sources de données courantes, consultez les sections ci-dessous.

  • Non utilisé pour l’alerte.
  • Aucune valeur médico-légale ou de diagnostic connue.
  • Non requis par les régulateurs.
  • N’est pas utilisé dans les tableaux de bord ou classeurs.

Vous pouvez aussi utiliser les transformations pour implémenter un filtrage plus précis et filtrer les données issues de colonnes qui n’ont que peu de valeur. Par exemple, vous pouvez avoir un événement Windows intéressant en termes d’alertes, mais comprenant des colonnes avec des données redondantes ou excessives. Vous pouvez créer une transformation qui permet de collecter l'événement mais supprime ces données excessives.

Filtrez les données autant que possible avant qu’elles ne soient envoyées à Azure Monitor pour éviter des frais potentiels de filtrage de trop de données à l’aide de transformations. Utilisez des transformations pour le filtrage d’enregistrements à l’aide d’une logique complexe et pour le filtrage des colonnes avec des données dont vous n’avez pas besoin.

Collecte de données par défaut

Azure Monitor effectue automatiquement la collecte de données suivante sans autre configuration nécessaire.

Métriques de plateforme

Les métriques de plateforme pour les machines virtuelles Azure incluent des métriques hôtes importantes telles que l’utilisation du processeur, du réseau et du disque. Ce peut être :

Journal d’activité

Le journal d’activité est collecté automatiquement. Il comprend l’activité récente de la machine, notamment les modifications de sa configuration et le moment où elle a été arrêtée et démarrée. Vous pouvez voir les métriques de plateforme et le journal d’activité collectés pour chaque hôte de machine virtuelle dans le portail Azure.

Vous pouvez afficher le journal d’activité d’un ordinateur individuel ou de toutes les ressources d’un abonnement. Créez un paramètre de diagnostic pour envoyer ces données dans le même espace de travail Log Analytics que celui utilisé par l’agent Azure Monitor pour les analyser avec les autres données de surveillance collectées pour la machine virtuelle. Il n’y a aucun coût pour l’ingestion ou la conservation des données du journal d’activité.

Informations sur la disponibilité des machines virtuelles dans Azure Resource Graph

Avec Azure Resource Graph, vous pouvez utiliser le même langage de requête Kusto que celui utilisé dans les requêtes de journal pour interroger vos ressources Azure à grande échelle avec un filtrage, un regroupement et un tri complexes par propriétés de ressource. Vous pouvez utiliser des annotations d’intégrité de machine virtuelle dans Resource Graph pour une analyse détaillée de l’attribution des défaillances et des temps d’arrêt.

Pour plus d’informations sur les données collectées et sur la façon de les afficher, consultez Surveiller des machines virtuelles avec Azure Monitor : Analyser les données de surveillance.

Insights de machine virtuelle

Lorsque vous activez VM insights, une DCR est créée, avec le préfixe MSVMI- qui collecte les informations suivantes. Vous pouvez utiliser ce même DCR avec d’autres ordinateurs au lieu d’en créer un pour chaque machine virtuelle.

  • Les compteurs de performances courants pour le système d’exploitation client sont envoyés à la table InsightsMetrics de l’espace de travail Log Analytics. Les noms des compteurs seront normalisés pour utiliser le même nom commun, quel que soit le type de système d’exploitation.

  • Si vous avez spécifié la collecte de processus et de dépendances, les tableaux suivants sont renseignés :

    • VMBoundPort : Trafic pour les ports serveur ouverts sur l’ordinateur
    • VMComputer : Données d’inventaire pour la machine
    • VMConnection : Trafic pour les connexions entrantes et sortantes vers et depuis l’ordinateur
    • VMProcess : Processus en cours d’exécution sur la machine

Par défaut, VM insights n’active pas la collecte de processus et de dépendances pour réduire les coûts d’ingestion des données. Ces données sont requises pour la fonctionnalité Carte et déploient également l’agent de dépendances sur l’ordinateur. Activez cette collection si vous souhaitez utiliser cette fonctionnalité.

Collecter des événements Windows et Syslog

Le système d’exploitation et les applications dans les machines virtuelles écrivent souvent dans le journal des événements Windows ou Syslog. Vous pouvez créer une alerte dès qu’un événement unique est trouvé ou attendre une série d’événements correspondants dans une fenêtre de temps particulière. Vous pouvez également collecter des événements pour une analyse ultérieure, comme l’identification de tendances particulières au fil du temps ou la résolution des problèmes après un problème.

Pour obtenir un aide sur la création d’une DCR pour collecter des événements Windows et Syslog, consultez Collecter des données avec l’agent Azure Monitor. Vous pouvez créer rapidement une DCR à l’aide des journaux d’événements Windows les plus courants et des fonctionnalités Syslog qui filtrent par niveau d’événement.

Pour un filtrage plus granulaire par critères tels que l’ID d’événement, vous pouvez créer un filtre personnalisé à l’aide de requêtes XPath. Vous pouvez filtrer davantage les données collectées en modifiant la DCR pour ajouter une transformation.

Utilisez les conseils suivants comme point de départ recommandé pour la collecte d’événements. Modifiez les paramètres DCR pour filtrer les événements inutiles et ajouter des événements supplémentaires en fonction de vos besoins.

Source Stratégie
Événements Windows Collectez au moins les événements Critique, Erreur et Avertissement pour les journaux Système et Application afin de prendre en charge les alertes. Ajoutez des événements d’informations pour analyser les tendances et prendre en charge la résolution des problèmes. Les événements Commentaires sont rarement utiles et ne doivent généralement pas être collectés.
Événements Syslog Collectez au moins les événements LOG_WARNING pour chaque installation afin de prendre en charge les alertes. Ajoutez des événements d’informations pour analyser les tendances et prendre en charge la résolution des problèmes. Les événements LOG_DEBUG sont rarement utiles et ne doivent généralement pas être collectés.

Exemples de requêtes de journal : Événements Windows

Requête Description
Event Tous les événements Windows
Event | where EventLevelName == "Error" Tous les événements Windows avec la gravité de l'erreur
Event | summarize count() by Source Nombre d’événements Windows par source
Event | where EventLevelName == "Error" | summarize count() by Source Nombre d’événements d’erreur Windows par source

Exemples de requêtes de journal : Événements Syslog

Requête Description
Syslog Tous les journaux Syslog
Syslog | where SeverityLevel == "error" Tous les enregistrements Syslog avec le niveau de gravité Erreur
Syslog | summarize AggregatedValue = count() by Computer Nombre d’enregistrements Syslog par ordinateur
Syslog | summarize AggregatedValue = count() by Facility Nombre d’enregistrements Syslog par installation

Collecter des compteurs de performances

Les données de performances du client peuvent être envoyées à Métriques Azure Monitor ou à Journaux Azure Monitor, et vous les envoyez généralement aux deux destinations. Si vous avez activé VM insights, un ensemble commun de compteurs de performances est collecté dans Journaux d’activité pour prendre en charge ses graphiques de performances. Vous ne pouvez pas modifier cet ensemble de compteurs, mais vous pouvez créer d’autres DDR pour collecter davantage de compteurs et les envoyer à différentes destinations.

Il existe plusieurs raisons pour lesquelles vous souhaitez créer une DCR pour collecter les performances des invités :

  • Vous n’utilisez pas VM Insights, donc les données de performances du client ne sont pas déjà collectées.
  • Collectez d’autres compteurs de performances que VM insights ne collecte pas.
  • Collectez des compteurs de performances à partir d’autres charges de travail s’exécutant sur votre client.
  • Envoyez des données de performances aux métriques Azure Monitor, où vous pouvez les utiliser avec l’explorateur de métriques et les alertes de métriques.

Pour obtenir des conseils sur la création d’une DCR pour collecter des compteurs de performances, consultez Collecter des événements et des compteurs de performances à partir de machines virtuelles avec l’agent Azure Monitor. Vous pouvez créer rapidement une DCR à l’aide des compteurs les plus courants. Pour un filtrage plus granulaire par critères tels que l’ID d’événement, vous pouvez créer un filtre personnalisé à l’aide de requêtes XPath.

Notes

Vous pouvez choisir de combiner les performances et la collecte d’événements dans la même DCR.

Destination Description
Mesures Les métriques d’hôte sont automatiquement envoyées aux métriques Azure Monitor. Vous pouvez utiliser une DCR pour collecter les métriques client afin qu’elles puissent être analysées avec l’explorateur de métriques ou avec des alertes de métriques. Ces données sont stockées pendant 93 jours.
Journaux d’activité Les données de performances stockées dans les journaux d’activité Azure Monitor peuvent être stockées pendant de longues périodes. Les données peuvent être analysées en même temps que vos données d’événements à l’aide de requêtes de journaux avec Log Analytics ou d’alertes de recherche dans les journaux. Vous pouvez également corréler des données à l’aide d’une logique complexe sur plusieurs ordinateurs, régions et abonnements.

Les données de performances sont envoyées aux tables suivantes :
– VM insights : InsightsMetrics
– Autres données de performances : Perf

Exemples de requêtes de journal

Les exemples suivants utilisent la Perf table avec des données de performances personnalisées.

Requête Description
Perf Toutes les données de performances
Perf | where Computer == "MyComputer" Toutes les données de performances d’un ordinateur particulier
Perf | where CounterName == "Current Disk Queue Length" Toutes les données de performances d’un compteur particulier
Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AVGCPU = avg(CounterValue) by Computer Utilisation moyenne du processeur entre tous les ordinateurs
Perf | where CounterName == "% Processor Time" | summarize AggregatedValue = max(CounterValue) by Computer Utilisation maximale du processeur entre tous les ordinateurs
Perf | where ObjectName == "LogicalDisk" and CounterName == "Current Disk Queue Length" and Computer == "MyComputerName" | summarize AggregatedValue = avg(CounterValue) by InstanceName Taille moyenne de file d’attente du disque actuelle entre toutes les instances d’un ordinateur donné
Perf | where CounterName == "Disk Transfers/sec" | summarize AggregatedValue = percentile(CounterValue, 95) by Computer 95e centile de transferts disque/s entre tous les ordinateurs
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 1h), Computer Moyenne horaire d’utilisation du processeur sur tous les ordinateurs
Perf | where Computer == "MyComputer" and CounterName startswith_cs "%" and InstanceName == "_Total" | summarize AggregatedValue = percentile(CounterValue, 70) by bin(TimeGenerated, 1h), CounterName 70e centile horaire de chaque compteur de pourcentage pour un ordinateur particulier
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" and Computer == "MyComputer" | summarize ["min(CounterValue)"] = min(CounterValue), ["avg(CounterValue)"] = avg(CounterValue), ["percentile75(CounterValue)"] = percentile(CounterValue, 75), ["max(CounterValue)"] = max(CounterValue) by bin(TimeGenerated, 1h), Computer Moyenne horaire, minimum, maximum et 75e centile d’utilisation du processeur pour un ordinateur spécifique
Perf | where ObjectName == "MSSQL$INST2:Databases" and InstanceName == "master" Toutes les données de performances de l’objet de performance de base de données pour la base de données MASTER à partir de l’instance de SQL Server nommée INST2.
Perf | where TimeGenerated >ago(5m) | where ObjectName == "Process" and InstanceName != "_Total" and InstanceName != "Idle" | where CounterName == "% Processor Time" | summarize cpuVal=avg(CounterValue) by Computer,InstanceName | join (Perf| where TimeGenerated >ago(5m)| where ObjectName == "Process" and CounterName == "ID Process" | summarize arg_max(TimeGenerated,*) by ProcID=CounterValue ) on Computer,InstanceName | sort by TimeGenerated desc | summarize AvgCPU = avg(cpuVal) by InstanceName,ProcID Moyenne du processeur au cours des 5 dernières minutes pour chaque ID de processus.

Collecter les journaux texte

Certaines applications écrivent des événements écrits dans un journal texte stocké sur la machine virtuelle. Créez une table personnalisée et une DCR pour collecter ces données. Vous définissez l’emplacement du journal de texte, sa configuration détaillée et le schéma de la table personnalisée. L’ingestion et la conservation de ces données dans l’espace de travail ont un coût.

Exemples de requêtes de journal

Les noms de colonnes utilisés ici sont donnés à titre d’exemple uniquement. Les noms de colonnes de votre journal seront probablement différents.

Requête Description
MyApp_CL | summarize count() by code Comptez le nombre d’événements par code.
MyApp_CL | where status == "Error" | summarize AggregatedValue = count() by Computer, bin(TimeGenerated, 15m) Créez une règle d’alerte pour tous les événements d’erreur.

Collecter les journaux IIS

IIS s’exécutant sur les machines Windows écrit les journaux dans un fichier texte. Configurez la collecte de journaux IIS à l’aide de Collecter les journaux IIS avec l’agent Azure Monitor. L’ingestion et la conservation de ces données dans l’espace de travail ont un coût.

Les enregistrements du journal IIS sont stockés dans la table W3CIISLog de l’espace de travail Log Analytics. L’ingestion et la conservation de ces données dans l’espace de travail ont un coût.

Exemples de requêtes de journal

Requête Description
W3CIISLog | where csHost=="www.contoso.com" | summarize count() by csUriStem Comptez les entrées du journal IIS par URL pour l’hôte www.contoso.com.
W3CIISLog | summarize sum(csBytes) by Computer Examinez le nombre total d’octets reçus par chaque machine IIS.

Surveiller un service ou un démon

Pour surveiller l’état d’un service Windows ou d’un démon Linux, activez la solution Suivi des modifications et inventaire dans Azure Automation.

Azure Monitor n’a pas la capacité de lui-même de surveiller l’état d’un service ou d’un démon. Quelques méthodes peuvent être utilisées, comme la recherche d’événements dans le journal des événements de Windows, mais cette méthode n’est pas fiable. Vous pouvez également rechercher le processus associé au service en cours d’exécution sur la machine à partir de la table VMProcess alimentée par VM Insights. Cette table est mise à jour uniquement toutes les heures, ce qui n’est généralement pas suffisant si vous souhaitez utiliser ces données pour les alertes.

Notes

La solution Suivi des modifications et analyse est différente de la fonctionnalité Analyse des changements de VM Insights. Cette fonctionnalité est en préversion publique et n’est pas encore incluse dans ce scénario.

Pour connaître les différentes options permettant d’activer la solution Change Tracking sur vos machines virtuelles, consultez Activer Suivi des modifications et inventaire. Cette solution comprend des méthodes permettant de configurer des machines virtuelles à grande échelle. Vous devez créer un compte Azure Automation pour prendre en charge cette solution.

Lorsque vous activez Suivi des modifications et inventaire, deux nouvelles tables sont créées dans votre espace de travail Log Analytics. Utilisez ces tables pour les requêtes de journaux et les règles d’alerte de recherche dans les journaux.

Table Description
ConfigurationChange Modifications apportées aux données de configuration dans l’invité
ConfigurationData Dernier état signalé pour les données de configuration dans l’invité

Exemples de requêtes de journal

  • Répertoriez tous les services et démons récemment démarrés.

    ConfigurationChange
    | where ConfigChangeType == "Daemons" or ConfigChangeType == "WindowsServices"
    | where SvcState == "Running"
    | sort by Computer, SvcName
    
  • Alerte lorsqu’un service spécifique s’arrête. Utilisez cette requête dans une règle d’alerte de recherche dans les journaux.

    ConfigurationData
    | where SvcName == "W3SVC" 
    | where SvcState == "Stopped"
    | where ConfigDataType == "WindowsServices"
    | where SvcStartupType == "Auto"
    | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
    
  • Alerte lorsqu’un des services d’un ensemble de services s’arrête. Utilisez cette requête dans une règle d’alerte de recherche dans les journaux.

    let services = dynamic(["omskd","cshost","schedule","wuauserv","heathservice","efs","wsusservice","SrmSvc","CertSvc","wmsvc","vpxd","winmgmt","netman","smsexec","w3svc","sms_site_vss_writer","ccmexe","spooler","eventsystem","netlogon","kdc","ntds","lsmserv","gpsvc","dns","dfsr","dfs","dhcp","DNSCache","dmserver","messenger","w32time","plugplay","rpcss","lanmanserver","lmhosts","eventlog","lanmanworkstation","wnirm","mpssvc","dhcpserver","VSS","ClusSvc","MSExchangeTransport","MSExchangeIS"]);
    ConfigurationData
    | where ConfigDataType == "WindowsServices"
    | where SvcStartupType == "Auto"
    | where SvcName in (services)
    | where SvcState == "Stopped"
    | project TimeGenerated, Computer, SvcName, SvcDisplayName, SvcState
    | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
    

Surveiller un port

La surveillance des ports permet de vérifier qu’une machine écoute sur un port spécifique. Deux stratégies potentielles de surveillance des ports sont décrites ici.

Tables d’agents de dépendances

Si vous utilisez VM insights avec Collection de processus et de dépendances activé, vous pouvez utiliser VMConnection et VMBoundPort pour analyser les connexions et les ports sur l’ordinateur. La table VMBoundPort est mise à jour toutes les minutes avec chaque processus en cours d’exécution sur l’ordinateur et le port sur lequel il écoute. Vous pouvez créer une alerte de recherche dans les journaux similaire à l’alerte de pulsations manquantes pour trouver les processus qui se sont arrêtés ou pour signaler que l’ordinateur n’écoute pas sur un port spécifique.

  • Examinez le nombre de ports ouverts sur vos machines virtuelles pour évaluer quelles machines virtuelles présentent des vulnérabilités de configuration et de sécurité.

    VMBoundPort
    | where Ip != "127.0.0.1"
    | summarize by Computer, Machine, Port, Protocol
    | summarize OpenPorts=count() by Computer, Machine
    | order by OpenPorts desc
    
  • Répertoriez les ports liés sur vos machines virtuelles pour évaluer quelles machines virtuelles présentent des vulnérabilités de configuration et de sécurité.

    VMBoundPort
    | distinct Computer, Port, ProcessName
    
  • Analysez l’activité réseau par port pour déterminer la façon dont votre application ou service est configuré.

    VMBoundPort
    | where Ip != "127.0.0.1"
    | summarize BytesSent=sum(BytesSent), BytesReceived=sum(BytesReceived), LinksEstablished=sum(LinksEstablished), LinksTerminated=sum(LinksTerminated), arg_max(TimeGenerated, LinksLive) by Machine, Computer, ProcessName, Ip, Port, IsWildcardBind
    | project-away TimeGenerated
    | order by Machine, Computer, Port, Ip, ProcessName
    
  • Examinez les tendances des octets envoyés et reçus pour vos machines virtuelles.

    VMConnection
    | summarize sum(BytesSent), sum(BytesReceived) by bin(TimeGenerated,1hr), Computer
    | order by Computer desc
    | render timechart
    
  • Utilisez les échecs de connexion dans le temps pour déterminer si le taux d’échec est stable ou évolue.

    VMConnection
    | where Computer == <replace this with a computer name, e.g. 'acme-demo'>
    | extend bythehour = datetime_part("hour", TimeGenerated)
    | project bythehour, LinksFailed
    | summarize failCount = count() by bythehour
    | sort by bythehour asc
    | render timechart
    
  • Liez les tendances d’état pour analyser le comportement et l’état de connexion d’une machine.

    VMConnection
    | where Computer == <replace this with a computer name, e.g. 'acme-demo'>
    | summarize  dcount(LinksEstablished), dcount(LinksLive), dcount(LinksFailed), dcount(LinksTerminated) by bin(TimeGenerated, 1h)
    | render timechart
    

Gestionnaire de connexions

La fonctionnalité Moniteur de connexion de Network Watcher est utilisée pour tester les connexions à un port sur une machine virtuelle. Un test permet de vérifier que la machine écoute sur le port et qu’elle est accessible sur le réseau.

Gestionnaire des connexions nécessite l’extension de Network Watcher sur la machine cliente qui lance le test. Il n’est pas nécessaire qu’elle soit installée sur la machine testée. Pour plus d’informations, consultez Tutoriel : Surveiller la communication réseau à l’aide du portail Azure.

Gestionnaire des connexions présente un coût supplémentaire. Pour plus d’informations, consultez Tarification Network Watcher.

Exécuter un processus sur un ordinateur local

La surveillance de certaines charges de travail nécessite un processus local. Il s’agit par exemple d’un script PowerShell qui s’exécute sur l’ordinateur local pour se connecter à une application et collecter ou traiter des données. Vous pouvez utiliser Runbook Worker hybride, qui fait partie d’Azure Automation, pour exécuter un script PowerShell local. Runbook Worker hybride n’est pas directement facturé, mais chaque runbook qu’il utilise est facturé.

Le runbook peut accéder à toutes les ressources sur l’ordinateur local pour collecter les données requises. Il ne peut pas envoyer de données directement à Azure Monitor ni créer une alerte. Pour créer une alerte, demandez au runbook d’écrire une entrée dans un journal personnalisé. Configurez ensuite ce journal pour qu’il soit collecté par Azure Monitor. Créez une règle d’alerte de recherche dans les journaux qui se déclenche sur cette entrée de journal.

Étapes suivantes