Documentation ServicePilot SaaS

Collecte des données

Les agents ServicePilot collectent ou reçoivent des données à ajouter à la base de données de ServicePilot. La configuration de ServicePilot détermine ce qui doit être conservé et pour combien de temps. Selon la source de données surveillée, d'autres statistiques calculées peuvent être stockées.

Exemple: Un serveur est recherché pour obtenir disk size et disk bytes used. En utilisant ces informations, un disk usage percentage est calculé et stocké dans la base de données.

Données interrogées

De nombreuses statistiques collectées par ServicePilot sont obtenues en interrogeant les équipements toutes les minutes pour obtenir leur valeur ou statut actuel. Les statistiques collectées sont définies dans les packages provisionnés et sont affectées par la configuration des ressources et par les policies appliquées à ces ressources.

Interrogation Ping

Un exemple simple de données interrogées est un Ping ou ICMP Echo vers une adresse IP. Dans la configuration de ServicePilot, si une ressource est ajoutée avec une adresse IP distante à interroger, alors les données renvoyées contiennent le temps de réponse en millisecondes entre l'agent ServicePilot et l'adresse IP distante.

Une fois par minute, l'agent ServicePilot enverra le Ping et attendra la réponse. Si l'agent ServicePilot n'obtient pas de réponse, il essaiera une deuxième fois, dans la même minute. S'il n'obtient de réponse à aucune des deux requêtes, l'objet ServicePilot sera considéré comme étant dans un état no response pending. Une deuxième minute de polling peut réussir ou échouer. En fonction du nombre de fois où cela doit être confirmé, l'objet passera au statut no response. Ceci provoquera le passage de l'objet dans l'état unavailable.

La fréquence de l'interrogation, le nombre de confirmations et l'état dans lequel l'objet se retrouvera peuvent tous être modifiés en appliquant policies.

Interrogation SNMP

Des données peuvent être obtenues en interrogeant des équipements à l'aide de l'interrogation SNMP. Ceci est similaire à l'interrogation Ping mais avec quelques différences. Les données obtenues comprennent un certain nombre de requêtes SNMP OID, soit pour des valeurs individuelles, soit pour une table entière de données.

En général, les OIDs individuels seront obtenus toutes les minutes tandis que les tables seront téléchargées toutes les 6 heures. Les tables de découverte sont récupérées selon la frequence de découverte et sont utilisées pour vérifier si de nouveaux éléments ont été ajoutés. De nouveaux objets sont ensuite créés puis interrogés toutes les minutes.

Exemple: Un switch est supervisé pour obtenir des données à partir d'un certain nombre d'interfaces Ethernet actives. Toutes les 6 heures, la liste des interfaces actives est téléchargée et les interfaces précédemment inactives sont ajoutées à la liste des interfaces pour ensuite être interrogées toutes les minutes.

Si des modifications de configuration sont apportées aux ressources, les scripts de découverte associés sont relancés juste après que les modifications aient été appliquées.

Un objet qui obtient des données par interrogation SNMP passera par défaut dans un état no response pending s'il n'a pas reçu de données dans la minute (sans confirmation). Cela signifie que l'objet passera directement dans le statut no response s'il ne reçoit pas de données. Dans ce cas, l'objet passe alors dans l'état unknown. La raison d'utiliser unknown plutôt que unavailable est qu'il est fréquent d'avoir un objet Ping pour le même équipement, et afin d'éviter les multiples alertes pour le même problème, il est préférable d'avoir un seul objet qui devient unavailable.

La fréquence de l'interrogation, la fréquence de découverte, le nombre de confirmations et l'état dans lequel l'objet est transitionné peuvent tous être modifiés en appliquant policies.

Autres types d'interrogation

Les agents ServicePilot utilisent de nombreuses autres méthodes pour obtenir des données à partir des équipements. Par exemple, les requêtes WMI Windows, les vérifications de port TCP, les requêtes SQL et les requêtes de pages Web, entre autres. Dans ces cas, la fréquence d'interrogation est déterminée par le package et la configuration des ressources.

Resource polling interval

La fréquence minimale d'interrogation est toujours de 1 minute, mais il est fréquent d'interroger les éléments moins souvent. Notez que même si la fréquence d'interrogation est définie, cela ne vous permet pas de spécifier à quelle heure chaque interrogation aura lieu. Pour cette raison, le fait de paramétrer une grande valeur de fréquence d'interrogation n'a pas beaucoup de sens car vous ne saurez pas à quel moment l'interrogation se produira dans la journée.

