SKOOR-Objekte strukturieren
Die Ansicht /root enthält nach der Erstinstallation von SKOOR Engine und Dashboards die folgenden Objekte:
Objekt | Funktion |
---|---|
| Vordefinierte Struktur für Kundenkonfigurationen. Dies ist normalerweise der Ort, an dem gearbeitet wird. |
| Eine Gruppe, die alle Dashboard-Objekte enthält (einschließlich ihrer Kacheln und Widgets) |
| Die Standardgruppe, in der SKOOR Engine Geräte, Jobs und Konfigurationselemente ablegt, um sich selbst und seine externen Kollektoren zu überwachen. |
| 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. |
| Ein spezielles Objekt, das alle Alarmgeräte und Alarmgruppen enthält. |
| Ein spezielles Objekt, das alle Konfigurationsobjekte enthält. Standardmäßig enthält es Untergruppen für die folgenden Objekttypen:
Die folgenden Konfigurationselemente sind veraltet, können aber weiterhin auf dem System verfügbar sein:
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. |
| Ein spezielles Objekt, das alle Vorlagenobjekte enthält. |
| Ein spezielles Objekt, das alle Benutzer- und Benutzergruppenobjekte enthält. |
| 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.