Oracle Cloud Infrastructure - Dokumentation

Überblick über Monitoring

Verwenden Sie den Oracle Cloud Infrastructure Monitoring-Service, um Cloud-Ressourcen mit den Metriken und Alarmen-Features aktiv und passiv zu überwachen. Erfahren Sie mehr über die Funktionsweise von Monitoring.

In dieser Abbildung werden Metriken und Alarme angezeigt, wie sie im Monitoring-Service verwendet werden.

Tipp

Sehen Sie sich ein Einführungsvideo zum Service an.

Funktionsweise von Monitoring

Der Monitoring-Service verwendet Metriken , um Ressourcen und alarme zu überwachen, um Sie zu benachrichtigen, wenn diese Metriken alarmspezifische Trigger erfüllen.

Metriken werden an den Monitoring-Service als Rohdatenpunkte oder Zeitstempel/Wert-Paare zusammen mit Dimensionen und Metadaten ausgegeben. Metriken stammen aus verschiedenen Quellen:

Sie können Metriken mit Connector-Hub aus dem Monitoring-Service übertragen. Weitere Informationen finden Sie unter Connector mit einer Monitoring-Quelle erstellen.

Metrikdaten, die an den Monitoring-Service gepostet werden, werden nur Ihnen präsentiert oder von den Oracle Cloud Infrastructure-Features genutzt, die Sie zur Verwendung der Metrikdaten aktivieren.

Wenn Sie eine Metrik abfragen, gibt der Monitoring-Service aggregierte Daten entsprechend den angegebenen Parametern zurück. Sie können einen Bereich (wie die letzten 24 Stunden), eine Statistik und ein Intervall  angeben. In der Konsole wird ein Monitoringdiagramm pro Metrik für ausgewählte Ressourcen angezeigt. Die aggregierten Daten in jedem Diagramm entsprechen dem ausgewählten Statistik- und Intervall. API-Anforderungen können optional nach Dimension filtern und eine Auflösung angeben. API-Antworten umfassen den Metriknamen sowie das zugehörige Quell-Compartment und den Metrik-Namespace . Sie können die aggregierten Daten in einer Visualisierung oder einer Diagramm-Library einfügen.

Metrik- und Alarmdaten sind über die Konsole, die CLI und die API zugänglich. Informationen zu Aufbewahrungszeiträumen finden Sie unter Speicherlimits.

Das Alarmfeature des Monitoring-Service veröffentlicht Alarm-Nachrichten für konfigurierte Ziele, z.B. Themen in Notifications und Streams in Streaming.

Metrikfeature - Überblick

Das Metrikfeature übermittelt Metrikdaten zu Zustand, Kapazität und Performance von Cloud-Ressourcen.

Eine Metrik ist ein Maß für Integrität, Kapazität oder Performance einer Ressource . Ressourcen, Services und Anwendungen geben Metriken an den Monitoringservice aus. Gemeinsame Metriken reflektieren Daten im Zusammenhang mit:

  • Verfügbarkeit und Latenz
  • Betriebszeit und Ausfallzeit der Anwendung
  • Abgeschlossene Transaktionen
  • Nicht erfolgreiche und erfolgreiche Vorgänge
  • KPIs (Key Performance-Indikatoren), wie Sales- und Engagement-Quantifizierer

Durch die Abfrage dieser Daten über Monitoring können Sie verstehen, wie gut die Systeme und Prozesse arbeiten, um die Serviceebenen zu erreichen, die Sie für Ihre Kunden festschreiben. Beispiel: Sie können die CPU-Auslastung und Datenträger-Lesezugriffe der Compute-Instanzen überwachen. Mit diesen Daten können Sie dann bestimmen, ob weitere Instanzen bereitgestellt werden sollen, um höhere Auslastungen zu handhaben, Probleme mit der Instance zu beheben oder das Systemverhalten besser zu verstehen.

Beispielmetrik: Fehlerrate

Für die Anwendungsintegrität ist einer der üblichen KPIs die Fehlerrate, die im Allgemeinen mit der Anzahl der nicht erfolgreichen Transaktionen dividiert durch die gesamten Transaktionen definiert wird. Dieser KPI wird in der Regel über die Software für das Monitoring und das Management der Anwendung bereitgestellt.

Als Entwickler können Sie diesen KPI aus Anwendungen mit benutzerdefinierten Metriken erfassen. Beobachtungen jedes Mal erfassen, wenn eine Anwendungstransaktion ausgeführt wird, und posten Sie diese Daten dann an den Monitoring-Service. Richten Sie in diesem Fall die Metriken für das Erfassen von nicht erfolgreichen Transaktionen, erfolgreichen Transaktionen und der Transaktionslatenzzeit (Zeit pro abgeschlossener Transaktion) ein.

Alarmfeature - Überblick

Mit Alarmen kann Zustand, Kapazität und Performance von Cloud-Ressourcen überwacht werden.

Ressourcen geben Metrikdatenpunkte in Monitoring aus. Wenn Alarme ausgelöst werden, senden sie Nachrichten an das konfigurierte Ziel. Bei Notifications werden Nachrichten im konfigurierten Thema an Abonnements gesendet. Bei Streaming werden Nachrichten an den konfigurierten Stream gesendet.