Pour tous ces autres types de collecte de données classés comme custom, l'état no response de l'objet sera défini après un certain nombre de minutes pendant lesquelles aucune donnée n'a été envoyée entre l'agent ServicePilot et ServicePilot.

Lorsque l'objet est déterminé comme étant dans un état no response, le statut de l'objet passera à unknown ou unavailable (selon la définition du package utilisé).

Par exemple, un objet web check passera dans l'état unavailable si aucune donnée n'est reçue pendant une heure. Web App No response

Un objet server disk passera dans l'état unknown si aucune donnée n'est reçue pendant 10 minutes. Server Disk No response

La durée de no response avant qu'un délai d'attente ne soit déclaré et le statut à utiliser peuvent être modifiés en appliquant policies.

Supervision des périodes

Par défaut, ServicePilot interroge et stocke les données en permanence. Il est possible de modifier ce comportement en utilisant des policies de monitoring qui incluent des périodes pour la collecte des données.

Exemple: Appliquez une policy de monitoring sur une vue contenant toutes les ressources d'un site. Cette policy de monitoring contient une définition de période indiquant que la surveillance ne doit avoir lieu que pendant les heures de travail de l'entreprise. En dehors de ce créneau, les ressources du site ne seront pas surveillées et leur état sera unknown.

Time period definition

Monitoring policy with Time period definition

Il est souvent utile de définir des périodes de surveillance lorsque l'on sait que des éléments ont des phases d'arrêt pour la maintenance, ou bien des redémarrages programmés.

Gestion des objets

Bien que les périodes de maintenance ou les redémarrages programmés puissent se produire à des moments connus, une gestion ad hoc des ressources peut être nécessaire pour arrêter d'alerter sur les problèmes en cours de traitement.

Exemple: Une interface réseau cause des problèmes et a été mise hors service jusqu'à ce que le problème soit résolu. L'alerte ServicePilot pour cette interface doit être désactivée.

Il est possible de déclarer comme unmanage un objet individuel ou une partie entière de la hiérarchie supervisée en sélectionnant une vue. L'accès à la fonction unmanage est disponible dans la hiérarchie de vues ou dans la liste de statuts.

Accès à la fonction Unmanage sur un objet depuis la carte

  1. En tant qu'utilisateur avec au moins les privilèges operator, naviguez dans la Carte jusqu'à ce que l'objet que vous souhaitez mettre en unmanage soit ouvert Map menu item
  2. Cliquez sur le bouton ManageManage button

Accès à la fonction Unmanage sur une vue depuis la carte

  1. En tant qu'utilisateur avec au moins les privilèges operator, naviguez dans la Carte jusqu'à ce que la vue que vous souhaitez mettre en unmanage soit ouverte Map menu item
  2. Cliquez sur l'icône View information View information icon
  3. Cliquez sur le bouton Manage Manage button

Accès à la fonction Unmanage à partir des listes de statuts

  1. En tant qu'utilisateur avec au moins les privilèges operator, naviguez jusqu'à Status Status menu item
  2. Sélectionnez Ressource, Objet ou Vue dans le sous-menu Statut dépendant du composant que vous souhaitez mettre en unmanage Status sub-menu
  3. Sélectionnez un ou plusieurs éléments à mettre en unmanage puis cliquez sur le bouton gris unmanage Manage button

Mettre en Manage ou Unmanage les éléments

Une fois la boîte de dialogue de gestion ouverte, vous pouvez choisir de mettre en manage (redémarrer la surveillance) ou unmanage (arrêter la surveillance) l'élément sélectionné. Si vous avez sélectionné une vue, cela va affecter la vue et tous ses sous-éléments.

Lorsqu'on "unmanage" un élément, on peut aussi demander à ServicePilot d'arrêter le stockage des données de cet élément dans la base de données. Si on unmanage simplement l'élément, les données d'indicateurs surveillés seront toujours récupérées et stockées mais le statut des éléments sera unknown.

Si vous souhaitez démarrer l'opération ultérieurement ou indiquer quand ServicePilot doit recommencer la surveillance, vous pouvez remplir les champs date et heure. Ceux-ci sont optionnels car l'action par défaut est d'arrêter ou de démarrer l'opération immédiatement.

Une note peut être ajoutée pour que les utilisateurs de ServicePilot puissent comprendre pourquoi cette action a été effectuée.

