Agents Operations Manager

  • Article

Important

Cette version d’Operations Manager a atteint la fin du support. Nous vous recommandons de mettre à niveau vers Operations Manager 2022.

Dans System Center Operations Manager, un agent est un service installé sur un ordinateur qui recherche des données de configuration et collecte de manière proactive des informations à des fins d’analyse et de création de rapports, mesure l’état d’intégrité des objets surveillés comme une base de données SQL ou un disque logique, et exécute des tâches à la demande d’un opérateur ou en réponse à une condition. Il permet à Operations Manager de surveiller les systèmes d’exploitation Windows, Linux et UNIX et les composants d’un service informatique installés sur ceux-ci, comme un site web ou un contrôleur de domaine Active Directory.

Agent Windows

Sur un ordinateur Windows surveillé, l’agent Operations Manager est répertorié comme service Microsoft Monitoring Agent (MMA). Le service Microsoft Monitoring Agent collecte des données d’événement et de performances, exécute des tâches et d’autres flux de travail définis dans un pack d’administration. Même si le service ne parvient pas à communiquer avec le serveur d'administration dont il dépend, le service continue d'être exécuté et met les données et événements collectés en file d'attente sur le disque de l'ordinateur analysé. Quand la connexion est rétablie, le service Microsoft Monitoring Agent envoie les données et événements collectés au serveur d’administration.

Notes

  • Le service Microsoft Monitoring Agent est parfois appelé service de contrôle d’intégrité.

Le service Microsoft Monitoring Agent s’exécute également sur les serveurs d’administration. Sur un serveur d’administration, le service exécute des flux de travail de surveillance et gère les informations d’identification. Pour exécuter des flux de travail, le service lance des processus MonitoringHost.exe à l’aide des informations d’identification spécifiées. Ces processus analysent et collectent les données du journal des événements, les données du compteur de performances, les données de l'infrastructure de gestion Windows (WMI) et exécutent des actions telles que des scripts.

Communication entre les agents et les serveurs d'administration

L'agent Operations Manager envoie des données d'alerte et de découverte au serveur d'administration principal qui lui est attribué, qui écrit les données dans la base de données opérationnelle. L'agent envoie également des événements, des performances et des données d'état au serveur d'administration principal pour cet agent, qui écrit les données dans les bases de données opérationnelle et de l'entrepôt de données simultanément.

L'agent envoie des données en fonction des paramètres de planification pour chaque règle et analyse. Pour les règles de collecte optimisées, les données sont transmises uniquement si l'échantillon d'un compteur diffère de l'échantillon précédent par une tolérance spécifiée, par exemple 10 %. Cela permet de réduire le trafic réseau et le volume des données stockées dans la base de données opérationnelle.

En outre, tous les agents envoient un paquet de données, appelé une pulsation, au serveur d'administration à intervalles réguliers, par défaut toutes les 60 secondes. L'objectif de la pulsation est de valider la disponibilité de l'agent et la communication entre l'agent et le serveur d'administration. Pour plus d'informations sur les pulsations, consultez How Heartbeats Work in Operations Manager (Fonctionnement des pulsations dans Operations Manager).

Pour chaque agent, Operations Manager exécute un observateur du service d'intégrité, qui analyse l'état du service d'intégrité à distance du point de vue du serveur d'administration. L’agent communique avec un serveur d’administration sur le port TCP 5723.

Illustration de la communication agent-serveur d’administration.

Agent Linux/UNIX

L’architecture de l’agent UNIX et Linux est très différente de celle d’un agent Windows. L’agent Windows dispose d’un service de contrôle d’intégrité chargé d’évaluer l’intégrité de l’ordinateur surveillé. L’agent UNIX et Linux n’exécute pas de service d’intégrité ; au lieu de cela, il transmet des informations au service d’intégrité sur un serveur d’administration à évaluer. Le serveur d’administration exécute tous les flux de travail pour surveiller l’intégrité du système d’exploitation définie dans notre implémentation des packs d’administration UNIX et Linux :

  • Disque
  • Processeur
  • Mémoire
  • Adaptateurs réseau
  • Système d’exploitation
  • Processus
  • Fichiers journaux

Les agents UNIX et Linux pour Operations Manager se composent d’un gestionnaire d’objets CIMOM (un serveur CIM) et d’un ensemble de fournisseurs CIM. Le Gestionnaire d’objets CIM est le composant serveur qui implémente les WS-Management la communication, l’authentification, l’autorisation et la distribution des demandes aux fournisseurs. Les fournisseurs sont au cœur de l’implémentation CIM dans l’agent, car ils définissent les propriétés et les classes CIM, ils interagissent avec les API du noyau pour extraire des données brutes, ils mettent en forme des données (par exemple, en calculant les deltas et moyennes), et ils traitent les requêtes envoyées à partir du gestionnaire d’objets CIMOM. Dans les versions allant de System Center Operations Manager 2007 R2 à System Center 2012 SP1, le gestionnaire d’objets CIMOM utilisé dans les agents d’Operations Manager UNIX et Linux est le serveur OpenPegasus. Les fournisseurs utilisés pour collecter des données d’analyse et créer des rapports sont développés par Microsoft et disponibles en open source sur CodePlex.com.