Das Alarmfeature des Monitoring-Service benachrichtigt Sie in Kooperation mit dem konfigurierten Zielservice, wenn Metriken alarmspezifische Trigger erfüllen. Die vorherige Abbildung zeigt den Ablauf, beginnend mit Ressourcen, die Metrik-Datenpunkte an Monitoring senden. Wenn ein Alarm ausgelöst wird, sendet er eine Alarmnachricht an das konfigurierte Ziel. Bei Notifications werden Nachrichten im konfigurierten Thema an Abonnements gesendet. Bei Streaming werden Nachrichten an den konfigurierten Stream gesendet. (Diese Abbildung deckt keine rohen und aggregierten Metrikdaten ab. Diese Details finden Sie in der Abbildung unter "Überblick über Monitoring oben auf dieser Seite.)

Sofern dies konfiguriert wurde, werden Sie im festgelegten Intervall durch Wiederholungsbenachrichtigungen über einen fortlaufenden Auslösestatus informiert. Sie können auch benachrichtigt werden, wenn ein Alarm wieder in den Status "OK" wechselt oder wenn ein Alarm zurückgesetzt wird.

Alarmauswertungen

Monitoring wertet Alarme einmal pro Minute, um den Alarmstatus zu finden.

Wenn der Alarm Benachrichtigungen aufteilt, wertet Monitoring jeden verfolgten Metrikstream aus. Wenn die Auswertung dieses Metrikstreams einen neuen FIRING-Status oder einen anderen qualifizierenden Ereignis angibt, sendet Monitoring eine Alarmnachricht.

Monitoring verfolgt Metrikstreams pro Alarm für qualifizierende Ereignisse, Nachrichten unterliegen jedoch den Zielservicelimits.

Abbildung der Alarmauswertung

Betrachten Sie einen Alarm, der das 90. Perzentil der Metrik CpuUtilization misst.

{
  "compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "destinations": ["ocid1.onstopic.exampleuniqueID"],
  "displayName": "High CPU Utilization",
  "id": "ocid1.alarm.oc1..exampleuniqueID",
  "lifecycleState": "ACTIVE",
  "metricCompartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "namespace": "oci_computeagent",
  "pendingDuration": "PT3M",
  "query": "CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85",
  "repeatNotificationDuration": "PT2H",
  "severity": "WARNING",
  "isEnabled": true,
  "timeCreated": "2023-02-01T01:02:29.600Z",
  "timeUpdated": "2023-02-03T01:02:29.600Z"
}

Hinweise zu diesem Beispielalarm:

  • Das Perzentil wird in der Abfrage als Statistik (fett) angegeben:
    CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
  • Jeder Datenpunkt ist das 90. Perzentil (percentile(0.9)) eines einminütigen Fensters, das in der Abfrage als Intervall (fett) angegeben wird:
    CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
  • Datenpunktwerte für diese Statistik können Nullwerte (absent) bis 100 sein.
  • Datenpunktauswertungen:
    • Bei einem Datenpunktwert größer als 85 ist die Auswertung "true" (1). Eine Auswertung "true" bedeutet, dass die Triggerregelbedingung erfüllt wurde.
    • Bei einem Datenpunktwert, der nicht größer als 85 ist, ist die Auswertung falsch (0).
  • Der Alarm wird erst ausgelöst, wenn die Bedingung Triggerregel drei aufeinanderfolgende Minuten lang erfüllt ist. Diese Konfiguration ist die Triggerverzögerung (pendingDuration) des Alarms, die auf PT3M gesetzt ist.
  • Der Alarm aktualisiert seinen Status auf "OK", wenn die Verletzung in der letzten Minute eindeutig war.

Die folgende Abbildung zeigt einen aggregierten Metrikstream für den Beispielalarm. Jeder Datenpunkt wird durch ein Quadrat angezeigt.


Aggregierter Metrikstream für den Beispielalarm.

Die folgende Tabelle zeigt aufeinanderfolgende Alarmauswertungen für den Beispielalarm. Der Alarm wird in einem beweglichen Fenster von drei einminütigen Intervallen ausgewertet.

Zeitstempel der Auswertungsperiode Minuten in Periode Datenpunktauswertungen* Status
3 [1 2 3] [0 0 0] OK
4 [2 3 4] [0 0 1] OK
5 [3 4 5] [0 1 1] OK
6 [4 5 6] [1 1 1] FIRING
7 [5 6 7] [1 1 1] FIRING
8 [6 7 8] [1 1 0] OK
9 [7 8 9] [1 0 0] OK
10 [8 9 10] [0 0 0] OK

*Ein Wert von eins (1) bedeutet, dass die Triggerregel-Bedingung erfüllt ist.

So werden Datenpunkte gezählt

In diesem Abschnitt wird beschrieben, wie Sie die Anzahl der von einem Alarm abgerufenen Datenpunkte (oder Datenpunkte) bestimmen. Mit dieser Zahl können Sie die Monitoring-Preise schätzen.

Um die Anzahl der von einem Alarm abgerufenen Datenpunkte zu ermitteln, rufen Sie zuerst die Anzahl der Abfragestreams und die analysierten Minuten ab.

  • Die Anzahl der Abfragestreams hängt von den von der Alarmabfrage zurückgegebenen Metrikstreams ab.
  • Die analysierten Minuten hängen von den Alarmattributen interval, resolution und pendingDuration ab. Bei Alarmabfragen ist der einzige gültige Wert für resolution 1m. Weitere Informationen zu interval finden Sie unter Intervall. Weitere Informationen zu resolution und pendingDuration finden Sie unter Monitoring-API.

Jeder Alarm wird einmal pro Minute ausgewertet, und somit wird jeder Alarm 1440 Mal pro Tag ausgewertet. Jede Auswertung fragt die Daten im von interval definierten Zeitfenster ab und prüft den Zeitraum, in dem der Alarm weiterhin durch pendingDuration definiert ist. Daher werden analysierte Minuten in jeder Minute durch den folgenden Ausdruck berechnet:

Analysierte Minuten pro Minute = interval * Obergrenze (pendingDuration / resolution)

Informationen zur internen Rücksetzungsperiode

Der interne Rücksetzungszeitraum bestimmt, wann ein Alarm die Prüfung auf eine fehlende Metrik stoppt, die den Auslösestatus in der vorherigen Auswertung ausgelöst hat. Wenn die Metrik für den gesamten Zeitraum abwesend ist, ignorieren spätere Alarmauswertungen den angegebenen Metrikstream. Wenn keine anderen Metrikstreams den Auslösestatus für den Alarm verursachen, wechselt der Alarm zu OK und sendet eine RESET-Nachricht. Standardmäßig wird die RESET-Nachricht nach 13 Minuten empfangen (interne Zurücksetzungsfrist plus slack-Standardzeitraum von 3 Minuten). Sie können den slack-Zeitraum anpassen.

Die Länge des internen Reset-Zeitraums wird global bei 10 Minuten konfiguriert, wodurch die Alarmhistorie eine Differenz von 10 Minuten anzeigt.

Der Beginn einer internen Reset-Periode hängt vom Alarmtyp ab. Bei Schwellenwertalarmen beginnt die interne Rücksetzungsperiode, wenn die erste Abwesenheit ermittelt wird. Bei Abwesenheitsalarmen beginnt die interne Rücksetzungsperiode nach Abschluss des Abwesenheitserkennungszeitraums (Standardwert 2 Stunden, kann angepasst werden).

Datenpunkte, die während einer internen Rücksetzungsperiode erfasst wurden

Jede Auswertung während der zehnminütigen internen Rücksetzungsperiode berücksichtigt alle Datenpunkte in diesem Zeitraum.

Beispiel: Ein Metrikstream (A), der den Schwellenwert überschreitet (rote Linie in den folgenden Diagrammen gestrichelt). Der Alarm wird ausgelöst (F). Wenn ein Mangel an ausgegebenen Datenpunkten erkannt wird, beginnt eine interne Zurücksetzungsfrist.

Das folgende Diagramm zeigt einen einzelnen internen Rücksetzungszeitraum für den Metrikstream A, von der Zeit t5 bis t15. Zum Zeitpunkt t16 wird der Metrikstream A nicht mehr ausgewertet.

Diagramm, das eine einzelne interne Rücksetzungsperiode darstellt.

Das folgende Diagramm zeigt zwei interne Rücksetzungsperioden für Metrikstream A, von den Zeitpunkten t3 bis t5 und von t6 bis t16. A gibt einen Datenpunkt in t6 aus und startet einen weiteren internen Rücksetzungszeitraum. Zum Zeitpunkt t17 wird der Metrikstream A nicht mehr ausgewertet.

Diagramm mit zwei internen Reset-Perioden.
Beispiel für Schwellenwertalarm

Ein Schwellenwertalarm meldet Metrikstreams, die außerhalb des Schwellenwerts auftreten. Wenn ein zuvor problematischer Metrikstream nicht vorhanden ist, startet der Alarm den internen Zurücksetzungszeitraum für den Metrikstream.

In diesem Beispiel werden vier Metrikstreams von einem Schwellenwertalarm ausgewertet. Die Konsole zeigt die anfänglichen Übergangszustände "Feuern" (1:30) und "OK" (1:51). Die interne Reset-Periode tritt auf, während der Alarm ausgelöst wird.

Beispiel für einen Schwellenwertalarm mit vier Metrikstreams.

Die interne Rücksetzungsperiode und andere wichtige Ereignisse in diesem Beispiel werden in der folgenden Tabelle beschrieben.

Zeit Bundesland Übergang Veranstaltungen Benachrichtigungen (siehe Nachrichtentypen)
12:0 OK OK Alle Emissionen liegen innerhalb der Schwelle. FIRING_TO_OK
1:30 FIRING FIRING Emission von resource1 überschreitet Schwellenwert. OK_TO_FIRING
1:35 FIRING -- Für resource1 wird keine Emission ermittelt. Der Alarm startet den internen Reset-Zeitraum für resource1. --
1:38 FIRING -- Für resource2 wird keine Emission ermittelt. Der Alarm startet den internen Reset-Zeitraum für resource2. --
1:45 FIRING -- Die interne Rücksetzungsperiode endet für resource1, sodass der Alarm nicht mehr auf Emissionen von resource1 prüft. Der Alarm wird jedoch immer noch ausgelöst, da sich resource2 noch in einer eigenen internen Zurücksetzungsperiode befindet. --
1:48 OK OK Die interne Rücksetzungsperiode endet für resource2, sodass der Alarm nicht mehr auf Emissionen von resource2 prüft. Die Emissionen der verbleibenden Ressourcen (resource3 und resource4) liegen innerhalb des Schwellenwerts. RESET (nach dem dreiminütigen slack-Zeitraum um ca. 1:51 Uhr gesendet)
Abwesenheitsalarm - Beispiel

Ein Abwesenheitsalarm meldet abwesende Metrikstreams. Wenn ein Metrikstream nicht vorhanden ist, startet der Alarm den Abwesenheitserkennungszeitraum für den Metrikstream (Standardwert von zwei Stunden kann angepasst werden). Nach Abschluss des Abwesenheitserkennungszeitraums startet der Alarm die interne Zurücksetzungsperiode für den Metrikstream.

In diesem Beispiel wird ein Metrikstream von einem Abwesenheitsalarm ausgewertet, der den standardmäßigen zweistündigen Abwesenheitserkennungszeitraum und den standardmäßigen dreiminütigen slack-Zeitraum verwendet. Die Konsole zeigt die anfänglichen Übergangszustände "Feuern" (2:00) und "OK" (4:10). Die interne Reset-Periode tritt auf, während der Alarm ausgelöst wird.

Beispiel für einen Abwesenheitsalarm mit einem einzelnen Metrikstream.

Die interne Rücksetzungsperiode und andere wichtige Ereignisse in diesem Beispiel werden in der folgenden Tabelle beschrieben.

Zeit Bundesland Übergang Veranstaltungen Benachrichtigungen (siehe Nachrichtentypen)
1:00 Uhr OK -- Emissionen werden erkannt.
2:00 Uhr FIRING FIRING Für resource-z wurde keine Emission ermittelt. Der Alarm startet die Abwesenheitserkennungsperiode für resource-z. OK_TO_FIRING
4:0 FIRING -- Die Abwesenheitserkennungsperiode für resource-z endet. Der Alarm startet den internen Reset-Zeitraum für resource-z. --
4:10 OK OK Die interne Reset-Periode endet für resource-z, sodass der Alarm nicht mehr auf Emissionen von resource-z überprüft. Es werden keine Metrikstreams mehr vom Alarm überwacht, sodass der Alarm in den Status "OK" übergeht. RESET (nach dem dreiminütigen slack-Zeitraum um ca. 4:13 Uhr gesendet)

Erforderliche Zeit bis zur Berücksichtigung von Alarmaktualisierungen

Es kann bis zu fünf Minuten dauern, bis Aktualisierungen von Alarmen überall berücksichtigt werden.

Beispiel: Wenn Sie einen Alert in aufgeteilte Benachrichtigungen aktualisieren, kann es bis zu fünf Minuten dauern, bis die Metrikstreamstatus in der Konsole aufgefüllt wird.

Nachrichtentypen

Der Nachrichtentyp zeigt den Grund für das Senden der Nachricht an.

Hinweis

Der angegebene Nachrichtentyp wird zu dem angegebenen Zeitpunkt plus der konfigurierten Triggerverzögerung des Alarms gesendet, sofern vorhanden.

Wiederholungsnachrichten werden auch gesendet, wenn sie im Alarm konfiguriert sind.

In der folgenden Tabelle sind der Alarmstatus und -übergang für jeden Nachrichtentyp aufgeführt.

Nachrichtentyp Bundesland Übergang Anmerkungen
OK_TO_FIRING FIRING von OK bis FIRING
FIRING_TO_OK OK von FIRING bis OK
REPEAT FIRING -- Dieser Nachrichtentyp wird gesendet, wenn der Alarm den Status FIRING beibehält und der Alarm für Wiederholungsbenachrichtigungen konfiguriert ist.
RESET OK von FIRING bis OK

Wichtig: Wenn eine RESET-Statusänderung auftritt, wählen Sie die Status der Ressource.

Dieser Nachrichtentyp wird gesendet, wenn der Alarm nach mindestens einem internen Zurücksetzen in den Status OK übergeht. Ein internes Zurücksetzen erfolgt, wenn ein Metrikstream, der den Übergang des Alarms in den FIRING-Status verursacht hat, während des vollständigen internen Zurücksetzungszeitraums kontinuierlich abwesend ist. Ein Metrikstream, der intern zurückgesetzt wird, wird nicht mehr vom Alarm verfolgt.

Mögliche Ursachen für einen fehlenden Metrikstream: Die Ressource, von der die Metrik ausgegeben wurde, wurde möglicherweise verschoben oder beendet, oder die Metrik wird möglicherweise nur bei einem Fehler ausgegeben. Weitere Informationen zur internen Rücksetzungsperiode finden Sie unter Informationen zur internen Rücksetzungsperiode.

Monitoring-Konzepte

Die folgenden Konzepte sind für die Arbeit mit Monitoring von wesentlicher Bedeutung.

Aggregierte Daten
Das Ergebnis bei der Anwendung einer Statistik und des Intervalls auf eine Auswahl von Rohdatenpunkten für eine Metrik. Beispiel: Sie können die Statistik max und dasIntervall 1h (eine Stunde) auf die Rohdatenpunkte der letzten 24 Stunden für die Metrik CpuUtilization anwenden. Aggregierte Daten werden in Standardmetrikdiagrammen in der Konsole angezeigt. Sie können auch Metrikabfragen für bestimmte Gruppen von aggregierten Daten erstellen. Anweisungen hierzu finden Sie unter Standardmetrikdiagramme anzeigen und Metrikabfragen erstellen.
Alarm
Die auszuwertende Alarmabfrage und das Benachrichtigungsziel, das verwendet werden soll, wenn sich der Alarm im Auslösestatus befindet, zusammen mit anderen Alarmeigenschaften.
Informationen zum Erstellen eines Alarms finden Sie unter Alarm erstellen.
Alarmabfrage
Der Monitoring Query Language-(MQL-)Ausdruck, der für den Alarm ausgewertet werden soll. Eine Alarmabfrage muss eine Metrik, eine Statistik, ein Intervall und eine Triggerregel (Schwellenwert oder Abwesenheit) angeben. Das Alarmfeature des Monitoring-Service interpretiert Ergebnisse für jede zurückgegebene Zeitreihe als booleschen Wert, wobei null für "false" steht und ein Wert ungleich null für "true" darstellt. Ein Wert von "true" bedeutet, dass die Triggerregelbedingung erfüllt wurde.
Informationen zum Erstellen einer allgemeinen Alarmabfrage finden Sie unter Allgemeine Abfrage zum Generieren eines Alarmmetrikdiagramms erstellen. Informationen zum Erstellen eines Alarms finden Sie unter Alarm erstellen.
Datenpunkt
Ein Zeitstempel/Wert-Paar für die angegebene Metrik. Beispiel: 2022-05-10T22:19:00Z, 10.4
Ein Datenpunkt ist entweder roh oder aggregiert. Rohdatenpunkte werden vom Metrik-Namespace an den Monitoring-Service mit dem Vorgang PostMetricData gepostet. Die Häufigkeit der geposteten Datenpunkte variiert je nach Metrik-Namespace. Beispiel: Ein benutzerdefinierter Namespace kann Datenpunkte für eine Metrik mit einer Häufigkeit von 20 Sekunden senden.
Aggregierte Datenpunkte sind das Ergebnis der Anwendung einer Statistik und eines Intervalls auf Rohdatenpunkte. Das Intervall der aggregierten Datenpunkte wird in der Anforderung SummarizeMetricsData angegeben. Beispiel: Eine Anforderung, die Statistik sum und Intervall 1h (eine Stunde) angibt, gibt einen sum-Wert für jede Stunde der verfügbaren Rohdatenpunkte für die Metrik zurück.
Dimension
Ein Qualifier, der in einer Metrikdefinition angegeben wird. Beispiel: Ressourcen-ID (resourceId), die in den Definitionen der oci_computeagent-Metriken angegeben wird. Mit Dimensionen können Sie Metrikdaten filtern oder gruppieren. Beispiel-Name/Wert-Paar für Dimensionen zum Filtern nach Availability-Domain: availabilityDomain = "VeBZ:PHX-AD-1"
Informationen zur Auswahl einer Dimension für ein Metrikdiagramm oder für eine Abfrage finden sie unter Dimensionen zum Filtern von Metriken auswählen und Dimensionen für eine Abfrage wählen.
Informationen zum Auswählen eines Intervalls für einen Alarm finden Sie unter Intervall für eine Alarmabfrage auswählen.
Häufigkeit
Der Zeitraum zwischen jedem geposteten Rohdatenpunkt für eine Metrik. (Rohdatenpunkte werden vom Metrik-Namespace an den Monitoring-Service gepostet.) Die Häufigkeit variiert je nach Metrik. Standardservicemetriken weisen normalerweise eine Häufigkeit von 60 Sekunden (auch ein Datenpunkt pro Minute gepostet) auf. Siehe auch Auflösung.
Intervall
Das Zeitfenster, in dem die Gruppe von Rohdatenpunkten konvertiert werden.
Der Zeitstempel des aggregierten Datenpunkts entspricht dem Ende des Zeitfensters, während dessen Rohdatenpunkte geprüft werden. Beispiel: Bei einem Intervall von fünf Minuten entspricht der Zeitstempel "2:05" dem Zeitfenster von 2:00:n bis 2:05:00.
In dieser Abbildung wird dargestellt, wie der Zeitstempel eines aggregierten Datenpunkts dem Intervall entspricht.
Die folgende Beispielabfrage (MQL-Ausdruck) gibt ein 5-Minuten-Intervall ein. Gültige Intervalloptionen in MQL-Ausdrücken finden Sie unter Intervall (Monitoring Query Language-(MQL-)Referenz).
CpuUtilization[5m].max()
Hinweis

Unterstützte Werte für das Intervall hängen vom angegebenen Zeitraum in der Metrikabfrage (nicht für Alarmabfragen) ab. Für kürzere Zeiträume werden weitere Intervallwerte unterstützt. Beispiel: Wenn Sie eine Stunde für den Zeitraum auswählen, werden alle Intervallwerte unterstützt. Wenn Sie 90 Tage als Zeitraum auswählen, werden nur Intervallwerte zwischen 1 Stunde und 1 Tag unterstützt.
Informationen zum Auswählen eines Intervalls für ein Metrikdiagramm oder eine Abfrage finden Sie unter Intervall für ein Standardmetrikdiagramm ändern und Intervall für eine Abfrage auswählen.
Informationen zum Auswählen eines Intervalls für einen Alarm finden Sie unter Intervall für eine Alarmabfrage auswählen.
Siehe auch Auflösung.
Nachricht
Der Inhalt, den das Alarmfeature des Monitoring-Service in Themen in den konfigurierten Benachrichtigungszielen des Alarms veröffentlicht. Eine Nachricht wird gesendet, wenn der Alarm in einen anderen Status übergeht, beispielsweise von OK zu FIRING.
Weitere Informationen zu Alarmnachrichten finden Sie unter Nachrichtenformat und Beispiele.
Metadaten
Eine Referenz, die in einer Metrikdefinition angegeben wird. Beispiel: Einheit (Byte), angegeben in der Definition der oci_computeagent-Metrik DiskBytesRead. Mit Metadaten können Sie zusätzliche Informationen zu einer Metrik bestimmen. Metrikdefinitionen finden Sie unter Unterstützte Services.
Metrik
Eine auf Zustand, Kapazität oder Performance einer Ressource bezogene Metrik. Beispiel: Die oci_computeagent-Metrik CpuUtilization, die die Verwendung einer Recheninstanz misst. Metrikdefinitionen finden Sie unter Unterstützte Services.
Hinweis

Metrikressourcen haben keine OCIDs .
Metrikdefinition
Eine Gruppe von Referenzen, Qualifiern und anderen Informationen, die von einem Metrik-Namespace für eine Metrik bereitgestellt werden. Beispiel: Die oci_computeagent-Metrik DiskBytesRead wird durch Dimensionen (wie Ressourcen-ID) und Metadaten (Angabe der Byte für Einheit) sowie die Identifizierung des Metrik-Namespace (oci_computeagent) definiert. Jede gepostete Gruppe von Datenpunkten enthält diese Informationen. Verwenden Sie den ListMetricData-API-Vorgang, um Metrikdefinitionen abzurufen. Metrikdefinitionen finden Sie unter Unterstützte Services.
Informationen zum Auswählen eines Metriknamens für eine Abfrage finden Sie unter Metriknamen für eine Abfrage auswählen.
Informationen zum Auslesen eines Metriknamens für einen Alarm finden sie unter Allgemeine Abfrage zum Generieren eines Alarmmetrikdiagramms erstellen und Allgemeinen Alarm erstellen.
Metrik-Namespace
Indikator der Ressource , des Service oder der Anwendung, die die Metrik ausgibt. Wird in der Metrikdefinition angegeben. Beispiel: Die Metrikdefinition CpuUtilization, die von der Oracle Cloud Agent-Software auf Compute-Instanzen ausgegeben wird, listet den Metrik-Namespace oci_computeagent als Quelle der Metrik CpuUtilization auf. Metrikdefinitionen finden Sie unter Unterstützte Services.
Informationen zum Auswählen eines Metrik-Namespace für ein Metrikdiagramm oder eine Abfrage finden Sie unter Standardmetrikdiagramme für einen Metrik-Namespace anzeigen (mehrere Ressourcen) und Metrik-Namespace für eine Abfrage auswählen.
Unter Allgemeine Abfrage zum Generieren eines Alarmmetrikdiagramms erstellen und Allgemeinen Alarm erstellen wird beschrieben, wie Sie einen Metrik-Namespace für einen Alarm auswählen.
Metrikstream
Ein einzelnes Set aggregierter Daten für eine Metrik und null oder mehr Dimensionswerte.
Auf der Seite "Metrikstreamstatus" entspricht jeder Metrikstream einem Set von Schlüssel/Wert-Paaren für Dimensionen.
In Metrikdiagrammen (in der Konsole) wird jeder Metrikstream als Linie dargestellt (außer Sie aggregieren alle Metrikstreams).
Die folgende Abbildung zeigt Metrikstreams in einem Diagramm. Jede Linie im Diagramm entspricht einem Metrikstream.
Diese Abbildung zeigt Metrikstreams in einem Diagramm. Jede Linie im Diagramm entspricht einem Metrikstream.
Beispiel: ein Compartment mit drei Compute-Instanzen in der Availability-Domain AD-1 (darunter zwei im Instanzpool ipexample) und eine vierte Instanz in der Availability-Domain AD-2. In diesem Beispiel zeigt das Metrikdiagramm "CPU-Auslastung" vier Linien (eine pro Instanz). Beim Filtern nach der Availability-Domain AD-1 zeigt das Diagramm drei Linien. Beim weiteren Filtern nach dem Instanzpool ipexample zeigt das Diagramm zwei Linien.
Informationen zum Auswählen von Metrikstreams in einer Abfrage finden Sie unter Dimensionen für eine Abfrage auswählen, Dimensionen für eine Abfrage auswählen und Dimensionen für eine Alarmabfrage wählen.
Informationen zum Einrichten eines Alarms für Benachrichtigungen pro Metrikstream finden Sie unter Alarm zum Aufteilen von Nachrichten nach Metrikstream erstellen und Szenario: Nachrichten nach Metrikstream aufteilen.
Benachrichtigungsziel
Details zum Senden von Nachrichten, wenn der Alarm in einen anderen Status übergeht, beispielsweise von OK in FIRING. Die Details und das Setup können je nach Zielservice variieren. Die verfügbaren Zielservices sind Notifications und Streaming.
Geben Sie für den Notifications-Service ein Thema an. (Wenn Sie das Thema für den Alarm erstellen, geben Sie auch mindestens ein Abonnementprotokoll (z.B. PagerDuty) an.)
Geben Sie für den Streaming-Service einen Stream an.
Beispiele für Alarmnachrichten, die an Themen und Streams gesendet werden, finden Sie unter Beispielalarmnachrichten.
Informationen zum Einrichten eines Benachrichtigungsziels in einem Alarm finden Sie unter Benachrichtigungen für einen Alarm definieren.
Oracle Cloud Agent-Software
Software, mit der eine Compute-Instanz Raw-Datenpunkte an den Monitoring-Service posten kann. Wird automatisch mit den neuesten Versionen von unterstützten Images installiert. Siehe Monitoring für Compute-Instanzen aktivieren.
query
Der Monitoring Query Language-(MQL-)Ausdruck und zugehörige Informationen (wie Metrik-Namespace), die zur Rückgabe aggregierter Daten ausgewertet werden. Die Abfrage muss eine Metrik, eine Statistik und ein Intervall angeben.
Informationen zum Erstellen einer Metrikabfrage finden Sie unter Abfrage erstellen.
Informationen zum Erstellen einer Alarmabfrage finden Sie unter Allgemeine Abfrage zum Generieren eines Alarmmetrikdiagramms erstellen.
Auflösung

Der Zeitraum zwischen den Zeitfenstern oder die Regelmäßigkeit, zu der Zeitfenster verschoben werden. Beispiel: Verwenden Sie eine Auflösung von 1m, um Aggregationen jede Minute abzurufen.

Hinweis

Bei Metrikabfragen bestimmt das ausgewählte Intervall die standardmäßige Auflösung der Anforderung, womit der maximale Zeitraum für die zurückgegebenen Daten bestimmt wird.

Bei Alarmabfragen hat das angegebene Intervall keine Auswirkung auf die Lösung  der Anforderung. Der einzige gültige Wert der Auflösung einer Alarmabfrageanforderung ist 1m. Weitere Informationen zum Auflösungsparameter und seiner Verwendung in Alarmabfragen finden Sie unter Alarm.

Wie in der folgenden Abbildung dargestellt, kontrolliert die Auflösung die Startzeit jedes Aggregationsfensters bezogen auf das vorherige Fenster, während das Intervall die Länge der Fenster kontrolliert. Beide Anforderungen wenden die Statistik max auf die Daten in jedem fünf-Minuten-Fenster (aus dem Intervall) an. Dadurch wird ein einzelner aggregierter Datenpunkt, der den höchsten CPUutilization-Zähler für dieses Fenster darstellt, angezeigt. Nur der Auflösungswert ist unterschiedlich. Durch diese Auflösung wird die Regelmäßigkeit geändert, bei der die Aggregationsfenster verschoben werden, oder die Startzeiten von aufeinanderfolgenden Aggregationsfenstern. Anforderung A gibt die Auflösung nicht an und verwendet somit den Standardwert gleich dem Intervall (5 Minuten). Die 5-Minuten-Aggregationsfenster dieser Anforderung stammen somit aus den Gruppen der Datenpunkte, die von 0:n bis 5:00, 5:n bis 10:00 usw. ausgegeben werden. Anforderung B gibt eine 1-Minuten-Auflösung an, sodass ihre 5-Minuten-Aggregationsfenster von der Gruppe der Datenpunkte übernommen werden, die jede Minute von 0:n bis 5:00, 1:n bis 6:00 usw. ausgegeben werden.

Diese Abbildung zeigt, wie Aggregationsfenster nach der Auflösung beginnen.

Informationen dazu, wie Sie eine nicht standardmäßige Auflösung angeben, die vom Intervall abweicht, finden sie unter Nicht-Standardauflösungen für eine Abfrage auswählen und Alarm erstellen.

Ressourcengruppe
Eine benutzerdefinierte Zeichenfolge, die mit einer benutzerdefinierten Metrik bereitgestellt wird und als Filter oder zur Aggregation von Ergebnissen verwendet werden kann. Die Ressourcengruppe muss in der Definition der geposteten Metrik vorhanden sein. Pro Metrik kann nur eine Ressourcengruppe angewendet werden.
Informationen zum Auswählen einer Ressourcengruppe in einer Abfrage finden Sie unter Ressourcengruppe in einer Abfrage auswählen.
Informationen zum Auswählen einer Ressourcengruppe in einer Alarmabfrage finden Sie unter Ressourcengruppe in einer Alarmabfrage auswählen.
Statistik
Die Aggregationsfunktion, die auf die Gruppe von Rohdatenpunkten angewendet wird
Informationen zum Auswählen der Statistik für ein Metrikdiagramm oder eine Abfrage finden Sie unter Statistik für ein Standardmetrikdiagramm ändern und Statistik für eine Abfrage auswählen.
Informationen zum Auswählen der Statistik für eine Alarmabfrage finden Sie unter Statistik für eine Alarmabfrage auswählen.
suppression
Eine Konfiguration zum Stoppen des Veröffentlichens von Nachrichten im angegebenen Zeitraum. Dies ist nützlich, um Alarmbenachrichtigungen während der Systemwartung zu unterbrechen.
Informationen zum Unterdrücken von Alarmen finden Sie unter Einzelnen Alarm unterdrücken und Mehrere Alarme unterdrücken.
Zeitraum
Die Grenzen (Zeitstempel) der gewünschten Metrikdaten. Beispiel: die letzte Stunde.
Informationen dazu, wie Sie den Zeitraum für ein Metrikdiagramm oder die Abfrage auswählen, finden sie unter Zeitraum für Standardmetrikdiagramme ändern, Zeitraum für ein benutzerdefiniertes Metrikdiagramm bearbeiten und Nicht standardmäßige Zeiträume für eine Abfrage auswählen.
Triggerregel
Die Bedingung, die erfüllt werden muss, damit der Alarm den Auslösestatus aufweist. Eine Triggerregel kann auf einem Schwellenwert oder auf Abwesenheit einer Metrik basieren.
Informationen zum Einrichten einer Triggerregel in einem Alarm finden Sie unter Triggerregeln zu einem Alarm hinzufügen.

Verfügbarkeit

Der Monitoring-Service ist in allen kommerziellen Oracle Cloud Infrastructure-Regionen verfügbar. Unter Informationen zu Regionen und Availability-Domains finden Sie die Liste der verfügbaren Regionen sowie zugehörige Standorte, Regions-IDs, Regionsschlüssel und Availability-Domains.

Unterstützte Services

Die folgenden Services haben Ressourcen oder Komponenten, die Metriken an Monitoring ausgeben können:

Ressourcen-IDs

Die meisten Oracle Cloud Infrastructure-Ressourcentypen verfügen über eine eindeutige, von Oracle zugewiesene ID, die als Oracle Cloud-ID (OCID) bezeichnet wird. Weitere Informationen zum OCID-Format und zu anderen Möglichkeiten zur Identifizierung von Ressourcen finden Sie unter Ressourcen-IDs. Siehe Ressourcen-IDs.

Hinweis

Metrikressourcen haben keine OCIDs .

Möglichkeiten für den Zugriff auf Monitoring

Auf Oracle Cloud Infrastructure (OCI) können Sie über die Konsole (eine browserbasierte Schnittstelle), die REST-API oder die OCI-CLI zugreifen. Anweisungen zur Verwendung der Konsole, API und CLI sind in verschiedenen Themen in dieser Dokumentation enthalten. Eine Liste der verfügbaren SDKs finden Sie unter Software Development Kits und Befehlszeilenschnittstelle.

Konsole: Um über die Konsole auf Monitoring zuzugreifen, müssen Sie einen unterstützten Browser verwenden. Um zu der Anmeldeseite der Konsole zu wechseln, rufen Sie das Navigationsmenü am Anfang dieser Seite auf, und wählen Sie Infrastrukturkonsole aus. Dort werden Sie aufgefordert, Ihren Cloud-Mandanten, Benutzernamen und Ihr Kennwort einzugeben. Öffnen Sie das Navigationsmenü , und wählen Sie Observability and Management aus. Wählen Sie unter Monitoring die Option Servicemetriken aus.

API: Um über APIs auf Monitoring zuzugreifen, verwenden Sie die Monitoring-API für Metriken und Alarme und die Notifications-API für Benachrichtigungen (wird bei Alarmen verwendet).

CLI: siehe Befehlszeilenreferenz für Monitoring und Befehlszeilenreferenz für Notifications.

Authentifizierung und Autorisierung

Jeder Service in Oracle Cloud Infrastructure kann zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) in IAM eingebunden werden.

