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 où travailler. `<Customer_Site>` est un espace réservé à renommer avec le nom de l'entreprise ou du projet.
`Dashboards`	Groupe contenant tous les objets du tableau de bord (y compris leurs vignettes et widgets).
`SKOOR system`	Groupe par défaut dans lequel SKOOR Engine place les appareils, les tâches et les éléments de configuration afin de se surveiller lui-même et ses collecteurs externes.
`Collectors`	Objet spécial contenant tous les collecteurs SKOOR Engine. Ceux-ci collectent toutes les mesures effectuées par les tâches et les transmettent au serveur SKOOR Engine. Le collecteur par défaut s'appelle collector-local et fonctionne sur le serveur SKOOR. Les collecteurs externes sont utilisés pour atteindre des hôtes dans différents réseaux. Comme les collecteurs sont simplement des utilisateurs standard avec le drapeau collecteur activé, ils sont créés dans le groupe Utilisateurs. Les collecteurs ont un état : OK (vert) signifie qu'ils sont connectés et transmettent actuellement des données de mesure au server, Major (rouge) signifie qu'ils sont déconnectés.
`Alarming`	Objet spécial contenant tous les dispositifs d'alarme et tous les groupes d'alarme.
`Configurations`	Objet spécial contenant tous les objets de configuration. Par défaut, il contient des sous-groupes pour les types d'objets suivants : Carte de filtrage Contient tous les objets de carte de filtrage disponibles dans SKOOR. Les cartes de filtrage sont des objets dont le contenu est lié dynamiquement en fonction de propriétés spécifiques. Moniteur d'opérations Contient tous les objets moniteur d'opérations disponibles dans SKOOR Le moniteur d'opérations offre des aperçus configurables de 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 serveurs et les maintenances planifiées. Élément d'information Contient tous les objets d'élément 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 associés à des groupes ou à des appareils Emplacement Contient tous les emplacements disponibles dans SKOOR. Ils sont gérés via le menu Admin et représentent des emplacements géographiques (nom de l'emplacement correspondant aux coordonnées géographiques). Les emplacements peuvent être attribués à de nombreux objets en tant que propriétés. Graph Contient tous les graphiques d'historique d'état ou de valeur préconfigurés disponibles dans SKOOR Ils peuvent être utilisés dans des cartes, des sous-cartes ou séparément Importation/exportation Contient tous les objets d'exportation CSV ou XML disponibles dans SKOOR Calendrier Contient tous les objets de planification disponibles dans SKOOR Ils sont utilisés pour définir les périodes actives ou inactives pour l'exécution des tâches, les contrôleurs de niveau de service (SLC), les groupes/appareils d'alarme ou les limites d'alarme. Tableau de bord Contient tous les objets de tableau de bord disponibles dans SKOOR Dashboard. Il s'agit des tableaux de bord eux-mêmes, ainsi que de leurs vignettes et widgets Les éléments de configuration suivants sont obsolètes mais peuvent encore être disponibles sur le système : Carte Carte enfant Carte géographique Élément de carte Gestion des services métier Si, par exemple, un objet de type Schedule est créé ailleurs dans l'arborescence SKOOR Engine, il sera automatiquement lié au groupe /root/Configurations/Schedule.
`Templates`	Objet spécial contenant tous les objets modèles.
`Users`	Objet spécial contenant tous les objets utilisateur et groupe d'utilisateurs.
`Lost+Found`	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.

Structure d'objets recommandée

Les objets nouvellement créés peuvent être regroupés de différentes manières. Ils peuvent être regroupés par emplacement (ville, bâtiment, étage, succursale de l'entreprise) ou par tout autre critère correspondant le mieux à l'organisation de l'entreprise ou du projet. Grâce à sa structure ouverte, SKOOR Engine facilite la création de différentes vues, par exemple par type d'appareil ou par responsabilité. La structure des objets varie en fonction des attentes du client en matière de surveillance. SKOOR Engine peut être utilisé exclusivement pour la surveillance technique ou principalement comme superposition pour la surveillance des services commerciaux et informatiques. La plupart des configurations représentent une combinaison de surveillance de l'infrastructure et des services. SKOOR recommande de configurer ces projets de surveillance à l'aide d'une structure d'objets similaire à celle ci-dessous :

/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 appareils quelque part sous le groupe Appareils. Ici, le groupe Appareils a d'abord été structuré par fonction des appareils (serveurs, stockage, etc.), puis par sous-fonction ou d'autres critères. Par exemple, les serveurs Linux lx203 et lx204 se trouvent tous deux dans le groupe Serveurs par OS/Serveurs Linux/Prod. Si l'on souhaite les structurer par emplacement, cela est également possible. À cette fin, les deux appareils ont simplement été liés au groupe Serveurs par emplacement/Londres. Les deux appareils serveurs 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, le renommage de lx203 serait répercuté sous ses deux groupes parents. La suppression de lx203 le supprimerait dans les deux groupes. Cependant, il est possible de le dissocier au lieu de le supprimer, il resterait alors sous l'autre groupe parent.

Il n'existe aucune règle de corrélation sur les objets de périphérique ou de groupe, il est donc normal que chaque tâche dont l'état n'est pas OK remonte 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 remontés vers le haut.

Modèle de service

Le sous-groupe Services/SLO contient les objets de service supérieurs. Ceux-ci représentent l'état du ou des services modélisés. En dessous, 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, ces tâches peuvent être liées sous le groupe Services. En général, seules les tâches individuelles sont liées aux SLO, mais il est également possible de lier des appareils ou des groupes entiers aux SLO.

Sous le SLO supérieur Service métier 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 manière à ce qu'un seul des deux servers LDAP doive être en fonctionnement. Dans cet exemple, l'un des servers LDAP n'est pas fonctionnel car son service slapd ne fonctionne pas. Cependant, le service reste disponible pour le client. En général, dans SKOOR, ce type de configuration est reflété à 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 serveur LDAP est en panne et majeur (rouge) si les deux sont en panne. Le SLO Business service 1 est configuré de manière à ne prendre en compte que les états majeurs des fonctions ci-dessous, il reste donc dans l'état OK (vert) dans un tel scénario.

L'arborescence du modèle définit la manière dont les états sont transférés du niveau du travail à la fonction de service et à l'objet de service supérieur.

Contrôleurs de niveau de service (SLC)

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

Alarme

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

Alarme technique Les
tâches de mesure situées sous l'un des objets de l'arborescence des dispositifs détectent les défauts et modifient leur état en fonction des limites d'alarme configurées pour chaque tâche. Chacun de ces changements d'état déclenche une alarme sur la tâche et le dispositif lui-même. Ces alarmes techniques peuvent ne pas entraîner d'interruption 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'alarme sont associés aux appareils individuels ou au groupe /root/<Nom du client ou du projet>/Devices.
Alarmes de service
Les responsables de service ne s'intéressent généralement pas aux défaillances techniques qui n'ont pas d'incidence sur leur service. Cependant, si des mesures situées sous l'arborescence de services sont propagées à leur objet de service supérieur, ils souhaitent en être immédiatement informés. À cette fin, des dispositifs d'alarme ou des groupes d'alarme distincts sont associés aux services individuels sous /root/<NOM du client ou du projet>/Services/SLO. Par exemple, si le service slapd sur les deux serveurs LDAP cesse de fonctionner, la fonction LDAP devient rouge, puis le service métier 1 devient également rouge. L'objet d'alarme associé envoie 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 Scheduler. En général, un seul rapport PDF est configuré pour chaque service. Il peut contenir l'historique des états ou des informations sur la conformité 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 schedulers de rapports peuvent être associés afin de générer régulièrement un fichier de sortie basé sur la configuration du rapport. Les schedulers de rapports peuvent également envoyer automatiquement le rapport généré à une ou plusieurs adresses e-mail.

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

Documentation