Illustration de l’architecture logicielle de l’agent UNIX/Linux Operations Manager.

Ceci a été modifiée dans System Center 2012 R2 Operations Manager, où les agents UNIX et Linux sont désormais basés sur une implémentation entièrement cohérente d’Open Management Infrastructure (OMI) en tant que Gestionnaire d’objets CIMOM. Pour les agents Operations Manager UNIX/Linux, OMI remplace OpenPegasus. À l’instar d’OpenPegasus, OMI est une implémentation open source, légère et portable du Gestionnaire d’objets CIM, bien qu’elle soit plus légère et plus portable qu’OpenPegasus. Cette implémentation continue d’être appliquée dans System Center 2016 - Operations Manager et ultérieur.

Diagramme de l’architecture logicielle mise à jour de l’agent UNIX/Linux Operations Manager.

La communication entre le serveur d’administration et l’agent UNIX et Linux est divisée en deux catégories : maintenance de l’agent et surveillance de l’intégrité. Le serveur d'administration utilise deux protocoles pour communiquer avec l'ordinateur UNIX ou Linux :

  • SSH (Secure Shell) et SFTP (Secure Shell File Transfer Protocol)

    Utilisé pour les tâches de maintenance de l’agent telles que l’installation, la mise à niveau et la suppression des agents.

  • Web Services for Management (WS-Management)

    Utilisé pour toutes les opérations d'analyse et inclut la détection d'agents déjà installés.

La communication entre le serveur d’administration Operations Manager et l’agent UNIX et Linux se fait via le protocole WS-Man over HTTPS et l’interface WinRM. Toutes les tâches de maintenance de l’agent sont effectuées via le protocole SSH sur le port 22. Toutes les analyses d’intégrité sont effectuées via le protocole WS-MAN sur le port 1270. Le serveur d’administration demande des données de performances et de configuration via WS-MAN avant d’évaluer les données en vue de fournir l’état d’intégrité. Toutes les actions, telles que la maintenance des agents, les analyses, les règles, les tâches et les restaurations, sont configurées pour utiliser des profils prédéfinis en fonction de leurs besoins pour un compte non privilégié ou privilégié.

Notes

Toutes les informations d’identification évoquées dans cet article font référence à des comptes qui ont été créés sur l’ordinateur UNIX ou Linux, et non aux comptes Operations Manager configurés lors de l’installation d’Operations Manager. Contactez votre administrateur système pour en savoir plus sur les informations d'identification et d'authentification.

Pour prendre en charge les nouvelles améliorations de l’extensibilité des systèmes UNIX et Linux que System Center 2016 – Operations Manager et ultérieur peut surveiller par le biais du serveur d’administration, les nouvelles API asynchrones de l’infrastructure de gestion Windows (MI) sont disponibles à la place des API WSMAN synchrones, qui sont utilisées par défaut. Pour permettre cette modification, vous devez créer la nouvelle clé de Registre UseMIAPI pour permettre à Operations Manager d’utiliser les nouvelles API MI asynchrones sur les serveurs d’administration qui surveillent les systèmes Linux/Unix.

  1. Ouvrez l’Éditeur du Registre à partir d’une invite de commandes avec élévation de privilèges.
  2. Créez la clé de Registre UseMIAPI sous .

Si vous devez restaurer la configuration d’origine à l’aide des API WSMAN synchrones, vous pouvez supprimer la clé de Registre UseMIAPI.

Sécurité de l'agent

Authentification sur l'ordinateur UNIX/Linux

Dans Operations Manager, l’administrateur système n’est plus obligé de fournir le mot de passe racine de l’ordinateur UNIX ou Linux au serveur d’administration. Désormais, par élévation, un compte non privilégié peut endosser l'identité d'un compte privilégié sur l'ordinateur UNIX ou Linux. Le processus d'élévation est effectué à l'aide des programmes su (superutilisateur) ou sudo UNIX qui utilisent les informations d'identification fournies par le serveur d'administration. Pour les opérations de maintenance de l'agent privilégiées qui ont recours à SSH (telles que la détection, le déploiement, les mises à niveau, la désinstallation et la récupération d'agent), la prise en charge de l'élévation su et sudo su et de l'authentification par clé SSH (avec ou sans phrase secrète) est fournie. Pour les opérations privilégiées de WS-Management (telles que l'affichage des fichiers journaux sécurisés), la prise en charge de l'élévation sudo (sans mot de passe) est ajoutée.

