Partage via

Migrer de System Center Operations Manager vers Azure Monitor

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

Il n’existe aucun processus standard pour la migration à partir de System Center Operations Manager. Vous pouvez vous appuyer sur les packs d’administration SCOM pendant une période prolongée, plutôt que sur l’exécution d’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 du cloud hybride

La plupart des clients utilisent une stratégie de supervision du cloud hybride qui vous permet d’effectuer une transition progressive vers le cloud. Cette approche vous permet de maintenir vos processus métier existants au fur et à mesure que vous vous familiarisez avec la nouvelle plateforme. Ne vous éloignez que de la fonctionnalité System Center Operations Manager, car vous pouvez la remplacer par Azure Monitor. Plusieurs outils de supervision ajoutent de la complexité. Toutefois, ils vous permettent de tirer parti de la capacité d’Azure Monitor à surveiller les charges de travail cloud de nouvelle génération. En même temps, vous pouvez conserver la capacité de System Center Operations Manager à surveiller les logiciels et charges de travail du serveur.

Votre environnement avant de déplacer des composants dans Azure est basé sur des machines virtuelles et physiques situées localement ou avec un fournisseur de services managés. Il s’appuie sur System Center Operations Manager pour surveiller les applications métier, les logiciels serveur et d’autres composants d’infrastructure dans votre environnement, tels que les serveurs physiques et les réseaux. Vous utilisez des packs d’administration standard pour les logiciels serveur tels qu’Internet Information Service (IIS), SQL Server et divers logiciels fournisseurs, et vous ajustez ces packs d’administration pour répondre à vos besoins spécifiques. Vous créez des packs d’administration personnalisés pour vos applications métier et composants qui ne peuvent pas être surveillés avec des packs d’administration existants. Vous configurez également System Center Operations Manager pour prendre en charge vos processus métier.

Lorsque vous déplacez des services dans le cloud, Azure Monitor commence à collecter des 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 des 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 surveillance 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 System Center Operations Manager. Étant donné que chaque système dispose de ses propres alertes, vous devez créer des groupes d’actions dans Azure Monitor équivalents à vos groupes de notification dans System Center Operations Manager.

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

