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

Objekt	Funktion
`<Customer_Site>`	Vordefinierte Struktur für Kundenkonfigurationen. Dies ist normalerweise der Ort, an dem gearbeitet wird. `<Customer_Site>` ist ein Platzhalter zum Umbenennen in den Firmen- oder Projektnamen
`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 besonderes Objekt, das alle SKOOR Engine Kollektoren . Diese sammeln alle Messwerte der Jobs und leiten sie an den SKOOR Engine Server weiter. Der Standard Kollektor heißt Kollektor 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 angelegt. Kollektoren haben einen Status: ok (grün) bedeutet, dass sie verbunden sind und aktuell 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: Karte filtern Enthält alle in SKOOR verfügbaren Filterkartenobjekte. Filterkarten sind Objekte, deren Inhalte anhand bestimmter Eigenschaften dynamisch verknüpft werden Betriebsmonitor Enthält alle in SKOOR verfügbaren Betriebsmonitorobjekte Der Betriebsmonitor bietet konfigurierbare Übersichten über den Zustand der in der SKOOR Engine verfügbaren Objekte Es listet SLO- und SLC-Zustände, Objekte, die aktuell oder in der Vergangenheit Alarme ausgegeben haben, Syslog-Einträge von SKOOR Engine oder anderen Server und geplante Wartungsarbeiten auf Info-Element Enthält alle in SKOOR verfügbaren Infoelement-Objekte. Info-Elemente sind beschreibende Objekte, die formatierten Text, Listen, Bitmap-Bilder oder Hyperlinks enthalten 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 geografischen Koordinaten). Vielen Objekten können Standorte als Eigenschaften zugewiesen werden Graph Enthält alle vorkonfigurierten Zustands- oder Wertverlaufsdiagramme, die in SKOOR verfügbar sind Diese können in Karten, untergeordneten Karten 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 Jobausführung, Service Level Controller (SLCs), alarmierende Gruppen/Geräte oder Alarmgrenzen zu definieren Armaturenbrett Enthält alle in SKOOR verfügbaren Dashboard-Objekte. Dies sind die Dashboards selbst sowie ihre Kacheln und Widgets Die folgenden Konfigurationselemente sind veraltet, können aber weiterhin auf dem System verfügbar sein: Karte Kinderkarte Geo-Karte Kartenelement Management von Unternehmensdienstleistungen Wenn zum Beispiel an anderer Stelle in der Baumstruktur der SKOOR Engine ein Objekt vom Typ Zeitplan erstellt wird, wird es automatisch auch mit der /root/Configurations/Schedule Group 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 sollten sich keine Objekte befinden.

Empfohlene Objektstruktur

Neu erstellte Objekte können auf verschiedene Weise gruppiert werden. Sie können nach Standort gruppiert werden (Stadt, Gebäude, Etage, Unternehmenszweig) oder nach allem, was am besten zum Unternehmen oder zur Projektorganisation passt. Dank ihrer offenen Struktur lassen sich mit SKOOR Engine ganz einfach verschiedene Ansichten erstellen, beispielsweise nach Gerätetyp oder Zuständigkeit. Die Objektstruktur variiert abhängig von den Kundenerwartungen bezüglich der Ü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 Dienstüberwachung dar. SKOOR empfiehlt, solche Überwachungsprojekte mit einer Objektstruktur einzurichten, die der folgenden ähnelt:

/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ätebestand

Der erste Schritt besteht normalerweise darin, die Geräteobjekte irgendwo unterhalb der Gerätegruppe zu erstellen. Hier wurde die Gerätegruppe zuerst nach Gerätefunktion (Server, Speicher ...) strukturiert, dann entweder nach Unterfunktion oder anderen Kriterien. Beispielsweise befinden sich die Linux-Server lx203 und lx204 beide in der Gruppe Server nach Betriebssystem/Linux-Server/Prod . Wenn man sie nach Orten strukturiert haben möchte, ist das auch möglich. Dazu wurden die beiden Geräte gerade mit der Gruppe Servers by location/London verknüpft. Die beiden Linux- Server -Geräte unterhalb dieser beiden Gruppen sind identisch, sie haben dieselben Objekt-IDs und enthalten dieselben Messaufträge. Beispielsweise würde die Umbenennung von lx203 unter seinen beiden übergeordneten Gruppen widergespiegelt. Das Löschen von lx203 würde es in beiden Gruppen löschen. Allerdings kann man die Verknüpfung auch einfach aufheben, anstatt sie zu löschen, dann würde sie unter der anderen übergeordneten Gruppe bleiben.

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 die Spitze der Gruppenstruktur verschiebt. Nur der Dienstebaum (siehe unten) verwendet Korrelationsregeln, um zu steuern, wie Zustände nach oben verschoben werden.

Servicemodell

Die Untergruppe Dienste/SLOs enthält die wichtigsten Dienstobjekte. Diese stellen den Zustand des/der modellierten Dienste(s) dar. Darunter wird ein Modellbaum unter Verwendung von Service Level Objects (SLOs) erstellt, die es ermöglichen, Korrelationsregeln für untergeordnete SLOs anzugeben.

Nachdem Sie die Geräte erstellt oder importiert und die darunter liegenden Messjobs erstellt haben, können diese Jobs unter der Gruppe Dienste verknüpft werden. Üblicherweise werden nur einzelne Jobs mit SLOs verknüpft, man kann aber auch ganze Geräte oder Gruppen mit SLOs verknüpfen.

Unterhalb des obersten SLO -Business-Dienstes 1 sind 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 funktioniert einer der LDAP-Server nicht, weil sein slapd -Dienst nicht läuft. Der Service steht dem Kunden jedoch weiterhin zur Verfügung. Normalerweise wird diese Art von Setup in SKOOR durch ein SLO mit einer Korrelationsregel (1 von 2) widergespiegelt. Die LDAP-Funktion hat den Status Minor ( orange ), wenn 1 LDAP- Server ausgefallen ist, und Major ( rot ), wenn beide ausgefallen sind. Der SLO -Geschäftsdienst 1 ist so konfiguriert, dass nur die Hauptzustände der folgenden Funktionen berücksichtigt werden, sodass er in einem solchen Szenario im Zustand OK ( grün ) bleibt.

Der Modellbaum definiert, wie die Zustände von der Jobebene zur Servicefunktion und zum obersten Serviceobjekt gepusht 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 Dienstes verknüpft (z. B. Business Service 1) und messen die Erfüllung eines Service Level Agreements (SLA) anhand 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 Leistungs- und/oder Verfügbarkeitsziele fest.

Alarmierend

SKOOR Engine verwendet Alarmgeräteobjekte, um Zustandsänderungen von Objekten unterhalb des Geräte- oder Dienstbaums zu erkennen und auf diese Änderungen zu reagieren (z. B. 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 obigen Szenario gibt es normalerweise zwei alarmierende Wege:

Technisch alarmierend
Messjobs unterhalb eines beliebigen Objekts im Gerätebaum bemerken Fehler und ändern ihren Status abhängig von den für jeden Job konfigurierten Alarmgrenzen. Jede einzelne 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 Serviceausfällen, sind aber dennoch für das technische Personal relevant und müssen langfristig 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 das /root/ /Gerätegruppe.
Dienst alarmierend
Servicemanager interessieren sich in der Regel nicht für technische Störungen, die ihren Service nicht beeinflussen. Wenn jedoch Messungen unterhalb des Servicebaums an ihr oberstes Serviceobjekt weitergegeben werden, möchten sie sofort benachrichtigt werden. Dazu werden den einzelnen Diensten unter /root/ eigene Alarmgeräte bzw. Alarmgruppen angehängt. /Dienste/SLOs. Wenn zum Beispiel die Der slapd -Dienst auf beiden LDAP-Servern wird nicht mehr ausgeführt, die Funktion LDAP wird rot und anschließend wird auch der Geschäftsdienst 1 rot. Das angehängte Alarmobjekt sendet eine E-Mail an den Dienstmanager.

Berichte

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

Neben PDF können auch andere Reports konfiguriert werden, zB CSV- oder XML-Reports.

Docs