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

Article
11/14/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, les environnements locaux et d’autres clouds. 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.

La migration est une tâche complexe. Commencez à planifier votre migration vers l’agent Azure Monitor en utilisant les informations contenues dans cet article comme guide.

Important

L’agent Log Analytics a été mis hors service le 31 août 2024. Cette mise hors service ne s’applique pas à l’agent MMA connecté exclusivement à une installation SCOM locale.

Vous pouvez vous attendre à ce qui suit quand vous utilisez l’agent MMA ou OMS après le 31 août 2024.

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. L’ingestion pour MMA reste inchangée jusqu’au 1er février 2025.
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. Vous pouvez toujours installer l’extension des agents MMA, mais également effectuer les installations hors connexion.
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 : la prise en charge des nouvelles distributions Linux ou Windows, notamment les Service Packs, ne va pas être ajoutée après la dépréciation des agents hérités.
L’agent Log Analytics peut coexister avec l’agent Azure Monitor. Attendez-vous à voir des données dupliquées si les deux agents collectent les mêmes données.

Avantages

L’utilisation de l’agent Azure Monitor vous permet d’obtenir des avantages immédiats, comme indiqué ci-dessous :

Des économies de coûts en utilisant des règles de collecte de données :
- Il permet la collecte de données ciblées et granulaires pour une machine, ou un ou plusieurs sous-ensembles de machines, par rapport à l’approche « tout ou rien » des anciens agents.
- Il permet aux règles de filtrage et aux transformations de données de réduire le volume de données global chargé, réduisant ainsi considérablement les coûts d’ingestion et de stockage.
Sécurité et niveau de performance
- Sécurité améliorée par le biais de jetons Microsoft Entra et d’identité managée (pour les clients).
- Débit d’événements supérieur de 25 % à celui des agents Log Analytics (MMA/OMS) hérités.
Gestion plus simple, y compris résolution efficace des problèmes :
- Il prend en charge les chargements de données vers plusieurs destinations (plusieurs espaces de travail Log Analytics, c’est-à-dire le multi-hébergement sur Windows et Linux), y compris la collecte de données interrégionale et multilocataire (via Azure LightHouse).
- La configuration centralisée de l’agent « dans le cloud » à l’échelle de l’entreprise tout au long du cycle de vie de la collecte de données, de l’intégration au déploiement en passant par les mises à jour et les modifications au fil du temps.
- Toutes les modifications apportées à la configuration sont déployées automatiquement sur tous les agents, sans nécessiter de déploiement côté client.
- Plus de transparence et de contrôle de plus de fonctionnalités et de services, comme Sentinel, Defender pour le cloud et Insights de machine virtuelle.
Un seul agent qui répond à tous les besoins de collecte de données sur les serveurs et les appareils clients pris en charge. Un agent unique est l’objectif, bien que l’agent Azure Monitor converge actuellement avec les agents Log Analytics.

Avant de commencer

Vérifiez les prérequis pour 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.
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.
Vérifiez que vous disposez des autorisations nécessaires pour installer l’agent Azure Monitor. Vous devez disposer des autorisations nécessaires pour installer l’agent sur les machines que vous souhaitez surveiller. Pour plus d’informations, consultez Autorisations requises pour installer l’agent Azure Monitor.

Conseils généraux

Utilisez les conseils suivants pour planifier et exécuter votre migration :

Comprenez vos agents et le nombre d’agents que vous devez migrer.
Comprenez comment vous utilisez vos espaces de travail.
Comprenez les solutions, les insights et les collectes de données qui sont configurées.
Configurez vos collectes de données et validez les collectes.
Comprenez les dépendances et services supplémentaires.
Supprimez les agents hérités.

Le classeur Aide à la migration vers l’agent Azure Monitor est une solution Azure Monitor basée sur des classeurs qui peut vous aider lors de chacune des étapes décrites ci-dessus. Ce guide référence le classeur et d’autres outils à chaque étape du processus de migration. Pour plus d’informations, consultez Classeur d’aide à la migration vers l’agent Azure Monitor.

Comprendre vos agents

Utilisez le générateur DCR pour convertir automatiquement la configuration de votre agent hérité en règles de collecte des données.¹ Pour mieux comprendre vos agents, examinez les questions suivantes :