Ein Administrator in einer Organisation muss Gruppen , Compartments und Policys einrichten, die steuern, welche Benutzer auf Services, Ressourcen und Zugriffstypen zugreifen können. Beispiel: Die Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und bearbeiten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen darf usw. Weitere Informationen finden Sie unter Identitätsdomains verwalten. Einzelheiten zum Schreiben von Policys für die einzelnen Services finden Sie in der Policy-Referenz.

Wenn Sie ein regulärer Benutzer (kein Administrator) sind, der die Oracle Cloud Infrastructure-Ressourcen verwenden muss, für die das Unternehmen verantwortlich ist, bitten Sie einen Administrator, eine Benutzer-ID für Sie einzurichten. Der Administrator kann festlegen, welche Compartments Sie verwenden können.

Weitere Informationen zu Benutzerautorisierungen für Monitoring finden Sie unter IAM-Policys.

Für Administratoren: Informationen zu allgemeinen Policys, mit denen Gruppen Zugriff auf Metriken erteilt werden kann, finden Sie unter Metrikzugriff für Gruppen. Informationen zu allgemeinen Alarm-Policys finden Sie unter Alarmzugriff für Gruppen. Um Ressourcen wie Instanzen zu autorisieren, um API-Aufrufe vorzunehmen, fügen Sie die Ressourcen zu einer dynamischen Gruppe hinzu. Verwenden Sie die Abgleichsregeln der dynamischen Gruppe, um die Ressourcen hinzuzufügen, und erstellen Sie dann eine Policy, mit der dieser dynamischen Gruppe der Zugriff auf Metriken gewährt wird. Siehe Metrikzugriff für Ressourcen.

