Partage via

Migrer de System Center Operations Manager (SCOM) vers Azure Monitor

  • Article

Cet article fournit des conseils aux clients qui utilisent actuellement System Center Operations Manager (SCOM) et qui planifient une transition vers la supervision basée sur le cloud avec Azure Monitor dans le cadre d’une migration d’applications métier et d’autres ressources sur Azure.

Il n’existe aucun processus standard de migration à partir de SCOM, et vous pouvez vous appuyer sur des packs d’administration SCOM pendant une période prolongée plutôt que d’effectuer une migration rapide. Cet article décrit les différentes options disponibles et les critères de décision que vous pouvez utiliser pour déterminer la meilleure stratégie pour votre environnement particulier.

Supervision d’un cloud hybride

La plupart des clients utilisent une stratégie de supervision de cloud hybride qui vous permet d’effectuer une transition progressive vers le cloud. Cette approche vous permet de conserver vos processus d’entreprise existants tout en vous familiarisant avec la nouvelle plateforme. Ne vous éloignez des fonctionnalités SCOM que si vous pouvez les remplacer par celles d’Azure Monitor. L’utilisation de plusieurs outils de supervision ajoute certes de la complexité, mais elle vous permet de profiter de la capacité d’Azure Monitor à superviser les charges de travail cloud de nouvelle génération tout en conservant la capacité de SCOM à superviser les logiciels serveur et les charges de travail.

Avant de déplacer des composants vers Azure, votre environnement est basé sur des machines virtuelles et physiques situées localement ou chez un fournisseur de services gérés. Il s’appuie sur SCOM pour surveiller les applications métier, les logiciels serveur et d’autres composants d’infrastructure de votre environnement, tels que les serveurs physiques et les réseaux. Vous utilisez des packs d’administration standard pour les logiciels serveur tels qu’IIS, SQL Server et divers logiciels de fournisseurs, et vous réglez ces packs d’administration en fonction de vos besoins spécifiques. Vous créez des packs d’administration personnalisés pour vos applications métier et d’autres composants qui ne peuvent pas être supervisés avec les packs d’administration existants. De plus, vous configurez SCOM pour qu’il prenne en charge vos processus métier.

Lorsque vous déplacez des services dans le cloud, Azure Monitor commence à collecter les métriques de plateforme et le journal d’activité pour chacune de vos ressources. Vous créez des paramètres de diagnostic pour collecter les journaux de ressources afin de pouvoir analyser de manière interactive toutes les données de télémétrie disponibles à l’aide de requêtes de journal et d’insights.

Pendant cette période de transition, vous disposez de deux outils de supervision indépendants. Vous utilisez des insights et des classeurs pour analyser vos données de télémétrie cloud dans le portail Azure tout en utilisant la console Opérateur pour analyser vos données collectées par SCOM. Étant donné que chaque système a sa propre alerte, vous devez créer des groupes d’actions dans Azure Monitor équivalents à vos groupes de notification dans SCOM.

Le tableau suivant décrit les différentes fonctionnalités et stratégies disponibles pour un environnement de supervision hybride à l’aide de SCOM et d’Azure Monitor.

Méthode Description
Agents à double hébergement SCOM utilise l’agent de gestion Microsoft (MMA), qui est le même que l’agent Log Analytics utilisé par Azure Monitor. Vous pouvez configurer cet agent pour qu’un seul ordinateur se connecte simultanément à SCOM et à Azure Monitor. Cette configuration nécessite que vos machines virtuelles Azure disposent d’une connexion à vos serveurs d’administration locaux.

L’agent Log Analytics a été remplacé par l’agent Azure Monitor, qui offre des avantages significatifs, notamment une gestion plus simple et un meilleur contrôle de la collecte des données. Les deux agents peuvent coexister sur la même machine, ce qui vous permet de vous connecter à Azure Monitor et à SCOM. Cette configuration est une meilleure option que le double hébergement de l’ancien agent en raison des avantages significatifs de l’agent Azure Monitor.
Groupe d'administration connecté Connectez votre groupe d’administration SCOM à Azure Monitor pour transférer les données collectées à partir de vos agents SCOM vers Azure Monitor. Cela est similaire à l’utilisation d’agents à double hébergement, mais sans nécessiter que chaque agent soit configuré pour se connecter à Azure Monitor. Cette stratégie nécessite l’ancien agent. Vous ne pouvez donc pas spécifier de supervision avec des règles de collecte de données. Vous ne pouvez pas non plus utiliser VM Insights, sauf si vous connectez chaque machine virtuelle directement à Azure Monitor.
Instance SCOM gérée Instance SCOM gérée est une implémentation complète de SCOM dans Azure qui vous permet de continuer à exécuter les packs d’administration que vous exécutez dans votre environnement SCOM local. Vous pouvez continuer à utiliser la même console Opérateur pour analyser votre intégrité et vos alertes. Vous pouvez également afficher des alertes dans Azure Monitor et analyser les données SCOM dans Grafana.

