Partager via

Agents Operations Manager

  • Article

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 pour l’analyse et la 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 par un opérateur ou en réponse à une condition. Operations Manager permet à Operations Manager de surveiller les systèmes d’exploitation Windows, Linux et UNIX et les composants d’un service informatique installés sur eux, 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 les données d’événement et de performances et exécute des tâches et d’autres workflows 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 restaurée, le service Microsoft Monitoring Agent envoie les données collectées et les événements au serveur d’administration.

Remarque

  • Le service Microsoft Monitoring Agent est parfois appelé service d’intégrité.

Le service Microsoft Monitoring Agent s’exécute également sur des serveurs d’administration. Sur un serveur d’administration, le service exécute des workflows de surveillance et gère les informations d’identification. Pour exécuter des flux de travail, le service lance MonitoringHost.exe processus à l’aide d’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 à son serveur d’administration principal affecté, 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 via le port TCP 5723.

Illustration de la communication de l’agent vers le serveur d’administration.

Agent Linux/UNIX

L’architecture de l’agent UNIX et Linux diffère considérablement 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 de contrôle d’intégrité. En revanche, il transmet des informations au service de contrôle d’intégrité sur un serveur Management à é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 CIM (c’est-à-dire, d’un serveur CIM) et d’un ensemble de fournisseurs CIM. Le gestionnaire d’objets CIM est le composant serveur qui implémente la communication, l’authentification, l’autorisation et l’envoi WS-Management de requêtes aux fournisseurs. Les fournisseurs sont la clé de l’implémentation CIM dans l’agent, la définition des classes et propriétés CIM, l’interaction avec les API du noyau pour récupérer des données brutes, mettre en forme les données (par exemple, calculer des deltas et des moyennes) et traiter les demandes distribuées à partir du Gestionnaire d’objets CIM. À partir de System Center Operations Manager 2007 R2 à System Center 2012 SP1, le Gestionnaire d’objets CIM utilisé dans les agents UNIX et Linux Operations Manager est le serveur OpenPegasus. Les fournisseurs utilisés pour collecter et signaler des données de surveillance sont développés par Microsoft et open source à CodePlex.com.

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

Cela a changé 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) comme gestionnaire d’objets CIM. Dans le cas des agents UNIX/Linux Operations Manager, OMI remplace OpenPegasus. Comme OpenPegasus, OMI est une implémentation de Gestionnaire d’objets CIM open source, légère et portable, bien qu’elle soit plus légère et plus portable que OpenPegasus. Cette implémentation continue d’être appliquée dans System Center 2016 - Operations Manager et versions ultérieures.

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 d’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 utilise WS-Man sur HTTPS et l’interface WinRM. Toutes les tâches de maintenance de l’agent sont effectuées via SSH sur le port 22. Toutes les analyses d’intégrité sont effectuées sur 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 pour 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é.

Remarque

Toutes les informations d’identification mentionnées dans cet article concernent les comptes qui ont été établis sur l’ordinateur UNIX ou Linux, et non sur les comptes Operations Manager configurés pendant 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 la scalabilité avec le nombre de systèmes UNIX et Linux System Center 2016 - Operations Manager et versions ultérieures peuvent surveiller par serveur d’administration, les nouvelles API Async Windows Management Infrastructure (MI) sont disponibles au lieu des API de synchronisation WSMAN, qui sont utilisées par défaut. Pour activer cette modification, vous devez créer la nouvelle clé de Registre UseMIAPI pour permettre à Operations Manager d’utiliser les nouvelles API Async MI 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éer une clé de Registre UseMIAPI sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup.

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

Sécurité de l'agent

Authentification sur un ordinateur UNIX/Linux

Dans Operations Manager, l’administrateur système n’est plus tenu 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 Comment définir les informations d’identification pour accéder aux ordinateurs UNIX et Linux.

Authentification avec le serveur de passerelle

Les serveurs de passerelle sont utilisés pour activer la gestion des agents des ordinateurs qui se trouvent 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.

Cela vous oblige à demander des certificats pour chaque agent qui signale à un serveur de passerelle et importe ces certificats dans l’ordinateur cible à l’aide de l’outil MOMCertImport.exe, qui se trouve dans le répertoire support SupportTools\ (amd64 ou x86). 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.

