La vue /root contient les objets suivants après l'installation initiale de SKOOR Engine et Dashboards :

Objet	Fonction
`<Customer_Site>`	Structure prédéfinie pour les configurations client. C'est généralement l'endroit avec lequel travailler. `<Customer_Site>` est un espace réservé à renommer en nom de l'entreprise ou du projet.
`Dashboards`	Un groupe contenant tous les objets du tableau de bord (y compris leurs vignettes et widgets)
`SKOOR system`	Le groupe par défaut dans lequel SKOOR Engine place les appareils, les tâches et les éléments de configuration pour se surveiller lui-même et ses collecteurs externes.
`Collectors`	Un objet spécial contenant tous collecteurs SKOOR Engine . Ceux-ci collectent toutes les mesures effectuées par les travaux et les transmettent au server SKOOR Engine . Le collecteur par défaut s'appelle collecteur -local et s'exécute sur le server SKOOR. collecteurs externes sont utilisés pour atteindre les hôtes de différents réseaux. Comme collecteurs ne sont que des utilisateurs standard avec l'indicateur collecteur défini, ils sont créés dans le groupe Utilisateurs. Collecteurs ont un état : ok (vert) signifie qu'ils sont connectés et fournissent actuellement des données de mesure au server , majeur (rouge) signifie qu'ils sont déconnectés.
`Alarming`	Un objet spécial contenant tous les dispositifs d'alarme et groupes d'alarmes.
`Configurations`	Un objet spécial contenant tous les objets de configuration. Par défaut, il contient des sous-groupes pour les types d'objets suivants : Filtrer la carte Contient tous les objets de carte de filtre disponibles dans SKOOR. Les cartes de filtre sont des objets dont le contenu est lié dynamiquement en fonction de propriétés spécifiques Moniteur des opérations Contient tous les objets du moniteur d'opérations disponibles dans SKOOR Le moniteur d'opérations offre des aperçus configurables sur l'état des objets disponibles dans le SKOOR Engine Il répertorie les états SLO et SLC, les objets qui ont émis des alarmes actuellement ou dans le passé, les entrées syslog du SKOOR Engine ou d'autres server et les maintenances planifiées. Élément d'information Contient tous les objets d’éléments d’information disponibles dans SKOOR. Les éléments d'information sont des objets descriptifs qui peuvent contenir du texte formaté, des listes, des images bitmap ou des hyperliens et peuvent être attachés à des groupes ou des appareils. Emplacement Contient tous les emplacements disponibles dans SKOOR Ceux-ci sont gérés via le menu Admin et représentent des emplacements géographiques (nom du lieu correspondant aux coordonnées géographiques) Les emplacements peuvent être attribués à de nombreux objets en tant que propriétés Graphique Contient tous les tracés d'historique d'état ou de valeur préconfigurés disponibles dans SKOOR Ceux-ci peuvent être utilisés dans des cartes, des cartes enfants ou séparément Importer / Exporter Contient tous les objets d'export CSV ou XML disponibles dans SKOOR Calendrier Contient tous les objets de planification disponibles dans SKOOR Ceux-ci sont utilisés pour définir les temps actifs ou inactifs pour l'exécution des tâches, les contrôleurs de niveau de service (SLC), les groupes/périphériques d'alarme ou les limites d'alarme. Tableau de bord Contient tous les objets du tableau de bord disponibles dans SKOOR. Ce sont les tableaux de bord eux-mêmes, ainsi que leurs vignettes et widgets Les éléments de configuration suivants sont obsolètes mais peuvent toujours être disponibles sur le système : Carte Carte enfant Carte géographique Élément de carte Gestion des services aux entreprises Si par exemple ailleurs dans l'arborescence SKOOR Engine un objet de type Schedule est créé, il sera automatiquement lié également au groupe /root/Configurations/Schedule.
`Templates`	Un objet spécial contenant tous les objets modèles.
`Users`	Un objet spécial contenant tous les objets utilisateur et groupe d'utilisateurs.
`Lost+Found`	Un objet spécial contenant tous les objets qui, pour une raison quelconque, ont perdu leur lien parent. Il ne devrait y avoir aucun objet en dessous ici.

Structure d'objet recommandée

