La vista /root contiene i seguenti oggetti dopo l'installazione iniziale di SKOOR Engine e Dashboard:

Oggetto	Funzione
`<Customer_Site>`	Struttura predefinita per le configurazioni del cliente. Questo è di solito il luogo in cui lavorare. `<Customer_Site>` è un segnaposto da rinominare con il nome dell'azienda o del progetto.
`Dashboards`	Un gruppo che contiene tutti gli oggetti del dashboard (compresi i relativi tiles e widgets).
`SKOOR system`	Il gruppo predefinito in cui SKOOR Engine inserisce i dispositivi, i lavori e gli elementi di configurazione per monitorare se stesso e i collettori esterni.
`Collectors`	Un oggetto speciale contenente tutti i collettori di SKOOR Engine. Questi raccolgono tutte le misurazioni effettuate dai lavori e le inoltrano al server di SKOOR Engine. Il collettore predefinito si chiama collector-local e funziona sul server SKOOR. I collettori esterni sono utilizzati per raggiungere host in reti diverse. Poiché i collettori sono solo utenti standard con il flag di collettore impostato, vengono creati nel gruppo Utenti. I collettori hanno uno stato: OK (verde) significa che sono connessi e che attualmente forniscono dati di misura al server, Major (rosso) significa che sono disconnessi.
`Alarming`	Un oggetto speciale contenente tutti i dispositivi e i gruppi di allarme.
`Configurations`	Un oggetto speciale contenente tutti gli oggetti di configurazione. Per impostazione predefinita, contiene sottogruppi per i seguenti tipi di oggetti: Mappa filtro Contiene tutti gli oggetti mappa filtro disponibili in SKOOR. Le mappe filtro sono oggetti il cui contenuto è collegato dinamicamente in base a specifiche proprietà. Monitor delle operazioni Contiene tutti gli oggetti Operations monitor disponibili in SKOOR. Il monitor delle operazioni offre una panoramica configurabile sullo stato degli oggetti disponibili nello SKOOR Engine. Elenca gli stati di SLO e SLC, gli oggetti che hanno emesso allarmi attualmente o in passato, le voci syslog dello SKOOR Engine o di altri server e le Manutenzioni programmate. Elemento info Contiene tutti gli oggetti info element disponibili in SKOOR. Gli elementi informativi sono oggetti descrittivi che possono contenere testi formattati, elenchi, immagini bitmap o collegamenti ipertestuali e possono essere collegati a gruppi o dispositivi. Posizione Contiene tutte le ubicazioni disponibili in SKOOR Sono gestite attraverso il menu Admin e rappresentano luoghi geografici (il nome del luogo corrisponde alle coordinate geografiche). Le località possono essere assegnate a molti oggetti come proprietà Grafico Contiene tutti i grafici preconfigurati dello storico degli stati o dei valori disponibili in SKOOR. Possono essere utilizzati nelle mappe, nelle mappe figlio o separatamente. Importazione/esportazione Contiene tutti gli oggetti di esportazione CSV o XML disponibili in SKOOR. Scheduler Contiene tutti gli oggetti di pianificazione disponibili in SKOOR. Vengono utilizzati per definire orari attivi o inattivi per l'esecuzione di lavori, controllori del livello di servizio (SLC), gruppi/dispositivi di allarme o limiti di allarme. Cruscotto Contiene tutti gli oggetti del cruscotto disponibili in SKOOR. Si tratta dei cruscotti stessi, delle loro tessere e dei loro widget. I seguenti oggetti di configurazione sono deprecati, ma possono essere ancora disponibili nel sistema: Mappa Mappa figlio Mappa Geo Elemento mappa Gestione dei servizi aziendali Se, ad esempio, in un altro punto della struttura ad albero di SKOOR Engine viene creato un oggetto di tipo Schedule, questo verrà automaticamente collegato anche al gruppo /root/Configurations/Schedule.
`Templates`	Un oggetto speciale contenente tutti gli oggetti modello.
`Users`	Un oggetto speciale contenente tutti gli oggetti utente e gruppo utente.
`Lost+Found`	Un oggetto speciale contenente tutti gli oggetti che per qualche motivo hanno perso il loro legame con il genitore. Non ci dovrebbero essere oggetti al di sotto di questo oggetto.

Struttura degli oggetti consigliata

