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 normalerweise der Ort, an dem man arbeiten kann. `<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 enthält. Diese sammeln alle von den Jobs durchgeführten Messungen und leiten sie an den SKOOR Engine Server weiter. Der Standard- Kollektor heißt Kollektor -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“ 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 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 basierend auf bestimmten Eigenschaften dynamisch verknüpft werden Betriebsmonitor Enthält alle in SKOOR verfügbaren Operationsmonitorobjekte Der Operationsmonitor 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 der SKOOR Engine oder anderer Server sowie geplante Wartungsarbeiten auf Infoelement Enthält alle in SKOOR verfügbaren Infoelementobjekte. Infoelemente 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 den geografischen Koordinaten). Standorte können vielen Objekten als Eigenschaften zugeordnet werden Graph Enthält alle in SKOOR verfügbaren vorkonfigurierten Zustands- oder Wertverlaufsdiagramme 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 deren Kacheln und Widgets Die folgenden Konfigurationselemente sind veraltet, können aber weiterhin auf dem System verfügbar sein: Karte Kinderkarte Geokarte Kartenelement Unternehmensdienstleistungsmanagement Wenn beispielsweise irgendwo anders in der SKOOR Engine Baumstruktur 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. Hier sollten sich keine Objekte darunter befinden.

Empfohlene Objektstruktur

Neu erstellte Objekte können auf verschiedene Arten gruppiert werden. Sie können nach Standort (Stadt, Gebäude, Stockwerk, Unternehmenszweig) oder nach allem, was am besten zum Unternehmen oder zur Projektorganisation passt, gruppiert werden. Durch die offene Struktur der SKOOR Engine ist es sehr einfach, verschiedene Ansichten, beispielsweise nach Gerätetyp oder Zuständigkeit, zu erstellen. Die Objektstruktur variiert je nach den Erwartungen des Kunden an die Überwachung. SKOOR Engine kann ausschließlich für das technische Monitoring oder hauptsächlich als Overlay für Business- und IT-Service-Monitoring eingesetzt 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äteinventur

Der erste Schritt besteht normalerweise darin, die Geräteobjekte irgendwo unterhalb der Gerätegruppe zu erstellen. Hier wurde die Gerätegruppe 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/Produkt“ . Wenn man sie nach Standorten strukturieren möchte, ist das auch möglich. Zu diesem Zweck wurden die beiden Geräte gerade mit der Gruppe „Server nach Standort/London“ verknüpft. Die beiden Linux- Server unterhalb dieser beiden Gruppen sind identisch, haben dieselben Objekt-IDs und enthalten dieselben Messaufträge. Beispielsweise würde die Umbenennung von lx203 unter beiden übergeordneten Gruppen angezeigt. 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 bleibt sie unter der anderen übergeordneten Gruppe.

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 des Gruppenbaums 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 Status der modellierten Dienste dar. Darunter wird ein Modellbaum mithilfe von Service Level Objects (SLOs) erstellt, der die Festlegung von Korrelationsregeln für untergeordnete SLOs ermöglicht.

Nach dem Erstellen oder Importieren der Geräte und dem Erstellen der darunter liegenden Messaufträge können diese Aufträge unterhalb der Gruppe „Dienste“ verknüpft werden. Normalerweise sind nur einzelne Jobs mit SLOs verknüpft, es können jedoch auch ganze Geräte oder Gruppen mit SLOs verknüpft werden.

Unterhalb des obersten SLO Business Service 1 werden die Funktionen des Services 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 ausgeführt werden muss. In diesem Beispiel ist einer der LDAP-Server nicht funktionsfähig, da sein slapd- Dienst nicht ausgeführt wird. Der Service steht dem Kunden jedoch weiterhin zur Verfügung. Normalerweise wird diese Art der Einrichtung in SKOOR durch ein SLO mit einer Korrelationsregel (1 von 2) widergespiegelt. Die LDAP-Funktion hat den Status „Minor“ ( orange ), wenn ein LDAP- Server ausgefallen ist, und den Status „Major“ ( rot ), wenn beide ausgefallen sind. Der SLO Business-Dienst 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 übertragen werden.

Service Level Controller (SLCs)

Die Untergruppe „Dienste/SLCs“ enthält die Service Level Controller-Objekte. SLCs sind in der Regel mit dem obersten SLO eines Dienstes verknüpft (z. B. Business-Dienst 1) und messen die Erfüllung eines Service Level Agreements (SLA) basierend auf einem bestimmten Zeitraum und einem Verfügbarkeitsziel (z. B. 99,9 %). Das SLA, ein Vertrag zwischen einem Anbieter einer Dienstleistung und einem Verbraucher einer Dienstleistung, legt messbar vereinbarte Leistungs- und/oder Verfügbarkeitsziele fest.

Alarmierend

SKOOR Engine verwendet Alarmgeräteobjekte, um Änderungen im Zustand von Objekten unterhalb des Geräte- oder Dienstbaums zu erkennen und auf diese Änderungen zu reagieren (z. B. Senden einer E-Mail an die Person, die für das Gerät oder den Dienst verantwortlich ist). Diese Alarmgeräte können zu Alarmgruppen zusammengefasst werden. Im obigen Szenario gibt es normalerweise zwei alarmierende Pfade:

Technische Alarmierung
Messjobs unterhalb eines der Objekte in der Gerätebaumstruktur 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 möglicherweise nicht zu Serviceausfällen, sind aber dennoch für das technische Personal relevant und müssen langfristig behoben werden. Um diese Alarme an die Verantwortlichen (per E-Mail) weiterzuleiten, werden Alarmgeräte oder Alarmgruppen an die einzelnen Geräte oder das /root/ angehängt. /Gerätegruppe.
Service alarmierend
Servicemanager haben in der Regel kein Interesse an technischen Störungen, die keinen Einfluss auf ihren Service haben. Wenn jedoch Messungen unterhalb des Servicebaums an ihr oberstes Serviceobjekt weitergegeben werden, möchten sie sofort benachrichtigt werden. Zu diesem Zweck werden den einzelnen Diensten unterhalb von /root/ separate Alarmgeräte bzw. Alarmgruppen zugeordnet. /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 Business-Dienst 1 rot. Das angehängte Alarmobjekt sendet eine E-Mail an den Servicemanager.

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. Für jeden Bericht können ein oder mehrere Berichtsplaner angehängt 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 Berichte konfiguriert werden, z. B. CSV- oder XML-Berichte.

Docs