Migrer vers l’Agent Azure Monitor à partir de l’agent Log Analytics

Article
06/03/2024

L’agent Azure Monitor (AMA) remplace l’agent Log Analytics (également appelé Agent Microsoft Monitor, MMA et OMS) pour les machines Windows et Linux, dans les environnements Azure et non-Azure, notamment les clouds locaux et tiers. Il introduit une méthode simplifiée et flexible pour configurer la collecte de données à l’aide de règles de collecte de données (DCR). Cet article fournit des conseils sur la mise en œuvre d’une migration réussie de l’agent Log Analytics vers l’agent Azure Monitor.

Si vous utilisez actuellement l’agent Log Analytics avec Azure Monitor ou d’autres services et fonctionnalités pris en charge, commencez à planifier votre migration vers l’agent Azure Monitor à l’aide des informations contenues dans cet article. Si vous utilisez l’agent Log Analytics pour SCOM, vous devez effectuer une migration vers l’agent SCOM

L’agent Log Analytics sera mis hors service le 31 août 2024. Vous pouvez vous attendre à ce qui suit lorsque vous utilisez l’agent MMA ou OMS après cette date.

Chargement des données : services d’ingestion cloud réduit progressivement la prise en charge des agents MMA, ce qui peut entraîner une diminution de la prise en charge et des problèmes de compatibilité potentiels pour les agents MMA au fil du temps.

Installation : La possibilité d’installer les agents hérités sera supprimée du portail Azure et les stratégies d’installation des agents hérités seront supprimées.

Support client : Vous ne pourrez pas obtenir de support pour les problèmes d’agent hérités.

prise en charge du système d’exploitation : prise en charge des nouvelles distributions Linux ou Windows (encl. Service Packs) ne sera pas ajoutée après la dépréciation des agents hérités.

Avantages

En plus de consolider et d’améliorer les agents Log Analytics hérités, l’agent Azure Monitor offre divers avantages immédiats, y compris des économies de coûts, une expérience de gestion simplifiée ainsi qu’une sécurité et des performances améliorées.

Recommandations en matière de migration

Avant de lancer la migration de l’agent Log Analytics vers l’agent Azure Monitor, consultez la check-list.

Avant de commencer

Vérifiez les conditions préalables à l’installation de l’agent Azure Monitor.
Pour surveiller les serveurs non Azure et locaux, vous devez installer l’agent Azure Arc. L’agent Arc permet à Azure de voir vos serveurs locaux en tant que ressources qu’il peut cibler. Vous ne vous exposez à aucuns frais supplémentaires pour l’installation de l’agent Azure Arc.
Comprenez votre utilisation actuelle.
Utilisez l’onglet Vue d’ensemble de l’espace de travail de l’assistant de migration AMA pour afficher les agents connectés et découvrir les solutions activées sur vos espaces de travail Log Analytics qui utilisent des agents hérités, ainsi que des recommandations de migration pour chacune.
Vérifiez que l’agent Azure Monitor peut répondre à tous vos besoins.
L’agent Azure Monitor est en disponibilité générale (GA) pour la collecte de données et est utilisé à cette fin par diverses fonctionnalités Azure Monitor et par d’autres services Azure. Pour plus d’informations, consultez Services et fonctionnalités pris en charge.
Envisagez d’installer l’agent Azure Monitor en même temps qu’un agent hérité pendant une période de transition.
Exécutez l’agent Azure Monitor parallèlement à l’ancien agent Log Analytics sur la même machine afin de continuer à utiliser les fonctionnalités existantes pendant l’évaluation ou la migration. N’oubliez pas que l’exécution de deux agents sur la même machine double la consommation de la ressource, y compris, mais sans y être limité, le processeur, la mémoire, l’espace de stockage et la bande passante réseau.
- Si vous configurez un nouvel environnement avec des ressources telles que des scripts de déploiement et des modèles d’intégration, installez l’agent Azure Monitor avec un agent hérité dans votre nouvel environnement pour ultérieurement réduire l’effort de migration.
- Si vous disposez de deux agents sur la même machine, évitez de collecter des données en double.
  La collecte de données en double à partir d’une même machine peut fausser les résultats des requêtes, affecter des fonctionnalités en aval telles que les alertes, les tableaux de bord, et les classeurs, et générer des frais supplémentaires pour l’ingestion et la conservation des données.
  Pour éviter la duplication de données :
  - Configurez les agents de manière à envoyer les données vers différents espaces de travail ou tables du même espace de travail.
  - Désactivez toutes les collectes de données en double des agents hérités en supprimant les configurations de l’espace de travail.
  - Defender pour le cloud déduplique de façon native les données, lorsque vous utilisez les deux agents, et vous êtes facturé une fois par machine lorsque vous exécutez les agents en parallèle.
  - Pour Sentinel, vous pouvez facilement désactiver l’ancien connecteur afin d’arrêter l’ingestion des journaux des anciens agents.