Pour obtenir des instructions détaillées sur la spécification des informations d’identification et la configuration des comptes, consultez Procédure de définition d’informations d’identification pour accéder à des ordinateurs UNIX et Linux.

Authentification de serveur de passerelle

Les serveurs de passerelle permettent d’autoriser la gestion par agent des ordinateurs situés en dehors de la limite d'approbation Kerberos d’un groupe d'administration. Étant donné que le serveur de passerelle réside dans un domaine qui n’est pas approuvé par le domaine dans lequel se trouve le groupe d’administration, les certificats doivent être utilisés pour établir l’identité, l’agent, le serveur de passerelle et le serveur d’administration de chaque ordinateur. Cette organisation satisfait l'exigence d'authentification mutuelle d'Operations Manager.

Vous devez demander des certificats pour chaque agent s’adressant à un serveur de passerelle et importer ces certificats sur l’ordinateur cible à l’aide de l’outil MOMCertImport.exe, qui se trouve dans le répertoire SupportTools\ (amd64 ou x86) du support d’installation. Vous devez avoir accès à une autorité de certification( CA), qui peut être une autorité de certification publique telle que VeriSign, ou vous pouvez utiliser les services de certificats Microsoft.

Déploiement des agents

Les agents System Center Operations Manager peuvent être installés à l’aide de l’une des trois méthodes suivantes. La plupart des installations utilisent une combinaison de ces méthodes pour installer différents groupes d’ordinateurs, selon les besoins.

Notes

  • Vous ne pouvez pas installer MMA sur un ordinateur, où le serveur d’administration Operations Manager, le serveur de passerelle, la console opérateur, la base de données opérationnelle, la console web, System Center Essentials ou System Center Service Manager sont installés, car leur version intégrée de MMA est déjà installée.
  • Vous pouvez utiliser l’agent MMA ou Log Analytics (version de l’extension de machine virtuelle).
  • Découverte et installation d’un ou plusieurs agents à partir de la console Opérateur. Il s’agit de la forme d’installation la plus courante. Un serveur d’administration doit pouvoir connecter l’ordinateur à l’appel de procédure distante. De plus, le compte d’action du serveur d’administration (ou autres informations d’identification fournies) doit avoir un accès administrateur à l’ordinateur cible.
  • Inclusion dans l’image d’installation. Il s’agit d’une installation manuelle dans une image de base qui est utilisée pour la préparation des autres ordinateurs. Dans ce cas, l’intégration Active Directory peut être utilisée pour attribuer automatiquement l’ordinateur à un serveur d’administration lors du démarrage initial.
  • Installation manuelle. Cette méthode est utilisée lorsque l’agent ne peut pas être installé par l’une des autres méthodes, par exemple, lorsque l’appel de procédure distante (RPC) n’est pas disponible en raison d’un pare-feu. L’installation est exécutée manuellement sur l’agent ou déployée à l’aide d’un outil existant de distribution de logiciels.

Les agents installés à l’aide de l’Assistant Découverte peuvent être gérés à partir de la console Operations, comme la mise à jour des versions de l’agent, l’application de correctifs et la configuration du serveur d’administration auquel l’agent fait rapport.

Lorsque vous installez l'agent à l'aide d'une méthode manuelle, les mises à jour de l'agent doivent également être effectuées manuellement. Vous pourrez utiliser l’intégration d’Active Directory pour affecter des agents à des groupes d’administration. Pour plus d’informations, consultez Intégration d'Active Directory et d'Operations Manager.

Sélectionnez l’onglet requis pour en savoir plus sur le déploiement de l’agent sur les systèmes Windows et UNIX et LINUX :

La découverte d’un système Windows nécessite que les ports TCP 135 (RPC), de plage RPC et TCP 445 (SMB) restent ouverts et que le service SMB soit activé sur l’ordinateur de l’agent.

  • Après la détection d'un périphérique cible, vous pouvez y déployer un agent. L'installation de l’agent nécessite :
  • L’ouverture des ports RPC commençant par le mappeur de point final TCP 135 et le port SMB TCP/UDP 445.
  • L’activation du Partage de fichiers et d'imprimantes pour les réseaux Microsoft, ainsi que des services Client pour les réseaux Microsoft (cela garantit que le port SMB est actif).
  • S'ils sont activés, les paramètres de stratégie de groupe du pare-feu Windows pour Autoriser l'exception d'administration à distance et Autoriser l'exception de partage de fichiers et d'imprimantes doivent avoir la valeur « Autoriser les messages entrants non sollicités provenant de : » définie sur l'adresse IP et les sous-réseaux des serveurs d'administration principal et secondaire pour l'agent.
  • Compte ayant des droits d'administrateur locaux sur l'ordinateur cible.
  • Windows Installer 3.1. Pour l’installer, consultez l'article 893803 de la Base de connaissances Microsoft https://go.microsoft.com/fwlink/?LinkId=86322
  • Microsoft Core XML Services (MSXML) 6 sur le support d'installation du produit Operations Manager dans le sous-répertoire \msxml. L’installation de l’agent Push installe MSXML 6 sur l’appareil cible s’il n’est pas déjà installé.