Limits für Monitoring

Unter Monitoring-Limits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung anfordern.

Andere Limits umfassen:

Speicherlimits

Artikel Gespeicherter Zeitraum
Metrikdefinitionen 90 Tage
Alarmhistorieneinträge 90 Tage

Limits für Alarmnachrichten

Die maximale Anzahl von Nachrichten pro Alarmauswertung hängt vom Alarmziel an. Die Limits sind mit dem Oracle Cloud Infrastructure-Service verknüpft, der für das Ziel verwendet wird.

Monitoring verfolgt 200.000 Metrikstreams pro Alarm für qualifizierende Ereignisse. Weitere Informationen zu Alarmauswertungen finden Sie unter Alarmauswertungen auf dieser Seite.

Alarmziel Zustellung Maximale Anzahl Alarmnachrichten pro Auswertung
Thema (Notifications) Mindestens einmal 60
Stream (Streaming) Mindestens einmal 100.000

Beispiel: Beachten Sie die folgenden Auswertungen eines Alarms, der Benachrichtigungen unter 200 Metrikstreams aufteilt und ein Thema als Ziel verwendet.

Alarmauswertung (Zeit) Metrikstreamübergang Generierte Nachrichten Gesendete Nachrichten Gelöschte Nachrichten
00:01:00 110 Metrikstreams gehen von OK in FIRING über. 110 60 50
00:02:00 90 Metrikstreams gehen von OK in FIRING über. 90 60 30