Manage dialog

Supprimer des objets

Bien que rarement nécessaire, il est possible de supprimer des objets de la configuration de ServicePilot. Seuls les objets créés automatiquement par ServicePilot peuvent être supprimés de cette façon. Pour arrêter la surveillance des équipements, c'est généralement un utilisateur administrateur de ServicePilot qui va supprimer la ressource de la configuration ou modifier les paramètres de la ressource pour arrêter la surveillance d'un élément particulier.

La suppression d'un objet ne supprimera pas les données historiques associées à cet objet de la base de données, de sorte qu'il sera toujours affiché dans les tableaux de bord qui interrogent les informations lorsque l'objet était encore présent.

Notez que si un objet est supprimé, il peut réapparaître si le composant est toujours présent lors de l'exécution du prochain script de découverte. Dans ce cas, l'objet doit être supprimé à l'aide des filtres présents dans les paramètres de la ressource, et si cela n'est pas possible, alors il est toujours possible de mettre en unmanage l'objet.

Exemple: ServicePilot surveille un serveur avec plusieurs volumes de disque. L'un des volumes du disque est supprimé définitivement. L'objet correspondant peut être supprimé car il ne réapparaîtra normalement plus jamais.

Supprimer un objet de la carte

  1. En utilisant un compte avec des privilèges administrateurs, naviguez dans la Carte jusqu'à ce que l'objet que vous souhaitez supprimer soit ouvert Map menu item
  2. Cliquez sur le lien Delete ObjectDelete Object link

Données sur les événements

Certaines données que ServicePilot reçoit peuvent être basées sur des événements non sollicités. Par exemple, un message syslog ou un Trap SNMP est envoyé à l'Agent ServicePilot.

Ce type de données est associé à la ressource qui a été utilisée pour configurer l'Agent ServicePilot afin qu'il accepte ces données. Cependant, les données ne sont pas stockées comme indicateurs dans les objets. En revanche, les événements sont stockés dans la base de données en fonction du type de données (Syslogs, SNMP Traps, VoIP call records). Des tableaux de bord sont ensuite mis à disposition pour visualiser ces données d'événements de manière standard. Des requêtes personalisées peuvent être ajoutées afin de filtrer les données ou afficher les informations d'une autre manière.

Rétention des données

ServicePilot conserve les données pendant une période limitée afin de réduire l'espace disque requis et de gérer la vitesse d'exécution des requêtes. Les données numériques des indicateurs peuvent être résumées et conservées plus longtemps, mais sous forme de moyennes, de minimums et de maximums des données réellement collectées. Il est donc possible de créer un graphique d'un indicateur en ne considérant que les moyennes journalières sur une année. Si vous effectuez ensuite un zoom sur une période plus courte, vous pouvez voir les moyennes horaires, mais seulement sur les 3 derniers mois, ou les moyennes par quart d'heure sur le dernier mois ou les données à la minute, mais seulement sur les 7 derniers jours.

D'autres types de données ne peuvent pas être compressés de cette façon et les données sont donc conservées moins longtemps. C'est aussi une opération beaucoup plus coûteuse en temps d'exécution pour interroger ces données, donc choisir une période de temps plus courte vous permettra d'obtenir des résultats plus rapidement.

Certaines données sont stockées dans la base de données, mais aucun historique n'est conservé. Par exemple, c'est le cas pour le statut actuel de tous les objets et les données d'inventaire.

Note: La surveillance gratuite de ServicePilot ne stocke aucune donnée historique dans la base de données. Seul le statut actuel des ressources surveillées est visible. De nombreux tableaux de bord et rapports seront donc vides.

Type de données Rétention
Données des indicateurs 7 jours
Données récapitulatives des indicateurs sur quart d'heure 30 jours
Données récapitulatives des indicateurs par heure 90 jours
Données récapitulatives des indicateurs par jour 365 jours
Disponibilité et performance des objets 90 jours
Résumé quotidien de la disponibilité et de la performance des objets 365 jours
Evénements et changements de statut détectés par ServicePilot 90 jours
Syslogs 60 jours
Traps SNMP et notifications 60 jours
Enregistrements de qualité des appels VoIP 90 jours
IP Flow, IPFIX, NetFlow, sFlow, Jflow 30 jours
Traces d'applications Web 7 jours
Données de logs associées aux objets 30 jours

Commencez Maintenant