Les objets nouvellement créés peuvent être regroupés de différentes manières. Ils peuvent être regroupés par localisation (ville, bâtiment, étage, succursale de l'entreprise) ou par tout ce qui correspond le mieux à l'entreprise ou à l'organisation du projet. Grâce à sa structure ouverte, SKOOR Engine permet de créer très facilement diverses vues, par exemple par type d'appareil ou par responsabilité. La structure de l'objet varie en fonction des attentes du client en matière de surveillance. SKOOR Engine peut être utilisé exclusivement pour le suivi technique ou principalement en tant que superposition pour le suivi des services métiers et informatiques. La plupart des configurations représentent une combinaison de surveillance de l'infrastructure et des services. SKOOR recommande de mettre en place de tels projets de surveillance en utilisant une structure d'objet similaire à la suivante :

/root
- <Customer or project name>
  - Configurations
    - Graphs
    - Import / export
    - OPM
    - Schedule
    - ...
  - Devices
    - Databases
    - EEM (End to end monitoring robot devices)
    - Network
      - Firewalls
      - Load balancers
      - Routers
      - Switches
      - Wireless
      - ...
    - Other
    - Printers
    - Servers
      - Servers by location
        London
        lx203
        lx204
        Zürich
      - Servers by OS
        Linux servers
        Dev
        Prod
        lx203
        ICMP
        Disk space
        CPU / Memory
        Service slapd
        lx204
        ICMP
        Disk space
        CPU / Memory
        Service slapd
        Windows servers
        ...
    - Storage
    - Virtualization hosts
  - Reports
    - Business service 1 service report
    - Business service 1 service report monthly scheduler
    - Business service 1 service report weekly scheduler
  - Services
    - SLCs
      - SLA Business service 1 monthly
        Business service 1
      - SLA Business service 1 yearly
        Business service 1
    - SLOs
      - Business service 1
        Function DB
        DB Server 1
        DB Server 2
        Function LDAP (correlation rule: 1 of 2)
        LDAP Server 1
        ICMP on lx203
        Disk space on lx203
        CPU / Memory on lx203
        Service slapd on lx203
        LDAP Server 2
        ICMP on lx204
        Disk space on lx204
        CPU / Memory on lx204
        Service slapd on lx204
        Function Network
        DHCP
        DHCP 1
        DHCP 2
        DNS
        NTP
        Function Webserver
        ...
      - IT service 1

L'exemple ci-dessus montre comment créer une structure de base pour la surveillance des services.

Inventaire des appareils

La première étape consiste généralement à créer les objets périphérique quelque part en dessous du groupe Périphériques . Ici, le groupe Périphériques a été structuré par fonction de périphérique (Serveurs, Stockage...) d'abord, puis soit par sous-fonction soit par d'autres critères. Par exemple, les serveurs Linux lx203 et lx204 sont tous deux dans le groupe Serveurs par OS/Linux serveurs/Prod . Si l’on souhaite les structurer par localisation, c’est également possible. A cet effet, les deux appareils viennent d'être liés au groupe Serveurs par localisation/Londres . Les deux server Linux situés sous ces deux groupes sont identiques, ils ont les mêmes ID d'objet et contiennent les mêmes tâches de mesure. Par exemple, renommer lx203 serait reflété sous ses deux groupes parents. La suppression de lx203 le supprimerait dans les deux groupes. Cependant, on peut simplement le dissocier au lieu de le supprimer, il restera alors en dessous de l'autre groupe parent.

Il n'y a pas de règles de corrélation sur les objets de périphérique ou de groupe, il est donc normal que chaque tâche qui a un état non OK pousse son état vers le haut de l'arborescence du groupe. Seule l'arborescence Services (voir ci-dessous) utilise des règles de corrélation pour contrôler la manière dont les états sont poussés vers le haut.

Modèle de service

Le sous-groupe Services/SLO contient les principaux objets de service. Ceux-ci représentent l’état du ou des services modélisés. En dessous de ceux-ci, une arborescence de modèles est construite à l'aide d'objets de niveau de service (SLO), qui permettent de spécifier des règles de corrélation pour les SLO enfants.

Après avoir créé ou importé les appareils et créé les tâches de mesure en dessous d'eux, ces tâches peuvent être liées sous le groupe Services . Habituellement, seules les tâches individuelles sont liées aux SLO, mais il est également possible de relier des appareils ou des groupes entiers à des SLO.

Sous le service SLO Business supérieur 1, les fonctions du service sont modélisées. Le modèle doit représenter l'arborescence des dépendances du service métier 1 . Par exemple, la Fonction LDAP , dont dépend ce service, est configurée de telle sorte qu'un seul des deux serveurs LDAP doit être exécuté. Dans cet exemple, l'un des serveurs LDAP n'est pas fonctionnel car son service slapd n'est pas en cours d'exécution. Cependant, le service reste disponible pour le client. Habituellement, dans SKOOR, ce type de configuration se reflète à l'aide d'un SLO avec une règle de corrélation (1 sur 2). La fonction LDAP a l'état mineur ( orange ) si 1 Server LDAP est en panne et majeur ( rouge ) si les deux sont en panne. Le service SLO Business 1 est configuré de sorte que seuls les états majeurs des fonctions ci-dessous soient pris en compte, il reste donc dans l'état OK ( vert ) dans un tel scénario.

L'arborescence du modèle définit comment les états sont poussés du niveau de travail vers la fonction de service et vers l'objet de service supérieur.

Contrôleurs de niveau de service (SLC)

Le sous-groupe Services/SLC contient les objets contrôleur de niveau de service. Les SLC sont généralement liés au SLO supérieur d'un service (par exemple le service Business 1) et mesurent le respect d'un accord de niveau de service (SLA) sur la base d'une période de temps spécifique et d'un objectif de disponibilité (par exemple 99,9 %). Le SLA, un contrat entre un fournisseur d'un service et un consommateur d'un service, établit des objectifs mesurables convenus de performance et/ou de disponibilité.

Alarmant

SKOOR Engine utilise des objets de dispositif d'alarme pour détecter les changements dans les états des objets situés sous l'appareil ou l'arborescence de service et agir en fonction de ces changements (par exemple, envoyer un e-mail à la personne responsable de l'appareil ou du service). Ces dispositifs d'alarme peuvent être regroupés en groupes d'alarmes. Dans le scénario ci-dessus, il existe généralement deux chemins alarmants :