Services et fonctionnalités de migration

Utilisez le générateur DCR pour convertir automatiquement la configuration de votre ancien agent en règles de collecte des données¹.

Passez en revue les règles générées avant de les créer, et tirez parti des options avancées, telles que le filtrage, le ciblage précis (par machine) et d’autres optimisations. Des étapes spéciales sont nécessaires pour migrer les journaux personnalisés MMA vers les journaux personnalisés AMA
Testez le nouvel agent et les règles de collecte de données sur quelques machines hors production :
1. Déployez les règles de collecte de données générées et associez-les à quelques machines, comme décrit dans Installer et utiliser le générateur de configuration DCR.
  
  Pour éviter une double ingestion, vous pouvez désactiver la collecte de données à partir d’agents hérités pendant la phase de test sans désinstaller les agents, en supprimant les configurations de l’espace de travail pour les agents hérités.
2. Vérifiez qu’il n’y a pas d’écart en comparant les données ingérées par l’agent hérité avec les données de l’agent Azure Monitor. Vous pouvez faire cette comparaison sur n’importe quelle table à l’aide de l’opérateur de jointure pour ajouter la colonne Category de la table Heartbeat, qui indique Azure Monitor Agent pour les données collectées par l’agent Azure Monitor.
  
  Par exemple, cette requête ajoute la Category colonne de la table Heartbeat aux données récupérées à partir de la table Event :
```
Heartbeat
| distinct Computer, SourceComputerId, Category
| join kind=inner (
    Event
| extend d=parse_xml(EventData)
    | extend sourceHealthServiceId = tostring(d.DataItem.["@sourceHealthServiceId"])
    | project-reorder TimeGenerated, Computer, EventID, sourceHealthServiceId, ParameterXml, EventData
    ) on $left.SourceComputerId==$right.sourceHealthServiceId
| project TimeGenerated, Computer, Category, EventID, sourceHealthServiceId, ParameterXml, EventData
```
Utilisez des stratégies intégrées pour déployer des extensions et des associations DCR à grande échelle. L’utilisation de la stratégie assure également le déploiement automatique des extensions et des associations DCR pour toutes les futures nouvelles machines³.

Utilisez l’assistant de migration AMA pour analyser la migration à grande échelle entre vos machines.
Vérifiez la collecte les données prévu par l’agent Azure Monitor et toutes les dépendances en aval, dont les tableaux de bord, les alertes et les classeurs, fonctionnent correctement :
1. Examinez les onglets Vue d’ensemble et Utilisation de Log Analytics Workspace Insights pour connaître les pics ou les baisses des taux d’ingestion après la migration. Vérifiez l’ingestion globale de l’espace de travail ainsi que les taux d’ingestion au niveau de la table.
2. Après la migration, vérifiez les écarts dans vos classeurs, tableaux de bord et alertes par rapport au comportement classique.
Nettoyage : après avoir vérifié que l’agent Azure Monitor collecte correctement les données, désactivez ou désinstallez les anciens agents Log Analytics.
- Une fois que l’agent Azure Monitor est installé pour tous vos besoins, désinstallez l’agent Log Analytics des ressources surveillées. Nettoyez les fichiers de configuration, les clés d’espace de travail ou les certificats qui ont été utilisés précédemment par l’agent Log Analytics. Continuez à utiliser l’ancienne version de Log Analytics pour les fonctionnalités et solutions non prises en charge par l’agent Azure Monitor.
  
  Utilisez l’outil de suppression MMA pour détecter et supprimer l’extension de l’agent Log Analytics de tous les ordinateurs de votre locataire.
- Ne désinstallez pas l’agent hérité si vous devez l’utiliser pour charger des données vers SCOM.

¹ Le générateur DCR convertit uniquement les configurations pour les journaux d’événements Windows, les syslog Linux et les compteurs de performances. La prise en charge d’autres fonctionnalités et solutions sera bientôt disponible.
² Vous devrez peut-être déployer les extensions requises pour des solutions spécifiques en plus de l’extension de l’agent Azure Monitor.

Migrer des fonctionnalités et services supplémentaires

L’agent Azure Monitor est en disponibilité générale pour la collecte de données. La plupart des services qui utilisaient l'agent Log Analytics pour la collecte de données ont été migrés vers l'agent Azure Monitor.

