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 des clients. C'est généralement l'endroit avec lequel il faut travailler. `<Customer_Site>` est un espace réservé à renommer au nom de l'entreprise ou du projet.
`Dashboards`	Un groupe contenant tous les objets du tableau de bord (y compris les tuiles et les widgets).
`SKOOR system`	Le groupe par défaut où SKOOR Engine place les appareils, les jobs et les éléments de configuration pour se surveiller lui-même et ses collecteurs externes.
`Collectors`	Un objet spécial contenant tous les collecteurs de SKOOR Engine. Ceux-ci collectent toutes les mesures effectuées par les jobs et les transmettent au serveur de SKOOR Engine. Le collecteur par défaut est appelé collecteur-local et s'exécute sur le serveur SKOOR. Les collecteurs externes sont utilisés pour atteindre des hôtes situés dans des réseaux différents. Comme les collecteurs sont des utilisateurs standard avec l'indicateur de collecteur activé, ils sont créés dans le groupe Utilisateurs. Les collecteurs ont un état : OK (vert) signifie qu'ils sont connectés et fournissent actuellement des données de mesure au serveur, Major (rouge) signifie qu'ils sont déconnectés.
`Alarming`	Un objet spécial contenant tous les dispositifs d'alarme et les groupes d'alarme.
`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 : 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 sur la base de propriétés spécifiques. Moniteur d'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 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 de SKOOR Engine ou d'un autre serveur 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 liens hypertextes et qui peuvent être attachés à des groupes ou à des appareils. Emplacement Contient tous les emplacements disponibles dans SKOOR Ils sont gérés par le menu Admin et représentent des emplacements géographiques (le nom de l'emplacement correspond aux coordonnées géographiques). Les emplacements peuvent être assignés à de nombreux objets en tant que propriétés Graphique Contient tous les graphiques préconfigurés de l'état ou de l'historique des valeurs disponibles dans SKOOR. Ils peuvent être utilisés dans des cartes, des cartes enfants ou séparément. Importation / exportation Contient tous les objets d'exportation CSV ou XML disponibles dans SKOOR Scheduler Contient tous les objets de planification disponibles dans SKOOR. Ceux-ci 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. Il s'agit des tableaux de bord eux-mêmes, ainsi que de leurs tuiles et widgets. Les éléments de configuration suivants sont obsolètes mais peuvent toujours être disponibles sur le système : Carte Carte enfant Plan géographique Élément de carte Gestion des services d'entreprise Si, par exemple, un objet de type Schedule est créé ailleurs dans l'arborescence de SKOOR Engine, il sera automatiquement lié 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 utilisateurs et groupes d'utilisateurs.
`Lost+Found`	Un objet spécial contenant tous les objets qui, pour une raison ou une autre, ont perdu leur lien parent. Il ne doit pas y avoir d'objets en dessous.

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 emplacement (ville, bâtiment, étage, succursale de l'entreprise) ou par tout ce qui correspond le mieux à l'organisation de l'entreprise ou du projet. Grâce à sa structure ouverte, SKOOR Engine permet de créer très facilement différentes vues, par exemple par type d'appareil ou par responsabilité. La structure de l'objet variera en fonction des attentes du client en matière de surveillance. SKOOR Engine peut être utilisé pour la surveillance technique exclusivement ou principalement en tant que 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 mettre en place de tels projets de supervision en utilisant une structure d'objets similaire à ce qui suit :

/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 de périphérique quelque part sous le groupe Périphériques. Ici, le groupe Appareils a été structuré d'abord par fonction (Serveurs, Stockage...), puis par sous-fonction ou selon 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, c'est également possible. À cette fin, les deux dispositifs ont simplement été liés au groupe Serveurs par emplacement/Londres. Les deux serveurs Linux situés sous ces deux groupes sont identiques, ils ont les mêmes ID d'objet et contiennent les mêmes travaux de mesure. Par exemple, renommer lx203 se refléterait sous ses deux groupes parents. La suppression de lx203 l'effacera dans les deux groupes. Toutefois, il est possible de le dissocier au lieu de le supprimer, et il restera alors sous l'autre groupe parent.

Il n'y a pas de règles de corrélation sur les périphériques ou les objets de groupe, il est donc normal que chaque travail qui a un état non-OK pousse son état vers le haut de l'arborescence des groupes. Seule l'arborescence des services (voir ci-dessous) utilise des règles de corrélation pour contrôler la façon 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 (des) service(s) modélisé(s). En dessous, une arborescence de modèle 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 travaux de mesure en dessous d'eux, ces travaux peuvent être liés au groupe Services. En général, seuls les travaux individuels sont liés aux SLO, mais il est également possible de lier des appareils ou des groupes entiers à des SLO.

Les fonctions du service sont modélisées sous le SLO Business service 1. Le modèle doit représenter l'arbre de dépendance du service commercial 1. Par exemple, la fonction LDAP, dont dépend ce service, est configurée de manière à ce qu'un seul des deux serveurs LDAP doive fonctionner. Dans cet exemple, l'un des serveurs LDAP n'est pas fonctionnel car son service slapd ne fonctionne pas. Cependant, le service est toujours disponible pour le client. Habituellement, dans SKOOR, ce type de configuration est reflété en utilisant un SLO avec une règle de corrélation (1 sur 2). La fonction LDAP a l'état Minor(orange), si 1 serveur LDAP est en panne et Major(rouge) si les deux sont en panne. Le SLO Business service 1 est configuré de manière à ce que seuls les états Major des fonctions ci-dessous soient pris en compte, il reste donc dans l'état OK(vert) dans un tel scénario.

L'arbre du modèle définit la manière dont les états sont transmis 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/SLCs 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 Business service 1) et mesurent le respect d'un accord de niveau de service (SLA) basé sur une période de temps spécifique et un objectif de disponibilité (par exemple 99,9 %). L'accord de niveau de service, un contrat entre un fournisseur de service et un consommateur de service, établit des objectifs mesurables et convenus de performance et/ou de disponibilité.

Alarme

SKOOR Engine utilise des objets de dispositifs 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 en envoyant un courrier électronique à 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 voies d'alarme :

Alarme technique
Les travaux de mesure situés sous l'un des objets de l'arborescence des appareils détectent des défauts et modifient leur état en fonction des limites d'alarme configurées pour chaque travail. Chacun de ces changements d'état déclenche une alarme sur la tâche et sur l'appareil lui-même. Ces alarmes techniques peuvent ne pas conduire à des interruptions 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 courrier électronique), des dispositifs d'alarme ou des groupes d'alarme sont attachés aux appareils individuels ou au groupe /root/<nom du client ou du projet>/appareils.
Alarme de service
Les gestionnaires de services ne s'intéressent généralement pas aux défauts techniques qui n'influencent pas leur service. Toutefois, si des mesures situées en dessous de l'arborescence du service sont propagées vers l'objet de service supérieur, ils souhaitent en être informés immédiatement. À cette fin, des dispositifs d'alarme ou des groupes d'alarme distincts sont attachés aux services individuels situés sous /root/<Nom du client ou du projet>/Services/SLO. Par exemple, si le service slapd des deux serveurs LDAP cesse de fonctionner, Function LDAP devient rouge et, par la suite, le service Business 1 devient également rouge. L'objet d'alarme joint enverra un courrier électronique au gestionnaire de service.

Rapports

Les rapports définissent des descriptions de rapports personnalisés qui peuvent être générés manuellement ou par le planificateur de rapports. En général, un seul rapport PDF est configuré pour chaque service. Il peut contenir des historiques d'état ou des informations sur l'accomplissement du CSL 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 rapport peuvent être attachés qui génèrent régulièrement un fichier de sortie basé sur la configuration du rapport. Les Scheduler peuvent également envoyer automatiquement le rapport généré à une ou plusieurs adresses électroniques.

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

Documentation