Attribution d'agents Active Directory

System Center Operations Manager vous permet de tirer pleinement profit de vos services de domaine Active Directory (AD DS) en vous donnant la possibilité de les utiliser pour affecter des ordinateurs gérés par agent à des groupes d’administration. Cette fonctionnalité est couramment utilisée avec l’agent déployé dans le cadre d’un processus de génération de déploiement de serveur. Quand l’ordinateur est en ligne pour la première fois, l’agent Operations Manager interroge Active Directory afin de connaître le serveur d’administration principal et de basculement qui lui est attribué, et démarre automatiquement la surveillance de l’ordinateur.

Pour affecter des ordinateurs à des groupes d'administration à l'aide d'AD DS :

  • Le niveau fonctionnel des domaines AD DS doit être Windows 2008 natif ou versions ultérieures
  • Les ordinateurs gérés par agent et tous les serveurs d'administration doivent se trouver dans le même domaine ou dans des domaines approuvés bidirectionnels.

Notes

Un agent qui détermine qu’il est installé sur un contrôleur de domaine n’interroge pas Active Directory pour obtenir des informations de configuration. et ce, pour des raisons de sécurité. L’intégration Active Directory est désactivée par défaut sur les contrôleurs de domaine, car l’agent s’exécute sous le compte Système local. Sur un contrôleur de domaine, le compte Système local dispose des droits d’administrateur de domaine. Par conséquent, il détecte tous les points de connexion de service de serveur d’administration qui sont inscrits dans Active Directory, quel que soit le groupe de sécurité auquel appartient le contrôleur de domaine. Par conséquent, l’agent tente de se connecter à tous les serveurs d’administration de tous les groupes d’administration. Les résultats peuvent être imprévisibles, ce qui présente un risque de sécurité.

L’attribution de l’agent est effectuée à l’aide d’un point de connexion de service, qui est un objet Active Directory servant à publier des informations que les applications clientes peuvent utiliser pour lier un service. Un administrateur de domaine crée cet objet en exécutant l’outil en ligne de commande MOMADAdmin.exe afin de créer un conteneur AD DS pour un groupe d’administration Operations Manager dans les domaines des ordinateurs qu’il gère. Le groupe de sécurité AD DS spécifié lors de l’exécution deMOMADAdmin.exe dispose des autorisations Lecture et Suppression enfant sur le conteneur. Le point de connexion de service contient les informations de connexion au serveur d’administration, y compris le nom de domaine complet du serveur et le numéro de port. Les agents Operations Manager peuvent découvrir automatiquement les serveurs de gestion en interrogeant des points de connexion de service. L’héritage n’est pas désactivé et, comme un agent peut lire les informations d’intégration inscrites dans AD, si vous forcez l’héritage pour que le groupe Tout le monde lit tous les objets au niveau racine dans Active Directory, cela affectera gravement et interrompra essentiellement les fonctionnalités d’intégration AD. Si vous forcez explicitement l’héritage dans l’ensemble du répertoire en accordant des autorisations de lecture au groupe Tout le monde, vous devez bloquer cet héritage sur le conteneur d’intégration AD de niveau supérieur, nommé OperationsManager et tous les objets enfants.  Si vous ne parvenez pas à effectuer cette opération, l’intégration AD ne fonctionnera pas comme prévu et vous n’aurez pas d’affectation principale et de basculement fiable et cohérente pour les agents déployée. De plus, si vous avez plusieurs groupes d’administration, tous les agents présents dans les deux groupes d’administration seront également multirésidents. 

Cette fonctionnalité est utile pour contrôler l’attribution de l’agent dans un déploiement de groupe d’administration distribué. Elle permet d’empêcher les agents de communiquer avec les serveurs d’administration qui sont dédiés aux pools de ressources ou aux serveurs d’administration d’un centre de données secondaire dans une configuration de secours semi-automatique afin d’éviter le basculement de l’agent lors d’un fonctionnement normal.

La configuration de l’affectation d’agent est gérée par un administrateur Operations Manager à l’aide de l’Assistant Affectation et basculement des agents pour affecter les ordinateurs à un serveur d’administration principal et à un serveur d’administration secondaire.

Notes

L'intégration Active Directory est désactivée pour les agents qui ont été installés à partir de la console Opérateur. Par défaut, l'intégration Active Directory est activée pour les agents installés manuellement à l'aide de MOMAgent.msi.

Étapes suivantes