Wenn ein Thema oder Stream überlastet ist, können die Alarmbenachrichtigungen verzögert werden. Eine Überlastung kann auftreten, wenn mehrere Ressourcen dieses Thema oder diesen Stream verwenden.

Best Practices für das Arbeiten innerhalb von Limits

Wenn Sie eine hohe Anzahl an Alarmbenachrichtigungen erwarten, befolgen Sie diese Best Practices, um zu verhindern, dass Grenzwerte für Alarmmeldungen überschritten werden und Verzögerungen auftreten.

  • Reservieren Sie ein einzelnes Thema oder einen einzelnen Stream zur Verwendung mit einem Alarm mit hohem Volumen. Verwenden Sie nicht ein einzelnes Thema oder einen einzelnen Stream für mehrere Alarme mit hohem Volumen.
  • Wenn Sie mehr als 60 Nachrichten pro Minute erwarten, geben Sie Streaming als Alarmziel an.
  • Streams:
    • Erstellen Sie Partitionen basierend auf der erwarteten Last. Siehe Limits für Streaming-Ressourcen.
    • Wenn Alarmmeldungen den Stream-Speicherplatz überschreiten, aktualisieren Sie den Alarm so, dass er einen anderen Stream mit mehr Partitionen verwendet. Beispiel: Wenn der ursprüngliche Stream fünf Partitionen enthält, erstellen Sie einen Stream mit zehn Partitionen, und aktualisieren Sie dann den Alarm, sodass er den neuen Stream verwendet.
      Hinweis

      Um fehlende Nachrichten zu vermeiden, verwenden Sie den ursprünglichen Stream weiter, bis keine weiteren Nachrichten empfangen werden.
  • Erhöhen Sie die Limits für den Mandanten:

Sicherheit

In diesem Thema wird die Sicherheit für Monitoring beschrieben.

Informationen zum Sichern von Monitoring, einschließlich Sicherheitsinformationen und Empfehlungen, finden Sie unter Monitoring sichern.