Technique alarmante
Les tâches de mesure situées sous l'un des objets de l'arborescence des appareils détectent des défauts et changent d'état en fonction des limites d'alarme configurées pour chaque tâche. Chacun de ces changements d'état déclenche une alarme sur le travail et sur l'appareil lui-même. Ces alarmes techniques ne peuvent pas entraîner de pannes de service, mais elles sont néanmoins pertinentes pour le personnel technique et doivent être corrigées à long terme. Pour transmettre ces alarmes aux personnes responsables (par e-mail), des dispositifs d'alarme ou des groupes d'alarmes sont attachés aux appareils individuels ou au /root/ /Groupe Appareils.
Service alarmant
Les responsables de service ne s'intéressent généralement pas aux défauts techniques qui n'influencent pas leur service. Cependant, si des mesures situées sous l'arborescence de services sont propagées vers leur objet de service supérieur, elles souhaitent en être immédiatement informées. À cette fin, des dispositifs d'alarme ou des groupes d'alarme distincts sont attachés aux services individuels sous /root/ /Services/SLO. Par exemple, si le Le service slapd sur les deux serveurs LDAP cesse de fonctionner, la fonction LDAP deviendra rouge et par la suite, le service Business 1 deviendra également rouge. L'objet d'alarme ci-joint enverra un e-mail au responsable du service.

Rapports

Les rapports définissent des descriptions de rapports personnalisées qui peuvent être générées manuellement ou par le planificateur de rapports. Habituellement, un seul rapport PDF est configuré pour chaque service. Il peut contenir des historiques d'état ou des informations sur l'exécution des SLC relatives à la période choisie pour le rapport. Le rapport lui-même contient la configuration du contenu. Pour chaque rapport, un ou plusieurs planificateurs de rapports peuvent être attachés qui génèrent régulièrement un fichier de sortie basé sur la configuration du rapport. Les planificateurs de rapports peuvent également envoyer automatiquement le rapport généré à une ou plusieurs adresses e-mail.

Outre le format PDF, d'autres rapports peuvent également être configurés, par exemple des rapports CSV ou XML.

Docs