Die /root-Ansicht enthält nach der Erstinstallation von SKOOR Engine und Dashboards die folgenden Objekte:

Objekt	Funktion
`<Customer_Site>`	Vordefinierte Struktur für Kundenkonfigurationen. Dies ist in der Regel der Ort, mit dem man arbeitet. `<Customer_Site>` ist ein Platzhalter, der in den Firmen- oder Projektnamen umbenannt werden kann
`Dashboards`	Eine Gruppe, die alle Dashboard-Objekte enthält (einschließlich ihrer Kacheln und Widgets)
`SKOOR system`	Die Standardgruppe, in der SKOOR Engine Geräte, Jobs und Konfigurationselemente ablegt, um sich selbst und seine externen Kollektoren zu überwachen.
`Collectors`	Ein spezielles Objekt, das alle SKOOR Engine Collectors enthält. Diese sammeln alle von den Aufträgen gemachten Messungen und leiten sie an den SKOOR Engine Server weiter. Der Standardkollektor heißt collector-local und läuft auf dem SKOOR Server. Externe Kollektoren werden verwendet, um Hosts in verschiedenen Netzwerken zu erreichen. Da Kollektoren nur Standardbenutzer mit gesetztem Kollektor-Flag sind, werden sie in der Gruppe Benutzer angelegt. Kollektoren haben einen Status: OK (grün) bedeutet, dass sie verbunden sind und derzeit Messdaten an den Server liefern, Major (rot) bedeutet, dass sie nicht verbunden sind.
`Alarming`	Ein spezielles Objekt, das alle Alarmgeräte und Alarmgruppen enthält.
`Configurations`	Ein spezielles Objekt, das alle Konfigurationsobjekte enthält. Standardmäßig enthält es Untergruppen für die folgenden Objekttypen: Filterkarte Enthält alle in SKOOR verfügbaren Filterkartenobjekte. Filterkarten sind Objekte, deren Inhalte dynamisch auf der Grundlage bestimmter Eigenschaften verknüpft werden Operator Monitor Enthält alle in SKOOR verfügbaren Operator-Monitor-Objekte Der Betriebsmonitor bietet konfigurierbare Übersichten über den Zustand der in der SKOOR Engine verfügbaren Objekte Er listet SLO- und SLC-Zustände, Objekte, die aktuell oder in der Vergangenheit Alarme ausgelöst haben, Syslog-Einträge der SKOOR Engine oder anderer Server und geplante Wartungen auf Info-Element Enthält alle in SKOOR verfügbaren Info-Element-Objekte. Info-Elemente sind beschreibende Objekte, die formatierten Text, Listen, Bitmap-Bilder oder Hyperlinks enthalten können und an Gruppen oder Geräte angehängt werden können Standort Enthält alle in SKOOR verfügbaren Standorte. Diese werden über das Admin-Menü verwaltet und stellen geografische Standorte dar (Standortname entspricht den geografischen Koordinaten) Standorte können vielen Objekten als Eigenschaften zugewiesen werden Grafik Enthält alle in SKOOR verfügbaren vorkonfigurierten Zustands- oder Werte-Historiendiagramme Diese können in Karten, Unterkarten oder separat verwendet werden Importieren/Exportieren Enthält alle in SKOOR verfügbaren CSV- oder XML-Exportobjekte Zeitplan Enthält alle in SKOOR verfügbaren Zeitplan-Objekte Diese werden verwendet, um aktive oder inaktive Zeiten für die Jobausführung, Service Level Controller (SLCs), alarmierende Gruppen/Geräte oder Alarm Limits zu definieren Dashboard Enthält alle in SKOOR verfügbaren Dashboard-Objekte. Dies sind die Dashboards selbst, sowie deren Kacheln und Widgets Die folgenden Konfigurationsobjekte sind veraltet, können aber weiterhin im System verfügbar sein: Karte Untergeordnete Karte Weltkarte Kartenelement Business Service Verwaltung Wenn zum Beispiel irgendwo in der Baumstruktur der SKOOR Engine ein Objekt vom Typ Schedule erstellt wird, wird es automatisch auch mit der Gruppe /root/Configurations/Schedule verknüpft.
`Templates`	Ein spezielles Objekt, das alle Vorlagenobjekte enthält.
`Users`	Ein spezielles Objekt, das alle Benutzer- und Benutzergruppenobjekte enthält.
`Lost+Found`	Ein spezielles Objekt, das alle Objekte enthält, die aus irgendeinem Grund ihre übergeordnete Verknüpfung verloren haben. Darunter sollte es keine Objekte geben.