Remarque

  • 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 la 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 être en mesure de connecter l’ordinateur avec RPC, et le compte d’action du serveur d’administration ou d’autres informations d’identification fournies doivent avoir un accès administratif à l’ordinateur cible.
  • Inclusion dans l’image d’installation. Il s’agit d’une installation manuelle sur une image de base utilisée pour la préparation d’autres ordinateurs. Dans ce cas, l’intégration d’Active Directory peut être utilisée pour affecter automatiquement l’ordinateur à un serveur d’administration au démarrage initial.
  • Installation manuelle. Cette méthode est utilisée quand l’agent ne peut pas être installé par une autre méthode, par exemple quand l’appel de procédure distante n’est pas disponible en raison d’un pare-feu. L’installation est exécutée manuellement sur l’agent ou déployée via un outil de distribution de logiciels existant.

Les agents installés à l’aide de l’Assistant Détection peuvent être gérés à partir de la console Opérateur, comme la mise à jour des versions d’agent, l’application de correctifs et la configuration du serveur Management auquel l’agent envoie des rapports.

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 ne pourrez pas utiliser l’intégration 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 d’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), 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 :
  • Ouverture de ports RPC commençant par le mappeur de point de terminaison TCP 135 et le port SMB (Server Message Block) TCP/UDP 445.
  • Activation du partage de fichiers et d’imprimantes pour les réseaux Microsoft et le client pour les services Réseaux Microsoft. (Cela garantit que le port SMB est actif.)
  • Si cette option est activée, 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 être définis pour autoriser les messages entrants non sollicités depuis l’adresse IP et les sous-réseaux des serveurs d’administration principaux et secondaires de l’agent.
  • Compte ayant des droits d'administrateur locaux sur l'ordinateur cible.
  • Windows Installer 3.1. Pour l’installer, consultez l’article 893803 dans la Base de https://go.microsoft.com/fwlink/?LinkId=86322 connaissances Microsoft
  • 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é.

Affectation de l’agent Active Directory

System Center Operations Manager vous permet de tirer parti de votre investissement dans services de domaine Active Directory (AD DS) en vous permettant de l’utiliser pour affecter des ordinateurs gérés par l’agent aux 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. Lorsque l’ordinateur est en ligne pour la première fois, l’agent Operations Manager interroge Active Directory pour son attribution de serveur principal et de gestion de basculement 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 natif ou supérieur à Windows 2008
  • Les ordinateurs gérés par l’agent et tous les serveurs d’administration doivent se trouver dans le même domaine ou dans des domaines approuvés bidirectionnels.

Remarque

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. C’est 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. Le compte système local sur un contrôleur de domaine dispose des droits d’administrateur de domaine ; par conséquent, il détecte tous les points de connexion de service du serveur d’administration inscrits dans Active Directory, quel que soit l’appartenance au groupe de sécurité du 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 (SCP), qui est un objet Active Directory pour publier des informations que les applications clientes peuvent utiliser pour établir une liaison à un service. Cela est créé par un administrateur de domaine exécutant l’outil en ligne de commande MOMADAdmin.exe pour 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 de MOMADAdmin.exe est autorisé à lire et supprimer des autorisations enfants sur le conteneur. Le SCP contient des informations de connexion au serveur d’administration, notamment le nom de domaine complet et le numéro de port du serveur. Les agents Operations Manager peuvent détecter automatiquement des serveurs d’administration en interrogeant les fournisseurs de services d’administration. L’héritage n’est pas désactivé et, étant donné qu’un agent peut lire les informations d’intégration inscrites dans AD, si vous forcez l’héritage pour le groupe Tout le monde à lire tous les objets au niveau racine dans Active Directory, cela affecte gravement et interrompt 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 à le faire, l’intégration AD ne fonctionne pas comme prévu et vous n’aurez pas d’affectation principale et de basculement fiable et cohérente pour les agents déployés. En outre, si vous avez plusieurs groupes d’administration, tous les agents des deux groupes d’administration seront également multi-hébergés. 

Cette fonctionnalité fonctionne bien pour contrôler l’attribution d’agent dans un déploiement de groupe d’administration distribué, afin d’empêcher les agents de créer des rapports vers des serveurs d’administration dédiés aux pools de ressources ou aux serveurs d’administration dans un centre de données secondaire dans une configuration de secours à chaud pour empêcher le basculement de l’agent pendant l’opération normale.

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

Remarque

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