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, an dem Sie arbeiten. „`<Customer_Site>`” ist ein Platzhalter, der in den Namen des Unternehmens oder Projekts umbenannt werden kann.
`Dashboards`	Eine Gruppe, die alle Dashboard-Objekte (einschließlich ihrer Kacheln und Widgets) enthält.
`SKOOR system`	Die Standardgruppe, in der SKOOR Engine Geräte, Jobs und Konfigurationselemente zur Überwachung seiner selbst und seiner externen Kollektoren ablegt.
`Collectors`	Ein spezielles Objekt, das alle SKOOR Engine-Kollektoren enthält. Diese sammeln alle von den Jobs durchgeführten 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 Benutzergruppe erstellt. Kollektoren haben einen Status: „OK” (grün) bedeutet, dass sie verbunden sind und derzeit Messdaten an den Server liefern, „Major” (rot) bedeutet, dass sie getrennt 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: Filterzuordnung Enthält alle in SKOOR verfügbaren Filterzuordnungsobjekte. Filterzuordnungen sind Objekte, deren Inhalte basierend auf bestimmten Eigenschaften dynamisch verknüpft sind. Operationsmonitor Enthält alle in SKOOR verfügbaren Operationsmonitor-Objekte. Der Operationsmonitor bietet konfigurierbare Übersichten über den Status 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 sowie geplante Wartungsarbeiten 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. Diagramm Enthält alle in SKOOR verfügbaren vorkonfigurierten Zustands- oder Wertverlaufsdiagramme Diese können in Karten, Unterkarten oder separat verwendet werden Import/Export Enthält alle in SKOOR verfügbaren CSV- oder XML-Exportobjekte Zeitplan Enthält alle in SKOOR verfügbaren Zeitplanobjekte Diese werden verwendet, um aktive oder inaktive Zeiten für die Ausführung von Jobs, Service Level Controller (SLCs), Alarmgruppen/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 Konfigurationselemente sind veraltet, können aber weiterhin im System verfügbar sein: Karte Untergeordnete Karte Geokarte Kartenelement Business Service Management Wenn beispielsweise an anderer Stelle in der Baumstruktur der SKOOR Engine ein Objekt vom Typ „Zeitplan” 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. Unterhalb dieses Objekts sollten sich keine weiteren Objekte befinden.

Empfohlene Objektstruktur

Neu erstellte Objekte können auf verschiedene Weise gruppiert werden. Sie können nach Standort (Stadt, Gebäude, Etage, Unternehmenszweig) oder nach anderen Kriterien gruppiert werden, die am besten zur Unternehmens- oder Projektorganisation passen. Dank seiner offenen Struktur macht es SKOOR Engine sehr einfach, verschiedene Ansichten zu erstellen, beispielsweise nach Gerätetyp oder Zuständigkeit. Die Objektstruktur variiert je nach den Erwartungen des Kunden hinsichtlich der Überwachung. SKOOR Engine kann ausschließlich für die technische Überwachung oder hauptsächlich als Overlay für die Geschäfts- und IT-Serviceüberwachung 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 Dienstüberwachung erstellen kann.

Geräteinventar

Der erste Schritt besteht in der Regel darin, die Geräteobjekte irgendwo unterhalb der Gruppe „Geräte” zu erstellen. Hier wurde die Gruppe „Geräte” zunächst nach Gerätefunktion (Server, Speicher ...) und dann entweder nach Unterfunktion oder anderen Kriterien strukturiert. Beispielsweise befinden sich 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 das ebenfalls möglich. Zu diesem Zweck wurden die beiden Geräte gerade mit der Gruppe „Server nach Standort/London“ verknüpft. Die beiden Linux-Servergeräte unterhalb dieser beiden Gruppen sind identisch, sie haben die gleichen Objekt-IDs und enthalten die gleichen Messaufträge. Eine Umbenennung von lx203 würde sich beispielsweise unterhalb beider übergeordneten Gruppen widerspiegeln. Das Löschen von lx203 würde es in beiden Gruppen löschen. Man kann es jedoch auch einfach entkoppeln, anstatt es zu löschen, dann würde es unter der anderen übergeordneten Gruppe verbleiben.

Es gibt keine Korrelationsregeln für Geräte- oder Gruppenobjekte, daher ist es normal, dass jeder Job, der einen nicht OK-Status hat, seinen Status an den Anfang der Gruppenstruktur verschiebt. Nur die Struktur „Services“ (siehe unten) verwendet Korrelationsregeln, um zu steuern, wie Status nach oben verschoben werden.

Dienstmodell

Die Untergruppe „Services/SLOs” enthält die obersten Serviceobjekte. Diese repräsentieren den Status der modellierten Dienste. Darunter wird ein Modellbaum mit Service Level Objects (SLOs) aufgebaut, die die Festlegung von Korrelationsregeln für untergeordnete SLOs ermöglichen.