Empfohlene Objektstruktur

Neu erstellte Objekte können auf verschiedene Weise gruppiert werden. Sie können nach Ort (Stadt, Gebäude, Stockwerk, Firmenniederlassung) gruppiert werden oder nach allem, was am besten zur Unternehmens- oder Projektorganisation passt. Dank der offenen Struktur von SKOOR Engine ist es sehr einfach, verschiedene Ansichten zu erstellen, zum Beispiel nach Gerätetyp oder Zuständigkeit. Die Objektstruktur variiert je nach den Erwartungen des Kunden an die Überwachung. SKOOR Engine kann ausschließlich für die technische Überwachung oder hauptsächlich als Overlay für die Überwachung von Geschäfts- und IT-Services verwendet werden. Die meisten Setups stellen eine Kombination aus Infrastruktur- und Service-Überwachung dar. SKOOR empfiehlt, solche Überwachungsprojekte mit einer Objektstruktur ähnlich der folgenden einzurichten:

/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

Das obige Beispiel zeigt, wie man eine Grundstruktur für die Serviceüberwachung erstellen kann.

Geräte-Inventarisierung

Der erste Schritt besteht normalerweise darin, die Geräteobjekte irgendwo unterhalb der Gruppe Geräte anzulegen. Hier wurde die Gruppe Geräte zunächst nach Gerätefunktionen (Server, Storage ...) strukturiert, dann entweder nach Unterfunktionen oder anderen Kriterien. Zum Beispiel sind die Linux Server lx203 und lx204 beide in der Gruppe Server nach Betriebssystem/Linux Server/Prod. Wenn man sie nach Standort strukturieren möchte, ist auch das möglich. Zu diesem Zweck wurden die beiden Geräte einfach mit der Gruppe Server nach Standort/London verknüpft. Die beiden Linux-Server-Geräte unterhalb dieser beiden Gruppen sind identisch, sie haben die gleichen Objekt-IDs und enthalten die gleichen Messaufträge. Eine Umbenennung von lx203 zum Beispiel würde sich unterhalb der beiden übergeordneten Gruppen niederschlagen. Das Löschen von lx203 würde es in beiden Gruppen löschen. Man kann jedoch die Verknüpfung aufheben, anstatt sie zu löschen, dann würde sie unterhalb der anderen übergeordneten Gruppe bleiben.

Es gibt keine Korrelationsregeln für Geräte- oder Gruppenobjekte, so dass es normal ist, dass jeder Job, der einen Nicht-OK-Status hat, seinen Status an die Spitze des Gruppenbaums schiebt. Nur der Baum Dienste (siehe unten) verwendet Korrelationsregeln, um zu steuern, wie Zustände nach oben verschoben werden.

Dienstmodell

Die Untergruppe Dienste/SLOs enthält die obersten Dienstobjekte. Diese stellen den Zustand des/der modellierten Dienstes/Dienste dar. Darunter wird ein Modellbaum mit Service Level Objects (SLOs) aufgebaut, die es ermöglichen, Korrelationsregeln für Child-SLOs festzulegen.

Nach dem Anlegen oder Importieren der Geräte und dem Anlegen der darunter liegenden Messaufträge können diese Aufträge unterhalb der Gruppe Dienste verknüpft werden. Normalerweise werden nur einzelne Jobs mit SLOs verknüpft, man kann aber auch ganze Geräte oder Gruppen mit SLOs verknüpfen.