Méthode Descriptif
Agents à double hébergement System Center Operations Manager utilise Microsoft Management Agent (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 à System Center Operations Manager et à Azure Monitor. Cette configuration nécessite que vos machines virtuelles Azure aient une connexion à vos serveurs d’administration locaux.

L’agent Log Analytics est remplacé par l’agent Azure Monitor, qui offre des avantages significatifs, notamment une gestion plus simple et un meilleur contrôle sur la collecte de données. Les deux agents peuvent coexister sur la même machine, ce qui vous permet de vous connecter à Azure Monitor et System Center Operations Manager. Cette configuration est une meilleure option que le double hébergement de l’agent hérité 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 System Center Operations Manager vers Azure Monitor. Cette configuration est similaire à l’utilisation d’agents à double accueil, mais ne nécessite pas que chaque agent soit configuré pour se connecter à Azure Monitor. Cette stratégie nécessite l’agent hérité. Vous ne pouvez donc pas spécifier la surveillance avec des règles de collecte de données (DCR). Vous ne pouvez pas non plus utiliser VM Insights, sauf si vous connectez chaque machine virtuelle directement à Azure Monitor.
Instance gérée SCOM L’instance managée SCOM est une implémentation complète de System Center Operations Manager dans Azure, ce qui vous permet de continuer à exécuter les mêmes packs d’administration que ceux que vous exécutez dans votre environnement System Center Operations Manager local. Vous pouvez continuer à utiliser la même console d'opérations pour analyser votre santé et vos alertes. Vous pouvez également afficher des alertes dans Azure Monitor et analyser les données System Center Operations Manager dans Grafana.

SCOM MI est similaire à la maintenance de votre environnement System Center Operations Manager existant et des agents double homing, bien que vous puissiez consolider votre configuration de surveillance 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 managée System Center Operations Manager dans Azure plutôt que de se connecter à des serveurs d’administration dans votre propre centre de données.
Pack d’administration Azure Le pack d’administration Azure permet à Operations Manager de découvrir les ressources Azure et de surveiller leur intégrité en fonction d’un ensemble particulier de scénarios de supervision. Ce pack d’administration vous oblige à effectuer une configuration supplémentaire pour chaque ressource dans Azure. Il peut être utile de fournir une visibilité de vos ressources Azure dans la console Opérateur jusqu’à ce que vous évoluez vos processus métier pour vous concentrer sur Azure Monitor.

Surveiller les applications métier

Vous avez généralement besoin de packs d’administration personnalisés pour surveiller vos applications métier avec System Center Operations Manager, à l’aide d’agents installés sur chaque machine virtuelle. Application Insights dans Azure Monitor surveille les applications web, qu’elles se présentent dans Azure, d’autres clouds ou localement. Elle peut être utilisée pour toutes vos applications, que vous les ayez migrées ou non vers Azure.

Si votre supervision d’une application métier est limitée aux fonctionnalités fournies par le modèle de performances d’application .NET dans System Center Operations Manager, vous pouvez probablement migrer vers Application Insights sans perte de fonctionnalités. En fait, Application Insights inclut un nombre important d’autres fonctionnalités, notamment :

  • Découvrez et surveillez automatiquement les composants d’application.
  • Collectez 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 navigateur telles que les vues de page et les performances de chargement.
  • Détecter les exceptions et explorer l’arborescence des appels de procédure et les requêtes connexes.
  • Effectuez une analyse avancée à l’aide de fonctionnalités telles que le suivi distribué et la détection intelligente.
  • Utilisez Metrics Explorer pour analyser de manière interactive les données de performances.
  • Utilisez des requêtes de journal pour analyser de manière interactive les données de télémétrie collectées avec les données collectées pour les services Azure et VM Insights.

Il existe certains scénarios dans lesquels vous devrez peut-être continuer à utiliser System Center Operations Manager en plus d’Application Insights, jusqu’à ce que vous puissiez obtenir les fonctionnalités requises. Voici quelques exemples où vous devrez peut-être continuer avec System Center Operations Manager :

  • Les tests de disponibilité, qui vous permettent de surveiller et d’alerter sur la disponibilité et la réactivité de vos applications, nécessitent des requêtes entrantes à partir des adresses IP des agents de test web. Si votre stratégie n’autorise pas ce type d’accès, vous devrez peut-être continuer à utiliser des moniteurs de disponibilité d’application web dans System Center Operations Manager.
  • Dans System Center Operations Manager, vous pouvez définir n’importe quel intervalle d’interrogation pour les tests de disponibilité, avec de nombreux clients qui vérifient toutes les 60 à 120 secondes. Application Insights a un intervalle d’interrogation minimal de cinq minutes, qui peut être trop long pour certains clients.
  • Une quantité importante de surveillance dans System Center Operations Manager est effectuée en collectant les événements générés par les applications et en exécutant des scripts sur l’agent local. Ces options ne sont pas standard dans Application Insights. Vous pouvez donc exiger un travail personnalisé pour atteindre vos besoins métier. Cela peut inclure des règles d’alerte personnalisées à l’aide de données d’événement stockées dans un espace de travail Log Analytics et des scripts lancés dans un invité de machines virtuelles à l’aide d’un Runbook Worker hybride.
  • Selon la langue dans laquelle votre application est écrite, vous pouvez être limité dans l’instrumentation que vous pouvez utiliser avec Application Insights.

Après la stratégie de base dans les autres sections de ce guide, continuez à utiliser System Center Operations Manager pour vos applications métier, mais tirez parti d’autres fonctionnalités fournies par Application Insights. Comme vous pouvez remplacer les fonctionnalités critiques par Azure Monitor, vous pouvez commencer à 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 System Center Operations Manager, en fonction des exigences des charges de travail exécutées sur vos machines virtuelles. Dès qu’une machine virtuelle est créée dans Azure, les métriques de plateforme et lesjournaux d’activité de l’hôte de machine virtuelle commencent automatiquement à être collectés. Activez les alertes recommandées pour vous avertir des erreurs courantes pour l’hôte de machine virtuelle, comme le serveur en panne 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 System Center Operations Manager. Toutefois, il vous permet de commencer à afficher les tendances au fil du temps et de surveiller vos machines virtuelles Azure avec d’autres ressources cloud. Vous pouvez également choisir d’activer la fonctionnalité de carte, ce qui vous donne des informations sur les processus s’exécutant sur vos machines virtuelles et leurs dépendances sur d’autres services.

Continuez à utiliser des packs d’administration pour les fonctionnalités qui ne sont pas fournies par d’autres fonctionnalités dans Azure Monitor. Cela inclut des packs d’administration pour les logiciels serveur critiques tels que IIS, SQL Server ou Exchange. Vous pouvez également avoir des packs d’administration personnalisés développés pour une infrastructure locale qui ne peut pas être atteinte avec Azure Monitor. Continuez à utiliser System Center Operations Manager s’il est étroitement intégré à vos processus opérationnels. Une fois que vous pouvez passer à la modernisation de vos opérations de service, Azure Monitor et d’autres services Azure peuvent l’augmenter ou le remplacer.

Remarque

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

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

Il n’existe aucun outil de migration pour convertir les packs d’administration SCOM en Azure Monitor, car leur logique est fondamentalement différente de la collecte de données Azure Monitor. La migration de la logique du pack d’administration se concentre généralement sur l’analyse des données collectées par System Center Operations Manager et l’identification de ces scénarios de surveillance qui peuvent être répliqués par Azure Monitor. Lorsque vous personnalisez Azure Monitor pour répondre à vos besoins pour différentes applications et composants, vous pouvez commencer à mettre hors service différents packs d’administration et agents hérités dans System Center Operations Manager.

Les packs d’administration dans System Center Operations Manager contiennent des règles et des moniteurs qui combinent la collecte de données et l’alerte résultante dans un flux de travail de bout en bout unique. Les données déjà collectées par System Center Operations Manager sont rarement utilisées pour les alertes. Azure Monitor sépare la collecte et les alertes de données 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 particulier ou un compteur de performances. Les règles de collecte de données dans Azure Monitor sont généralement plus larges en collectant plusieurs ensembles d’événements et de compteurs de performances dans une même DCR.

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

Au lieu de tenter de répliquer l’ensemble des fonctionnalités d’un pack d’administration, analysez la supervision critique que chacun fournit. Déterminez si vous pouvez répliquer ces exigences de surveillance à l’aide d’autres méthodes. Dans de nombreux cas, vous pouvez configurer des règles de collecte et d’alerte de données dans Azure Monitor qui répliquent suffisamment de fonctionnalités que vous pouvez mettre hors service un pack d’administration particulier. Les packs d’administration peuvent souvent inclure des centaines et même des milliers de règles et de moniteurs.

Une stratégie consiste à se concentrer sur ces moniteurs et règles qui ont déclenché des alertes dans votre environnement. Reportez-vous aux rapports existants disponibles dans Operations Manager, tels que les alertes et les 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 les plus 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 des alertes spécifiques pour la migration. Ignorez les alertes qui ont été ignorées ou qui sont connues comme 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 s’exécutant sur un ordinateur pour simuler une connexion utilisateur ou un trafic utilisateur réel. Si l’application est disponible, vous pouvez supposer que la machine s’exécute correctement. Les tests de disponibilité Application Insights dans Azure Monitor fournissent cette fonctionnalité. Il 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 effectuant le test. Vous pouvez également continuer à utiliser votre pack d’administration existant.

Étapes suivantes