Architecture Agent Client Collector
Un Agent Client Collector agent est installé ServiceNow sur vos appareils Windows, Linux et macOS pour surveiller l’infrastructure de votre entreprise et les applications installées.
Agent Client Collector Architecture : vue d’ensemble
Il Agent Client Collector est construit sur un framework Sensu et est livré avec des capacités de surveillance pour les serveurs, les bases de données, les serveurs d’applications et les middlewares. Il prend également en charge l’extension de la surveillance grâce à des vérifications supplémentaires de la communauté Sensu ou de plugins compatibles avec Nagios, ce qui vous permet de personnaliser la surveillance en fonction de vos besoins.
Surveillance avec vérifications et politiques
L’agent exécute des vérifications sur l’hôte pour recueillir des données pertinentes et les transformer en événements ou en mesures. Ces vérifications sont définies au sein ServiceNow des politiques de surveillance et y sont associées. Une politique est une combinaison des éléments de configuration (CI) surveillés et des vérifications qui s’exécutent sur ces CI. Les vérifications sont associées à des politiques visant à surveiller différents aspects du système.
Vous pouvez personnaliser les instances de vérification (par exemple, ajuster la fréquence ou spécifier des paramètres tels que les informations d’identification de connexion pour les bases de données) sans affecter la définition de vérification d’origine. La personnalisation d’une instance de vérification ne prend effet que sur l’instance de vérification associée à la politique et ne modifie pas la définition de vérification globale. Cette personnalisation garantit une certaine flexibilité dans la surveillance de différents CI dans différents scénarios.
Collecte et transmission des données
Après l’installation, l’agent collecte des informations sur son hôte et ses processus. L’agent envoie les données collectées à l’instance ServiceNow via le fichier Serveur MID. Le Serveur MID sert de pont entre l’agent et l’instance ServiceNow , garantissant que les données sont transformées et envoyées en toute sécurité pour traitement.
Sur l’instance, les CI sont créés pour l’hôte et les applications classés à partir des processus en cours d’exécution (tels que Microsoft SQL Server). Une fois ces CI créés, les politiques de surveillance actives associées aux CI sont téléchargées Serveur MID dans le répertoire de l’agent, qui transmet ensuite les politiques à l’agent pour exécution.
Stockage et utilisation des données
- Données CI : CMDB pour les éléments de configuration.
- Données d’événements : table d’événements (par exemple, alertes déclenchées par des dépassements de seuil).
Ces données peuvent être exploitées à des fins de surveillance, d’alerte et de reporting. L’intégration garantit une visibilité en temps réel de l’intégrité de votre infrastructure et de vos applications, tout en permettant une détection et une correction proactives des problèmes.
- Définissez une politique de surveillance dans l’instance ServiceNow .
- Le extrait Serveur MID les instances de vérification à partir de l’instance et les transmet à l’agent.
- L’agent exécute les vérifications, collecte les données et renvoie les résultats au Serveur MID.
- La envoie Serveur MID les données collectées à l’instance ServiceNow , où elles sont stockées dans les tables d’événements CMDB OR.
Les commandes et leurs configurations qui s’exécutent sur l’agent sont appelées vérifications. L’agent est fourni par défaut avec des définitions de vérification, qui déterminent une commande spécifique et la fréquence par défaut à laquelle elle s’exécute. Les vérifications sont définies sur l’instance et transmises à l’agent via le Serveur MID fichier .
Une politique est une combinaison des CI surveillés par et Agent Client Collector des vérifications qui s’exécutent sur ces CI. Vous associez des définitions de vérification à des politiques. Ces définitions de vérification sont alors appelées instances de vérification. Vous pouvez personnaliser les instances de vérification pour qu’elles répondent à vos besoins. Par exemple, personnalisez l’intervalle d’exécution ou les paramètres spécifiques à la stratégie, tels que les informations d’identification de connexion pour accéder à une base de données MySQL. La personnalisation d’une instance de vérification prend effet uniquement sur l’instance de vérification associée à la politique, ce qui n’affecte pas la définition de vérification d’origine ou les instances de vérification déjà créées dans d’autres politiques.