Unterhalb der obersten SLO Business Service 1 werden die Funktionen des Dienstes modelliert. Das Modell soll den Abhängigkeitsbaum von Business Service 1 abbilden. Zum Beispiel ist die Funktion LDAP, von der dieser Dienst abhängt, so eingerichtet, dass nur einer der beiden LDAP Server laufen muss. In diesem Beispiel ist einer der LDAP-Server nicht funktionsfähig, weil sein slapd-Dienst nicht läuft. Der Dienst ist jedoch weiterhin für den Kunden verfügbar. In SKOOR wird diese Art von Konfiguration normalerweise durch einen SLO mit einer Korrelationsregel (1 von 2) abgebildet. Die LDAP-Funktion hat den Status Minor(orange), wenn ein LDAP Server ausgefallen ist und Major(rot), wenn beide ausgefallen sind. Das SLO Business Service 1 ist so konfiguriert, dass nur Major-Zustände der darunter liegenden Funktionen berücksichtigt werden, so dass es in einem solchen Szenario im Zustand OK(grün) bleibt.

Der Modellbaum definiert, wie die Zustände von der Auftragsebene zur Servicefunktion und zum obersten Serviceobjekt weitergegeben werden.

Dienstebenen-Steuerungen (SLCs)

Die Untergruppe Services/SLCs enthält die Objekte der Service Level Controller. SLCs sind in der Regel mit dem obersten SLO eines Dienstes (z. B. Business Service 1) verknüpft und messen die Erfüllung eines Service Level Agreements (SLA) auf der Grundlage eines bestimmten Zeitraums und eines Verfügbarkeitsziels (z. B. 99,9 %). Das SLA, ein Vertrag zwischen einem Anbieter eines Dienstes und einem Verbraucher eines Dienstes, legt messbare, vereinbarte Ziele für Leistung und/oder Verfügbarkeit fest.

Alarmierung

SKOOR Engine verwendet Alarmvorrichtungsobjekte, um Änderungen der Zustände von Objekten unterhalb des Geräte- oder Servicebaums zu erkennen und darauf zu reagieren (z. B. Senden einer E-Mail an die für das Gerät oder den Service zuständige Person). Diese Alarmgeräte können zu Alarmgruppen zusammengefasst werden. In dem oben beschriebenen Szenario gibt es in der Regel zwei Alarmierungswege:

Technische Alarmierung
Messaufträge unterhalb eines beliebigen Objekts im Gerätebaum stellen Fehler fest und ändern ihren Zustand in Abhängigkeit von den für jeden Auftrag konfigurierten Alarm Limits. Jede dieser Zustandsänderungen löst einen Alarm für den Job und das Gerät selbst aus. Diese technischen Alarme führen zwar nicht zu Betriebsausfällen, sind aber dennoch für das technische Personal relevant und müssen auf Dauer behoben werden. Um diese Alarme an die zuständigen Personen (per E-Mail) weiterzuleiten, werden Alarmgeräte oder Alarmgruppen an die einzelnen Geräte oder die Gruppe /root/<Kunden- oder Projektname>/Geräte angehängt.
Service-Alarmierung
Serviceverantwortliche sind in der Regel nicht an technischen Störungen interessiert, die ihren Service nicht beeinflussen. Wenn jedoch Messungen unterhalb des Servicebaums auf ihr oberstes Serviceobjekt übertragen werden, möchten sie sofort benachrichtigt werden. Zu diesem Zweck werden an die einzelnen Dienste unterhalb von /root/<Kunden- oder Projektname>/Services/SLOs separate Alarmgeräte oder Alarmgruppen angehängt. Wenn zum Beispiel der slapd-Dienst auf beiden LDAP-Servern nicht mehr läuft, wird Function LDAP rot und anschließend auch Business Service 1 rot. Das angehängte Alarmobjekt sendet eine E-Mail an den Dienstmanager.

Berichte

Berichte definieren benutzerdefinierte Berichtsbeschreibungen, die manuell oder mit Hilfe des Berichtsplaners erstellt werden können. Normalerweise wird für jeden Dienst ein einzelner PDF-Bericht konfiguriert. Er kann Status-Historien oder SLC-Erfüllungsinformationen in Bezug auf die für den Bericht gewählte Zeitspanne enthalten. Der Bericht selbst enthält die Konfiguration des Inhalts. Für jeden Report können ein oder mehrere Report Scheduler angehängt werden, die regelmäßig eine Ausgabedatei auf der Grundlage der Reportkonfiguration erzeugen. Die Scheduler können den generierten Bericht auch automatisch an eine oder mehrere E-Mail-Adressen senden.

Neben PDF können auch andere Berichte konfiguriert werden, z.B. CSV- oder XML-Berichte.

Dokumentation