SCOM MI est similaire à la maintenance de votre environnement SCOM existant et des agents de double hébergement, bien que vous puissiez consolider votre configuration de supervision dans Azure et mettre hors service vos composants locaux tels que les serveurs de base de données et d’administration. Les agents de machines virtuelles Azure peuvent se connecter à l’instance gérée SCOM dans Azure au lieu de se connecter aux serveurs d’administration de votre propre centre de données.
Pack d’administration Azure Le pack d’administration Azure permet à Operations Manager de découvrir des ressources Azure et de surveiller leur intégrité en fonction d’un ensemble spécifique de scénarios de supervision. Ce pack d’administration vous oblige à effectuer une configuration supplémentaire pour chaque ressource dans Azure. Il peut cependant être utile de fournir une certaine visibilité de vos ressources Azure dans la console des opérations jusqu'à ce que vous évoluiez vos processus métier pour vous concentrer sur Azure Monitor.

Surveiller les applications métier

En général, vous avez besoin de packs d’administration personnalisés pour superviser vos applications métier avec SCOM, en tirant parti des agents installés sur chaque machine virtuelle. Application Insights dans Azure Monitor supervise les applications web, qu’elles soient dans Azure, d’autres clouds ou locales. Elle peut être utilisée pour l’ensemble de vos applications, que vous les ayez ou non migrées vers Azure.

Si votre supervision d’une application métier se limite aux fonctionnalités fournies par le modèle de performances d’application .NET dans SCOM, vous pouvez très probablement migrer vers Application Insights sans aucune perte de fonctionnalité. En fait, Application Insights inclut un grand nombre d’autres fonctionnalités, dont les suivantes :

  • Détecter et surveiller automatiquement les composants de l’application.
  • Collecter des données détaillées sur l’utilisation et les performances des applications, telles que le temps de réponse, les taux d’échec et les taux de requête.
  • Collecter des données de navigation telles que les pages vues et les performances de chargement.
  • Détecter les exceptions et explorer l’arborescence des appels de procédure et les requêtes connexes.
  • Effectuer une analyse avancée à l’aide de fonctionnalités telles que le suivi distribué et la détection intelligente.
  • Utiliser Metrics Explorer pour analyser de manière interactive les données de performances.
  • Utiliser des requêtes de journal pour analyser de manière interactive la télémétrie collectée avec les données collectées pour les services Azure et VM Insights.

Il existe cependant certains cas de figure où vous devrez continuer à utiliser SCOM en plus d’Application Insights jusqu’à ce que vous soyez en mesure d’obtenir la fonctionnalité requise. Voici quelques exemples de cas où vous pourriez avoir besoin de continuer à utiliser SCOM :

  • Les tests de disponibilité, qui vous permettent de surveiller et de signaler la disponibilité et la réactivité de vos applications, nécessitent des requêtes entrantes provenant des adresses IP d’agents de test web. Si votre stratégie ne permet pas ce type d’accès, vous devrez peut-être continuer à utiliser les moniteurs de disponibilité des applications web dans SCOM.
  • Dans SCOM, vous pouvez définir n’importe quel intervalle d’interrogation pour les tests de disponibilité, avec de nombreux clients vérifiant toutes les 60 à 120 secondes. Application Insights a un intervalle d’interrogation minimal de cinq minutes, ce qui peut être trop long pour certains clients.
  • La collecte des événements générés par les applications et l’exécution de scripts sur l’agent local constituent une part importante de la supervision dans SCOM. Comme ces options ne sont pas des options standard dans Application Insights, vous pouvez exiger un travail personnalisé pour répondre aux besoins de votre entreprise. Cela peut inclure des règles d’alerte personnalisées utilisant des données d’événements stockées dans un espace de travail Log Analytics et des scripts lancés dans une machine virtuelle invitée à l’aide d’un Runbook Worker hybride.
  • Selon le langage dans lequel votre application est écrite, vous pouvez être limité dans l’instrumentation que vous pouvez utiliser avec Application Insights.

En suivant la stratégie de base décrite dans les autres sections de ce guide, continuez à utiliser SCOM pour vos applications métier, mais tirez parti des autres fonctionnalités fournies par Application Insights. À mesure que vous pouvez remplacer les fonctionnalités critiques par Azure Monitor, commencez à mettre hors service vos packs d’administration personnalisés.

Surveillance des machines virtuelles

La surveillance du logiciel sur vos machines virtuelles dans un environnement hybride utilise souvent une combinaison d'Azure Monitor et de SCOM, selon les exigences des charges de travail exécutées sur vos machines virtuelles. Dès qu’une machine virtuelle est créée dans Azure, la collecte des métriques de plateforme et des journaux d’activité pour l’hôte de machine virtuelle commence automatiquement. Activez les alertes recommandées pour vous informer des erreurs courantes pour l’hôte de machine virtuelle, telles que l’arrêt du serveur et une utilisation élevée du processeur.

