Status- und Zustandsüberwachung

Monitoring

Unabhängig von den integrierten Health Checks kann ein Administrator die Überwachungsdaten jederzeit konsultieren, um den Gesamtstatus des Systems oder den Zustand einer bestimmten Komponente oder eines bestimmten Service zu überprüfen. Dies geschieht über die Grafana-Schnittstelle, indem die systemweiten Metrikdaten abgefragt werden, die in Prometheus gespeichert sind.

Grafana bietet einen visuellen Ansatz für die Überwachung: Sie können Dashboards erstellen, die aus einer Reihe von Visualisierungsbereichen bestehen. Jeder Bereich entspricht einer einzelnen Metrikabfrage oder einer Kombination von Metrikabfragen, die im ausgewählten Format angezeigt werden. Zu den Optionen gehören Diagramme, Tabellen, Diagramme, Diagramme, Gauges usw. Für jeden Metrikbereich können Schwellenwerte definiert werden. Wenn das Abfrageergebnis einen bestimmten Schwellenwert überschreitet oder unterschreitet, ändert sich die Anzeigefarbe und gibt schnell an, welche Elemente fehlerhaft sind, untersucht werden müssen oder nicht.

Mit einem Set vordefinierter Dashboards können Administratoren das System überwachen, sobald es hochgefahren und gestartet ist. Die Standardmonitoring-Dashboards sind in die folgenden Kategorien gruppiert:

Die Standard-Dashboards enthalten Metrikdaten für die physischen Komponenten des Systems – Server, Switches, Speicherprovider und deren Betriebssysteme und Firmware – sowie seine logischen Komponenten – Controller-Software, Plattform, Kubernetes-Cluster und -Microservices, Compute-Instanzen und deren virtualisierte Ressourcen. Auf diese Weise kann der Administrator oder Supporttechniker den Zustand beider Komponentenkategorien unabhängig prüfen und Korrelationen zwischen ihnen finden. Beispielsweise kann ein bestimmter Microservice aufgrund des Mangels an verfügbarem Speicher eine schlechte Performance aufweisen. Die Überwachungsdaten geben an, ob dies ein Symptom für ein Systemkonfigurationsproblem, einen Mangel an physischen Ressourcen oder einen Hardwarefehler ist. Das Überwachungssystem verfügt über einen Warndienst, der Hardwarefehler erkennen und melden kann. Der Administrator kann optional einen Benachrichtigungskanal für den Empfang von Alerts basierend auf Regeln konfigurieren, die im Überwachungssystem definiert sind.

Im Rahmen von Service- und Supportvorgängen fordert Oracle Sie möglicherweise auf, bestimmte Metrikdaten zu melden, die in den Standard-Dashboards angezeigt werden. Aus diesem Grund sollten die Standard-Dashboard-Konfigurationen immer beibehalten werden. Wenn jedoch einige der Überwachungsfunktionen versehentlich geändert oder fehlerhaft sind, können die Standardwerte wiederhergestellt werden. In ähnlicher Weise ist es Oracle möglich, neue Dashboards zu erstellen oder vorhandene zu ändern, um die Überwachung zu verbessern, und sie in Ihre Betriebsumgebung zu übertragen, ohne dass ein formales Upgradeverfahren erforderlich ist.

Alle hier beschriebenen Open-Source-Überwachungs- und Protokollierungstools verfügen über öffentliche APIs, mit denen Kunden ihre vorhandenen Überwachungs- und Warnsysteme für den Zustand integrieren können. Oracle bietet jedoch keine Unterstützung für solche benutzerdefinierten Konfigurationen.

Beobachtbarkeit der Faultdomain

Wenn es darum geht, die Appliance-Infrastruktur, die Compute-Instanzen und die zugehörigen Ressourcen in einem fehlerfreien Zustand zu halten, ist die Faultdomain ein äußerst wichtiges Konzept. Es gruppiert eine Gruppe von Infrastrukturkomponenten mit dem Ziel, Ausfallzeitereignisse aufgrund von Fehlern oder Wartung zu isolieren und sicherzustellen, dass Ressourcen in anderen Faultdomains nicht betroffen sind.

Entsprechend Oracle Cloud Infrastructure gibt es in einer Private Cloud Appliance immer drei Faultdomains. Jede Faultdomain entspricht mindestens einem physischen Compute Node. Neben der Verwendung von Grafana für Monitoringdaten im gesamten System kann ein Administrator auch direkt über die Service-Enklave auf wichtige Kapazitätsmetriken für Faultdomains zugreifen:

• Anzahl Compute Nodes pro Faultdomain

• Gesamte und verfügbare RAM-Menge pro Faultdomain

• Gesamtanzahl und verfügbare Anzahl von vCPUs pro Faultdomain

• Nicht zugewiesene CPU- und RAM-Kapazität des Systems