Gli oggetti appena creati possono essere raggruppati in vari modi. Possono essere raggruppati per località (città, edificio, piano, filiale dell'azienda) o per qualsiasi cosa si adatti meglio all'organizzazione dell'azienda o del progetto. Grazie alla sua struttura aperta, SKOOR Engine consente di creare facilmente diverse viste, ad esempio per tipo di dispositivo o per responsabilità. La struttura degli oggetti varia a seconda delle aspettative del cliente in materia di monitoraggio. SKOOR Engine può essere utilizzato esclusivamente per il monitoraggio tecnico o principalmente come overlay per il monitoraggio del business e dei servizi IT. La maggior parte delle configurazioni rappresenta una combinazione di monitoraggio dell'infrastruttura e dei servizi. SKOOR consiglia di impostare tali progetti di monitoraggio utilizzando una struttura di oggetti simile a quella riportata di seguito:

/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'esempio precedente mostra come si può creare una struttura di base per il monitoraggio dei servizi.

Inventario dei dispositivi

Il primo passo è di solito quello di creare gli oggetti dei dispositivi al di sotto del gruppo Devices. In questo caso, il gruppo Dispositivi è stato strutturato prima per funzione del dispositivo (Server, Storage ...), poi per sottofunzione o per altri criteri. Ad esempio, i server Linux lx203 e lx204 sono entrambi nel gruppo Servers by OS/Linux servers/Prod. Se si desidera strutturarli in base alla posizione, è possibile farlo. A questo scopo i due dispositivi sono stati collegati al gruppo Servers by location/London. I due dispositivi server Linux sotto questi due gruppi sono identici, hanno gli stessi ID oggetto e contengono gli stessi lavori di misura. Ad esempio, la ridenominazione di lx203 si rifletterà sotto entrambi i gruppi di origine. L'eliminazione di lx203 lo cancellerebbe in entrambi i gruppi. Tuttavia, si può semplicemente scollegare l'oggetto invece di cancellarlo, in questo caso rimarrebbe sotto l'altro gruppo padre.

Non ci sono regole di correlazione per gli oggetti dei dispositivi o dei gruppi, quindi è normale che ogni lavoro che ha uno stato non OK spinga il suo stato in cima all'albero dei gruppi. Solo l'albero dei servizi (vedi sotto) utilizza regole di correlazione per controllare come gli stati vengono spinti verso l'alto.

Modello di servizio

Il sottogruppo Servizi/SLO contiene gli oggetti di servizio più importanti. Questi rappresentano lo stato dei servizi modellati. Al di sotto di questi si costruisce un modello ad albero utilizzando gli oggetti di livello di servizio (SLO), che consentono di specificare le regole di correlazione per i SLO figli.

Dopo aver creato o importato i dispositivi e creato i lavori di misura sottostanti, questi lavori possono essere collegati al gruppo Servizi. Di solito, solo i singoli lavori sono collegati agli SLO, ma si possono collegare anche interi dispositivi o gruppi agli SLO.

Sotto lo SLO Business service 1 vengono modellate le funzioni del servizio. Il modello deve rappresentare l'albero delle dipendenze del servizio Business 1. Ad esempio, la funzione LDAP, da cui dipende questo servizio, è impostata in modo che solo uno dei due server LDAP debba essere in funzione. In questo esempio, uno dei server LDAP non funziona perché il suo servizio slapd non è in esecuzione. Tuttavia, il servizio è ancora disponibile per il cliente. Di solito, in SKOOR questo tipo di configurazione si riflette utilizzando uno SLO con una regola di correlazione (1 di 2). La funzione LDAP ha uno stato minore(arancione) se 1 server LDAP è inattivo e maggiore(rosso) se entrambi sono inattivi. Lo SLO Business service 1 è configurato in modo da considerare solo gli stati maggiori delle funzioni sottostanti, quindi in questo scenario rimane nello stato OK(verde).

L'albero del modello definisce il modo in cui gli stati vengono trasferiti dal livello di lavoro alla funzione di servizio e all'oggetto di servizio superiore.

Controllori del livello di servizio (SLC)

Il sottogruppo Servizi/SLC contiene gli oggetti controllori del livello di servizio. Gli SLC sono solitamente collegati allo SLO superiore di un servizio (ad esempio, il servizio Business 1) e misurano il rispetto di un accordo sul livello di servizio (SLA) basato su un periodo di tempo specifico e su un obiettivo di disponibilità (ad esempio, 99,9%). Lo SLA, un contratto tra un fornitore di servizi e un consumatore di servizi, stabilisce obiettivi misurabili e concordati di prestazioni e/o disponibilità.

Allarmi

SKOOR Engine utilizza oggetti dispositivo di allarme per rilevare i cambiamenti di stato degli oggetti sotto l'albero dei dispositivi o dei servizi e agire in base a tali cambiamenti (ad esempio, inviando un'e-mail alla persona responsabile del dispositivo o del servizio). Questi dispositivi di allarme possono essere combinati in gruppi di allarme. Nello scenario sopra descritto, di solito ci sono due percorsi di allarme:

Allarme tecnico
I lavori di misura che si trovano al di sotto di uno qualsiasi degli oggetti dell'albero dei dispositivi notano dei guasti e cambiano il loro stato in base ai limiti di allarme configurati su ciascun lavoro. Ogni singolo cambiamento di stato genera un allarme sul lavoro e sul dispositivo stesso. Questi allarmi tecnici non possono portare a interruzioni del servizio, ma sono comunque importanti per il personale tecnico e devono essere risolti a lungo termine. Per inoltrare questi allarmi alle persone responsabili (via e-mail), i dispositivi di allarme o i gruppi di allarme sono collegati ai singoli dispositivi o al gruppo /root/<nome cliente o progetto>/Dispositivi.
Allarmi di servizio
I responsabili dell'assistenza di solito non sono interessati a guasti tecnici che non influenzano il loro servizio. Tuttavia, se alcune misure al di sotto dell'albero del servizio vengono propagate al loro oggetto di servizio superiore, vogliono essere avvisati immediatamente. A questo scopo, ai singoli servizi sotto /root/<nome cliente o progetto>/Servizi/SLO vengono collegati dispositivi o gruppi di allarme separati. Ad esempio, se il servizio slapd su entrambi i server LDAP smette di funzionare, la funzione LDAP diventa rossa e successivamente anche il servizio Business 1 diventa rosso. L'oggetto allarme allegato invierà un'e-mail al gestore del servizio.

Rapporti

I rapporti definiscono descrizioni di rapporti personalizzati che possono essere generati manualmente o dal pianificatore di rapporti. Di solito viene configurato un singolo report PDF per ogni servizio. Può contenere lo storico degli stati o le informazioni sull'adempimento SLC relative al periodo di tempo scelto per il report. Il rapporto stesso contiene la configurazione dei contenuti. Per ogni rapporto è possibile collegare uno o più Scheduler che generano regolarmente un file di output in base alla configurazione del rapporto. Gli Scheduler possono anche inviare automaticamente il rapporto generato a uno o più indirizzi e-mail.

Oltre ai PDF, è possibile configurare anche altri report, ad esempio CSV o XML.

Documentazione