Nach dem Erstellen oder Importieren der Geräte und dem Erstellen der darunter liegenden Messaufträge können diese Aufträge unterhalb der Gruppe „Services“ verknüpft werden. In der Regel werden nur einzelne Aufträge mit SLOs verknüpft, es ist jedoch auch möglich, ganze Geräte oder Gruppen mit SLOs zu verknüpfen.

Unterhalb des obersten SLO Business Service 1 werden die Funktionen des Dienstes modelliert. Das Modell sollte den Abhängigkeitsbaum von Business Service 1 darstellen. Beispielsweise 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, da sein slapd-Dienst nicht läuft. Der Dienst ist jedoch für den Kunden weiterhin verfügbar. In SKOOR wird diese Art von Konfiguration in der Regel durch ein SLO mit einer Korrelationsregel (1 von 2) abgebildet. Die LDAP-Funktion hat den Status „Minor” (orange), wenn 1 LDAP-Server ausgefallen ist, und „Major” (rot), wenn beide ausgefallen sind. Der SLO Business Service 1 ist so konfiguriert, dass nur die Status „Major” der darunter liegenden Funktionen berücksichtigt werden, sodass er in einem solchen Szenario im Status „OK” (grün) bleibt.

Der Modellbaum definiert, wie die Zustände von der Jobebene zur Servicefunktion und zum obersten Serviceobjekt übertragen werden.

Service Level Controller (SLCs)

Die Untergruppe Services/SLCs enthält die Service Level Controller-Objekte. SLCs sind in der Regel mit dem obersten SLO eines Services (z. B. Business Service 1) verknüpft und messen die Erfüllung einer Service Level Agreement (SLA) auf der Grundlage eines bestimmten Zeitraums und eines Verfügbarkeitsziels (z. B. 99,9 %). Die SLA, ein Vertrag zwischen einem Dienstanbieter und einem Dienstnutzer, legt messbare, vereinbarte Leistungs- und/oder Verfügbarkeitsziele fest.

Alarmierung

Die SKOOR Engine verwendet Alarmgeräteobjekte, um Änderungen im Status von Objekten unterhalb des Geräte- oder Dienstbaums zu erkennen und auf diese Änderungen zu reagieren (z. B. durch Senden einer E-Mail an die für das Gerät oder den Dienst verantwortliche Person). Diese Alarmgeräte können zu Alarmgruppen zusammengefasst werden. Im oben genannten Szenario gibt es in der Regel zwei Alarmpfade:

Technische Alarmierung
Messaufträge unterhalb eines beliebigen Objekts im Gerätebaum erkennen Fehler und ändern ihren Status in Abhängigkeit von den für jeden Auftrag konfigurierten Alarm Limits. Jede dieser Statusänderungen löst einen Alarm für den Auftrag und das Gerät selbst aus. Diese technischen Alarme führen zwar nicht zu Dienstausfällen, sind aber dennoch für das technische Personal relevant und müssen langfristig behoben werden. Um diese Alarme an die zuständigen Personen weiterzuleiten (per E-Mail), werden Alarmgeräte oder Alarmgruppen an die einzelnen Geräte oder die Gruppe /root/<Kunden- oder Projektname>/Devices angehängt.
Dienstalarmierung
Dienstmanager sind in der Regel nicht an technischen Fehlern interessiert, die keinen Einfluss auf ihren Dienst haben. Wenn jedoch Messungen unterhalb des Dienstbaums an ihr oberstes Dienstobjekt weitergeleitet werden, möchten sie sofort benachrichtigt werden. Zu diesem Zweck werden separate Alarmgeräte oder Alarmgruppen an die einzelnen Dienste unter /root/<KUNDEN- oder Projektname>/Services/SLOs angehängt. Wenn beispielsweise der slapd-Dienst auf beiden LDAP-Servern nicht mehr ausgeführt wird, wird die Funktion LDAP rot und anschließend auch der Business-Dienst 1 rot. Das angehängte Alarmobjekt sendet eine E-Mail an den Servicemanager.

Berichte

Berichte definieren benutzerdefinierte Berichtsbeschreibungen, die manuell oder durch den Scheduler generiert werden können. In der Regel wird für jeden Dienst ein einzelner PDF-Bericht konfiguriert. Dieser kann Statusverläufe oder SLC-Erfüllungsinformationen in Bezug auf den für den Bericht gewählten Zeitraum enthalten. Der Bericht selbst enthält die Konfiguration der Inhalte. Für jeden Bericht können ein oder mehrere Scheduler angehängt werden, die regelmäßig eine Ausgabedatei basierend auf der Berichtskonfiguration generieren. Die Scheduler können den generierten Bericht auch automatisch an eine oder mehrere E-Mail-Adressen senden.

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

Dokumentation