Les fonctionnalités et services suivants ont désormais une version de l’agent Azure Monitor (certains sont toujours en préversion publique). Cela signifie que vous pouvez déjà choisir d'utiliser l'agent Azure Monitor pour collecter des données lorsque vous activez la fonctionnalité ou le service.

Service ou fonctionnalité	Recommandation pour la migration	État actuel	Plus d’informations
VM Insights, Service Map et Dependency Agent	Migrer vers l’agent Azure Monitor	GA	Activer VM Insights
Microsoft Sentinel	Migrer vers l’agent Azure Monitor	Version préliminaire publique	Migration AMA pour Microsoft Sentinel
Change Tracking and Inventory	Migrer vers l’agent Azure Monitor	GA	Migration pour Change Tracking et Inventaire
Network Watcher	Migrer vers le nouveau service appelé Moniteur de connexion avec l'agent Azure Monitor	GA	Surveiller la connectivité réseau à l’aide du Moniteur de connexion
Insights Azure Stack HCI	Migrer vers l’agent Azure Monitor	GA	Surveiller Azure Stack HCI avec Insights
Aperçus Azure Virtual Desktop (AVD)	Migrer vers l’agent Azure Monitor	GA	Azure Virtual Desktop Insights
Solution de supervision de conteneur	Migrer vers le nouveau service appelé Container Insights avec l’agent Azure Monitor	GA	Activer Container Insights
Collecteur DNS	Utiliser le nouveau connecteur Sentinel	GA	Activer le connecteur DNS

Lorsque vous migrez les services suivants (qui utilisent actuellement l’agent Log Analytics) vers leurs remplacements respectifs (v2), vous n’avez plus besoin d’aucun agent de surveillance :

Service	Recommandation pour la migration	État actuel	Plus d’informations
Microsoft Defender pour cloud, serveurs, SQL et point de terminaison	Migrer vers Microsoft Defender pour cloud (aucune dépendance vis-à-vis des agents Log Analytics ou de l’agent Azure Monitor)	GA	Plan Microsoft Defender pour le cloud pour la dépréciation de l’agent Log Analytics
Gestion des mises à jour	Mirer vers le Gestionnaire de mise à jour Azure (aucune dépendance vis-à-vis des agents Log Analytics ou de l'agent Azure Monitor)	GA	Documentation Update Manager
Vue d’ensemble du Runbook Worker hybride d’Automation	Extension Automation Hybrid Worker (aucune dépendance vis-à-vis des agents Log Analytics ou de l’agent Azure Monitor)	GA	Migrer vers des Workers hybrides basés sur l’extension

Lacunes de parité connues pour les solutions qui peuvent avoir un impact sur votre migration

Journaux IIS : lorsque la collecte de journaux IIS est activée, il se peut qu’AMA ne remplisse pas la colonne sSiteName de la table W3CIISLog. Ce champ est collecté par défaut lorsque la collecte de journaux IIS est activée pour l’agent hérité. Si vous devez collecter le champ sSiteName à l’aide d’AMA, activez le champ Service Name (s-sitename) dans la journalisation W3C d’IIS. Pour connaître les étapes d’activation de ce champ, consultez Sélectionner les champs W3C à journaliser.
Sentinel : les journaux de pare-feu Windows ne sont pas encore en disponibilité générale
Solution d’évaluation SQL : fait désormais partie de l’évaluation des meilleures pratiques SQL. Les stratégies de déploiement nécessitent un espace de travail Log Analytics par abonnement, ce qui n’est pas la meilleure pratique recommandée par l’équipe AMA.
Microsoft Defender pour le cloud : certaines fonctionnalités de la nouvelle solution sans agent sont en développement. Il est possible que votre migration soit impactée si vous utilisez FIM (File Integrity Monitoring), des recommandations de découverte de la protection des points de terminaison, des configurations incorrectes du système d’exploitation (recommandations Azure Security Benchmark ou ASB) et des contrôles d’application adaptatifs.
Container Insights : la version Windows est disponible en préversion publique.

Forum aux questions

Cette section fournit des réponses aux questions fréquentes.

L’agent Azure Monitor et l’agent Log Analytics peuvent-ils être utilisés simultanément ?

Oui. Si vous migrez vers l’agent Azure Monitor, vous pouvez envisager d’installer l’agent Azure Monitor avec un ancien agent pour une période de transition, mais vous devez tenir compte de certaines considérations. En savoir plus sur les considérations relatives à la coexistence des agents dans les instructions de migration de l’agent Azure Monitor.

Étapes suivantes

Pour plus d'informations, consultez les pages suivantes :

Partager via