Activez VM Insights pour installer l’agent Azure Monitor et commencer à collecter des données de performances courantes à partir du système d’exploitation client. Cela peut chevaucher certaines données que vous collectez déjà dans SCOM, mais cela vous permet de commencer à afficher les tendances au fil du temps et à superviser vos machines virtuelles Azure avec d’autres ressources cloud. Vous pouvez également choisir d’activer la fonctionnalité de carte qui vous donne des insights sur les processus en cours d’exécution sur vos machines virtuelles et leurs dépendances vis-à-vis d’autres services.

Continuez à utiliser les packs d’administration pour les fonctionnalités qui ne sont pas être fournies par d’autres fonctionnalités dans Azure Monitor. Cela comprend les packs d’administration pour les logiciels serveur critiques comme IIS, SQL Server ou Exchange. Vous pouvez également faire développer des packs d’administration personnalisés pour l’infrastructure locale qui n’est pas accessible avec Azure Monitor. Continuez également à utiliser SCOM si vous êtes étroitement intégré à vos processus opérationnels jusqu’à ce que vous puissiez passer à la modernisation de vos opérations de service là où Azure Monitor et d’autres services Azure peuvent les augmenter ou les remplacer.

Remarque

Si vous activez VM Insights avec l’agent Log Analytics au lieu de l’agent Azure Monitor, aucun agent supplémentaire ne doit être installé sur la machine virtuelle. L’agent Azure Monitor est toutefois recommandé en raison de ses améliorations significatives dans la supervision de la machine virtuelle dans le cloud. La complexité de la maintenance de plusieurs agents est compensée par la possibilité de définir la supervision dans les règles de collecte de données, ce qui vous permet de configurer différentes collectes de données pour différents ensembles de machines virtuelles, comme dans votre stratégie de conception de packs d’administration.

Migrer la logique de pack d’administration pour les charges de travail de machine virtuelle

Il n’existe aucun outil de migration pour convertir des packs d’administration SCOM en Azure Monitor, car leur logique est fondamentalement différente de celle de la collecte de données Azure Monitor. La migration de la logique de pack d’administration se concentre généralement sur l’analyse des données collectées par SCOM et l’identification des scénarios de surveillance qui peuvent être répliqués par Azure Monitor. Au fur et à mesure que vous personnalisez Azure Monitor pour répondre à vos besoins en matière d’applications et de composants, vous pouvez commencer à mettre hors service différents anciens agents et packs d’administration dans SCOM.

Les packs d’administration dans SCOM contiennent des règles et des analyses qui associent la collecte de données et l’alerte qui en résulte dans un workflow de bout en bout unique. Les données déjà collectées par SCOM sont rarement utilisées pour des alertes. Azure Monitor sépare la collecte de données et les alertes en processus distincts. Les règles d’alerte accèdent aux données des journaux Azure Monitor et des métriques Azure Monitor collectées auprès des agents. En outre, les règles et les moniteurs sont généralement axés sur des données spécifiques telles qu’un événement ou un compteur de performances particulier. Les règles de collecte de données dans Azure Monitor sont généralement plus larges pour collecter plusieurs jeux d’événements et compteurs de performances dans un seul DCR.

Consultez le contenu suivant pour obtenir des conseils sur la création d’une collecte de données et d’alertes pour des scénarios de supervision courants :

Au lieu de tenter de répliquer l’ensemble des fonctionnalités d’un pack d’administration, analysez les données de supervision fournies par chacun d’entre eux. Déterminez si vous pouvez répliquer ces exigences en matière de supervision à l’aide d’autres méthodes. Dans de nombreux cas, vous pouvez configurer la collecte de données et les règles d’alerte dans Azure Monitor de manière à répliquer suffisamment de fonctionnalités pour pouvoir mettre hors service un pack d’administration particulier. Les packs d’administration peuvent souvent inclure des centaines, voire des milliers, de règles et de moniteurs.

Une stratégie consiste à se concentrer sur les moniteurs et les règles qui ont déclenché des alertes dans votre environnement. Reportez-vous aux rapports existants disponibles dans Operations Manager, comme Alertes et Alertes les plus courantes, qui peuvent vous aider à identifier les alertes au fil du temps. Vous pouvez également exécuter la requête suivante sur la base de données Operations pour évaluer les alertes récentes les plus courantes.

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

Évaluez la sortie pour identifier les alertes spécifiques à la migration. Ignorez toutes les alertes qui ont été mises de côté ou qui sont connues pour être problématiques. Examinez vos packs d’administration pour identifier toutes les alertes critiques intéressantes qui n’ont jamais été déclenchées.

Transactions synthétiques

Les packs d’administration utilisent souvent des transactions synthétiques qui se connectent à une application ou à un service en cours d’exécution sur une machine afin de simuler une connexion utilisateur ou le trafic utilisateur réel. Si l’application est disponible, vous pouvez supposer que la machine fonctionne correctement. Les tests de disponibilité Application Insights dans Azure Monitor fournissent cette fonctionnalité. Elle fonctionne uniquement pour les applications accessibles à partir d’Internet. Pour les applications internes, vous devez ouvrir un pare-feu pour autoriser l’accès à partir d’URL Microsoft spécifiques qui effectuent le test. Vous pouvez également continuer à utiliser votre pack d’administration existant.

Étapes suivantes