Question	Actions
Combien d’agents devez-vous migrer ?	Comprendre le nombre d’agents que vous devez migrer.
Avez-vous des agents qui sont déployés en dehors d’Azure ? Ces agents sont-ils déployés dans votre propre centre de données ou dans un autre environnement cloud ?	Pour les serveurs qui se trouvent en dehors d’Azure, vous devez d’abord déployer Azure Arc Connected Machine Agent. Pour plus d’informations, consultez Vue d’ensemble d’Azure Connected Machine Agent.
Utilisez-vous System Center Operations Manager (SCOM) ? Quelles sont vos intentions concernant SCOM à l’avenir ?	Si vous envisagez de continuer à utiliser SCOM, commencez à évaluer SCOM Managed Instance. Pour plus d’informations, consultez SCOM Managed Instance.
Comment déployez-vous vos agents aujourd’hui ?	Si vous utilisez des méthodes automatisées pour déployer l’agent hérité, réfléchissez au moment où vous devrez arrêter ces déploiements automatisés pour les nouveaux serveurs et commencez à vous concentrer sur le déploiement du nouvel agent. L’arrêt du déploiement automatisé pour les nouveaux serveurs permet d’alléger les efforts de migration, et vous permet de vous concentrer sur l’inventaire existant des agents à migrer.

Le classeur d’aide à la migration vers l’agent Azure Monitor peut vous aider à comprendre le nombre d’agents que vous devez migrer. Pour plus d’informations, consultez Classeur d’aide à la migration vers l’agent Azure Monitor – Agents.

Comprendre vos espaces de travail, solutions, insights et collectes de données

Avant la migration, veillez à bien comprendre comment vos espaces de travail Log Analytics sont utilisés. Vérifiez s’ils sont tous utilisés, et vérifiez à quels espaces de travail les agents envoient leur télémétrie. De nombreux espaces de travail sont créés au fil du temps, et il peut être délicat d’identifier les espaces de travail qui sont réellement utilisés, ceux qui sont utilisés pour collecter de la télémétrie, et à partir de quels serveurs. La migration est une bonne occasion de nettoyer et de consolider vos espaces de travail.

Lorsque vous examinez vos espaces de travail, notez les solutions configurées. Ces informations sont importantes pour comprendre les données que vous collectez et comment vous les utilisez.

Le classeur d’aide à la migration vers l’agent Azure Monitor peut vous aider à identifier vos espaces de travail, les solutions implémentées dans chaque espace de travail, et quand vous avez utilisé la solution pour la dernière fois. Chaque solution a une recommandation de migration. Pour plus d’informations, consultez Classeur d’aide à la migration vers l’agent Azure Monitor – Espaces de travail.

Vous pouvez également utiliser le classeur d’audit d’espace de travail Azure Monitor pour vous aider à comprendre vos espaces de travail. Pour utiliser le classeur d’audit d’espace de travail Azure Monitor, copiez le classeur à partir du dépôt GitHub et importez-le dans votre espace de travail Log Analytics.

Ce classeur collecte tous vos espaces de travail Log Analytics, et vous montre les éléments suivants pour chaque espace de travail :

Toutes les sources de données qui envoient des données à l’espace de travail.
Les agents qui envoient des pulsations à l’espace de travail.
Les ressources qui envoient des données à l’espace de travail.
Toutes les ressources Application Insights qui envoient des données à l’espace de travail.

Pour plus d’informations, consultez Classeur d’audit d’espace de travail Azure Monitor.

Configurer vos collectes de données et valider les collectes

Lors de la configuration de vos collectes de données, tenez compte des étapes suivantes :