Die Faultdomainmetriken spiegeln die tatsächlichen physischen Ressourcen wider, die von Compute-Instanzen belegt werden können, die auf den Compute Nodes gehostet werden. Die Summen enthalten keine Ressourcen, die für den Vorgang des Hypervisors reserviert sind: 40 GB RAM und 4 CPU-Cores (8 vCPUs).

Neben den drei Faultdomains zeigt die Service-CLI die Kategorie "Nicht zugewiesen" an. Es bezieht sich auf installierte Compute Nodes, die nicht bereitgestellt wurden und daher noch nicht Teil einer Faultdomain sind. Für nicht zugewiesene Compute Nodes kann die Speicherkapazität nicht berechnet werden, aber die CPU-Metriken werden angezeigt.

Systemintegritätsprüfungen

Health Checks sind die grundlegendste Form der Erkennung. Sie werden in regelmäßigen Abständen als Kubernetes-CronJob-Services ausgeführt, die normalen UNIX-Cron-Jobs sehr ähnlich sind. Für jedes Health-Check-Ergebnis wird ein Statuseintrag erstellt. Dabei handelt es sich immer um eine von zwei Möglichkeiten: gesund oder nicht fehlerfrei. Alle Statusinformationen werden für die weitere Verarbeitung in Prometheus gespeichert; die fehlerhaften Ergebnisse generieren auch Logeinträge in Loki mit Details, um den Fehlerbehebungsprozess voranzutreiben.

Health Checks dienen dazu, den Status bestimmter Systemkomponenten zu überprüfen und Statusänderungen zu erkennen. Jeder Health Check-Prozess folgt dem gleichen Grundprinzip: um die aktuelle Bedingung aufzuzeichnen und mit dem erwarteten Ergebnis zu vergleichen. Wenn sie übereinstimmen, ist der Health Check erfolgreich. Wenn sie sich unterscheiden, ist der Health Check nicht erfolgreich. Eine Statusänderung von fehlerfrei in nicht fehlerfrei weist darauf hin, dass eine Fehlerbehebung erforderlich ist.

Zur Fehlerbehebung stehen Ihnen zwei Hauptdatenquellen zur Verfügung: Protokolle und Metriken. Beide Datenkategorien werden aus dem gesamten System gesammelt und an einem zentralen Ort gespeichert: Protokolle werden in Loki und Metriken in Prometheus aggregiert. Beide Tools verfügen über eine Abfrageschnittstelle, mit der Sie die Daten filtern und visualisieren können: Beide sind in Grafana integriert. Auf die browserbasierte Benutzeroberfläche kann über die Service-Web-UI zugegriffen werden.

Um zu untersuchen, warum ein Health Check nicht erfolgreich verläuft, können Logs und Metrikdaten basierend auf dem Fehlertyp gefiltert werden. Loki kategorisiert Daten mit einem Kennzeichnungssystem und zeigt Logmeldungen an, die mit dem ausgewählten Loglabel übereinstimmen. Wählen Sie ein Label aus der Liste, um die Logs für den gewünschten Service oder die gewünschte Anwendung anzuzeigen. In dieser Liste können Sie nicht nur die Health Checks, sondern auch die internen und externen Appliance-Services auswählen.

Darüber hinaus wird der aktuelle Status jedes Health Checks im Plattform-Health-Check-Dashboard angezeigt, das Teil des Service Advisor-Dashboard-Sets ist, das standardmäßig in Grafana bereitgestellt wird.

Private Cloud Appliance führt die unten aufgeführten Health Checks aus.

Zentralisiertes Logging

Die Plattform bietet einheitliches Logging über das gesamte System hinweg. Der Fluentd-Datensammler ruft Protokolle aus Komponenten im gesamten System ab und speichert sie an einem zentralen Ort zusammen mit den Telemetriedaten der Appliance. Infolgedessen werden alle erforderlichen Fehlerbehebungs- und Debugginginformationen in einem einzigen Datenspeicher verwaltet und müssen nicht aus verschiedenen Quellen erfasst werden, wenn ein Problem untersucht werden muss. Der Gesamtzustand des Systems wird in einer Ansicht, einem Grafana-Dashboard, erfasst. Das bedeutet, dass kein Administrator einzelne Komponenten prüfen muss.

Wenn ein Problem gefunden wird, das Unterstützung von Oracle erfordert, protokolliert der Administrator eine Serviceanfrage. Ein Support-Bundle wird in der Regel als Teil dieses Prozesses angefordert. Dank der zentralisierten Protokollierung ist das Support-Bundle einfach zu generieren und bleibt auch bei starkem Systembetrieb möglich. Das Generieren des Support-Bundles ist ein skriptbasierter Vorgang, der eine einzelne komprimierte Archivdatei erzeugt. Der Administrator muss die Archivdatei mit den konsolidierten Logs und anderen Diagnosedaten manuell hochladen.

Wenn die Private Cloud Appliance für ASR registriert ist, führen bestimmte Hardwarefehler dazu, dass eine Serviceanfrage und Diagnosedaten automatisch an den Oracle Support gesendet werden.