Identifiez un groupe pilote de serveurs que vous pouvez utiliser pour ce processus. Utilisez les serveurs pilotes pour valider les données avant de déployer à grande échelle.
Utilisez le générateur de configuration DCR pour transformer les collectes de données configurées dans l’espace de travail et les déployer en tant que règles de collecte de données dans votre environnement. Pour plus d’informations sur le générateur de configuration DCR, consultez Générateur de configuration DCR.
Migrez VM Insights ou Azure Monitor pour machines virtuelles vers l’agent Azure Monitor. Validez les collectes de données migrées pour le groupe pilote de serveurs par rapport à ce qui était collecté avant la migration. 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. Pour plus d’informations, consultez Sources de données de l’agent Log Analytics dans Azure Monitor.
Validez les nouvelles données pour vous assurer qu’il n’y a pas d’écarts. Comparez les données ingérées par l’agent hérité avec les données de l’agent Azure Monitor. Utilisez KQL pour comparer les données équivalentes de chaque agent en fonction du type d’agent.
Planifiez le déploiement à grande échelle à l’aide d’Azure Policy. Utilisez des stratégies intégrées pour déployer des extensions et des associations DCR à grande échelle. L’utilisation de la stratégie garantit également le déploiement automatique des extensions et des associations DCR pour les nouvelles machines. Pour plus d’informations sur le déploiement à grande échelle, consultez Gérer l’agent Azure Monitor – Utiliser des stratégies Azure.

Comprendre les dépendances et services supplémentaires

Avant la migration, il est important de comprendre comment vos autres services sont affectés.

Service	Impact
Update Management	Si vous utilisez Update Management sous Azure Automation, vous devez migrer vers le Gestionnaire de mise à jour Azure. Le Gestionnaire de mise à jour Azure a son propre agent, et il est découplé de l’agent Azure Monitor. Update Management sera déconseillé fin août 2024. Nous vous recommandons de migrer vers le Gestionnaire de mise à jour Azure. Pour plus d’informations, consultez Passer d’Automation Update Management au Gestionnaire de mise à jour Azure. Le classeur d’aide à la migration vers AMA vous montre les machines qui utilisent la solution Update Management et comment les migrer. Pour plus d’informations, consultez Classeur d’aide à la migration vers l’agent Azure Monitor – Update management.
Change Tracking and Inventory	Si vous utilisez Suivi des modifications et inventaire, vous devez migrer vers Azure Automation. Suivi des modifications et inventaire fait également partie d’Azure Automation. Bien que l’agent Azure Monitor dispose d’une solution de suivi des modifications et d’inventaire, vous devez créer une règle de collecte de données. Pour plus d’informations, consultez Gérer le suivi des modifications et l’inventaire à l’aide de l’agent Azure Monitoring.
Defender pour le cloud	Si vous utilisez Defender pour le cloud pour votre service ou Defender pour serveurs et que vous avez activé P2 ou prévoyez d’activer P2 pour vos serveurs, changez le déploiement d’agent dans Defender pour le cloud afin de passer du déploiement d’agent hérité à l’analyse sans agent. Si vous utilisez Defender pour le cloud pour collecter des événements de sécurité, créez une règle de collecte de données personnalisée pour collecter ces événements.
Microsoft Sentinel	Si vous utilisez Microsoft Sentinel, les solutions qui utilisaient l’agent hérité ont été converties en solutions basées sur l’agent Azure Monitor, et elles peuvent être mises à jour.

Supprimer les agents hérités

Dans le cadre de votre planification de la migration, envisagez de supprimer l’agent hérité une fois la migration terminée pour éviter la duplication de la collecte de données.

Si vous n’avez pas besoin de conserver MMA sur l’une de vos machines, utilisez l’outil de découverte et de suppression MMA pour supprimer l’agent à grande échelle. Pour plus d’informations sur l’outil de découverte et de suppression MMA, consultez Outil de découverte et de suppression MMA.

En revanche, si vous utilisez System Center Operations Manager (SCOM), conservez l’agent MMA déployé sur les machines que vous continuerez à gérer avec System Center Operations Manager.

Il existe un pack d’administration SCOM qui peut vous aider à supprimer les configurations d’espace de travail à grande échelle tout en conservant la configuration du groupe d’administration SCOM. Pour plus d’informations sur le pack d’administration SCOM, consultez Pack d’administration SCOM.

Problèmes de migration connus

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.
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 : passe à une solution sans agent. Certaines fonctionnalités ne seront pas prêtes à la date de dépréciation. Les clients doivent rester sur MMA pour les machines qui utilisent la surveillance de l’intégrité des fichiers (FIM), des recommandations de découverte de 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.
La gestion des mises à jour passe à une solution sans agent, mais elle ne sera pas prête à la date de dépréciation de MMA. Les clients qui utilisent la Gestion des mises à jour doivent rester sur MMA jusqu’à ce que le nouveau service Gestionnaire de mise à jour automatisé soit prêt.

Partager via