Oracle Cloud Infrastructure - Dokumentation

Überblick über Monitoring

Mit Oracle Cloud Infrastructure Monitoring können Sie Cloud-Ressourcen mit den Features "Metriken" und "Alarme" aktiv und passiv ü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 zu überwachen, und Alarme , um Sie zu benachrichtigen, wenn diese Metriken alarmspezifische Trigger erfüllen.

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

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

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

Bei der Abfrage einer Metrik 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 Monitoring-Diagramm pro Metrik für ausgewählte Ressourcen angezeigt. Die aggregierten Daten in jedem Diagramm entsprechen der ausgewählten Statistik und des ausgewählten Intervalls. API-Anforderungen können optional nach Dimension filtern und eine Auflösung angeben. API-Antworten umfassen den Metriknamen zusammen mit dem zugehörigen Quell-Compartment und dem Metrik-Namespace . Sie können die aggregierten Daten in einer Visualisierung oder einer Diagramm-Library einfügen.

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

Das Feature "Alarme" des Monitoring-Service veröffentlicht Alarmnachrichten für konfigurierte Ziele, z.B. Themen in Notifications und Streams in Streaming.

Metrikfeature - Überblick

Mit dem Metrikfeature werden Metrikdaten über den Zustand, die Kapazität und die Performance von Cloud-Ressourcen übermittelt.

Eine Metrik ist ein Maß für Integrität, Kapazität oder Performance einer Ressource . Ressourcen, Services und Anwendungen senden Metriken an den Monitoring-Service. 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 funktionieren, um die Serviceebenen zu erreichen, die Sie für Ihre Kunden festschreiben. Beispiel: Sie können die CPU-Auslastung und die Datenträgerlesungen der Compute-Instanzen überwachen. Mit diesen Daten können Sie dann entscheiden, ob Sie mehr Instanzen bereitstellen möchten, um höhere Auslastungen zu behandeln, Probleme mit der Instanz 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 normalerweise über die Software für das Monitoring und die Verwaltung der Anwendung bereitgestellt.

Als Entwickler können Sie diesen KPI aus Anwendungen mit benutzerdefinierten Metriken erfassen. Erfassen Sie Beobachtungen zu jeder Anwendungstransaktion, 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

Verwenden Sie Alarme, um Zustand, Kapazität und Performance von Cloud-Ressourcen zu überwachen.

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 Zusammenarbeit mit dem konfigurierten Zielservice, wenn Metriken alarmspezifische Trigger erfüllen. Die vorherige Abbildung zeigt den Ablauf, beginnend mit Ressourcen, die Metrikdatenpunkte 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 werden auch benachrichtigt, wenn ein Alarm wieder in den Status "OK" wechselt oder wenn ein Alarm zurückgesetzt wird.

Alarmauswertungen

Monitoring bewertet Alarme einmal pro Minute, um den Alarmstatus zu ermitteln.

Wenn der Alarm Benachrichtigungen aufteilt, bewertet Monitoring jeden verfolgten Metrikstream. Wenn die Auswertung dieses Metrikstreams einen neuen FIRING-Status oder ein anderes qualifizierendes Ereignis angibt, sendet Monitoring eine Alarmnachricht.

Monitoring trackt Metrikströme pro Alarm für qualifizierende Ereignisse, Nachrichten unterliegen jedoch den Zielservicelimits.

Abbildung der Alarmbewertung

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 ist:
    CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
  • Datenpunktwerte für diese Statistik können von Null (abwesend) bis 100 sein.
  • Datenpunktauswertungen:
    • Bei Datenpunktwerten, die größer als 85 sind, ist die Auswertung wahr (1). Eine echte Auswertung bedeutet, dass die Triggerregelbedingung erfüllt wurde.
    • Bei Datenpunktwerten, die nicht größer als 85 sind, 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 als PT3M festgelegt ist.
  • Der Alarm aktualisiert seinen Status auf OK, wenn die Verletzung in der letzten Minute klar war.

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


Aggregierter Metrikstream für den Beispielalarm.

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

Zeitstempel des Auswertungszeitraums 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 einer (1) bedeutet, dass die Triggerregelbedingung 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 jeder Alarm 1440 Mal pro Tag ausgewertet. Jede Auswertung fragt die Daten in dem von interval definierten Zeitfenster ab und prüft den Zeitraum, in dem der Alarm durch pendingDuration definiert bleibt. Daher werden in jeder Minute analysierte Minuten mit dem folgenden Ausdruck berechnet:

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

Informationen zum internen Rücksetzungszeitraum

Der interne Zurücksetzungszeitraum bestimmt, wann ein Alarm die Prüfung auf eine abwesende Metrik stoppt, die den Auslösestatus in der vorherigen Bewertung ausgelöst hat. Wenn die Metrik für den gesamten Zeitraum nicht vorhanden ist, ignorieren spätere Alarmauswertungen den angegebenen Metrikstream. Wenn keine anderen Metrikstreams den Auslösestatus für den Alarm verursachen, geht der Alarm in "OK" über und sendet eine RESET-Nachricht. Standardmäßig kommt die RESET-Nachricht nach 13 Minuten (interner RESET-Zeitraum plus Standard-Slack-Zeitraum von 3 Minuten) an. Sie können den Pufferzeitraum anpassen.

Die Länge des internen Zurücksetzungszeitraums wird global nach 10 Minuten konfiguriert. Dadurch zeigt die Alarmhistorie einen Unterschied von 10 Minuten an.

Der Beginn einer internen Rücksetzungsperiode hängt vom Alarmtyp ab. Bei Schwellenwertalarmen beginnt die interne Zurücksetzungsperiode, wenn die erste Abwesenheit erkannt wird. Bei Abwesenheitsalarmen beginnt die interne Zurücksetzungsperiode nach Abschluss der Abwesenheitserkennungsperiode (Standardwert: 2 Stunden, kann angepasst werden).

Datenpunkte, die während einer internen Zurücksetzungsperiode gesammelt wurden

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

Beispiel: Ein Metrikstream (A), der den Schwellenwert überschreitet (in den folgenden Diagrammen gestrichelte rote Linie). Der Alarm wird ausgelöst (F). Wenn ein Mangel an emittierten Datenpunkten erkannt wird, beginnt ein interner Rücksetzungszeitraum.

Das folgende Diagramm zeigt einen einzelnen internen Zurücksetzungszeitraum für den Metrikstream A von den Zeiten 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ücksetzungszeiträume für den Metrikstream A, von t3 bis t5 und von t6 bis t16. A gibt einen Datenpunkt bei t6 aus und startet einen weiteren internen Zurücksetzungszeitraum. Zum Zeitpunkt t17 wird der Metrikstream A nicht mehr ausgewertet.

Diagramm mit zwei internen Rücksetzungsperioden.
Beispiel für einen Schwellenwertalarm

Ein Schwellenwertalarm meldet Metrikstreams, die außerhalb des Schwellenwertes auftreten. Wenn kein vorher problematischer Metrikstream vorhanden ist, startet der Alarm den internen Rü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) an. Die interne Rücksetzungsperiode tritt auf, während sich der Alarm im Auslösestatus befindet.

Beispiel für einen Schwellenwertalarm mit vier Metrikstreams.

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

Zeit Status Übergang Ereignisse Benachrichtigungen (siehe Nachrichtentypen)
12:0 OK OK Alle Emissionen liegen innerhalb der Schwelle. FIRING_TO_OK
1:30 FIRING FIRING Die Emission von resource1 überschreitet den Schwellenwert. OK_TO_FIRING
1:35 FIRING -- Für resource1 wird keine Emission festgestellt. Der Alarm startet den internen Rücksetzungszeitraum für resource1. --
1:38 FIRING -- Für resource2 wird keine Emission festgestellt. Der Alarm startet den internen Rücksetzungszeitraum für resource2. --
1:45 FIRING -- Der interne Rücksetzungszeitraum endet für resource1, sodass der Alarm nicht mehr auf Emissionen von resource1 prüft. Der Alarm wird jedoch immer noch ausgelöst, weil sich resource2 noch in einem eigenen internen Rücksetzungszeitraum befindet. --
1:48 OK OK Der interne Rücksetzungszeitraum endet für resource2, sodass der Alarm nicht mehr auf Emissionen von resource2 prüft. Emissionen aus den verbleibenden Ressourcen (resource3 und resource4) liegen innerhalb des Schwellenwertes. RESET (nach der dreiminütigen Slack-Periode um ca. 1:51 Uhr gesendet)
Beispiel für Abwesenheitsalarm

Ein Abwesenheitsalarm meldet abwesende Metrikstreams. Wenn kein Metrikstream vorhanden ist, startet der Alarm die Abwesenheitserkennungsperiode für den Metrikstream (Standardwert von zwei Stunden, kann angepasst werden). Nach Abschluss des Zeitraums für die Abwesenheitserkennung startet der Alarm den internen Rücksetzungszeitraum für den Metrikstream.

In diesem Beispiel wird ein Metrikstream von einem Abwesenheitsalarm ausgewertet, der die standardmäßige zweistündige Abwesenheitserkennungsperiode und die standardmäßige Abwesenheitsdauer mit drei Minuten verwendet. In der Konsole werden die anfänglichen Übergangszustände "Feuern" (2:00) und "OK" (4:10) angezeigt. Die interne Rücksetzungsperiode tritt auf, während sich der Alarm im Auslösestatus befindet.

Beispiel für einen Abwesenheitsalarm mit einem einzelnen Metrikstream.

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

Zeit Status Übergang Ereignisse Benachrichtigungen (siehe Nachrichtentypen)
1:00 Uhr OK -- Emissionen erkannt werden.
2:00 Uhr FIRING FIRING Für Ressource z wird keine Emission festgestellt. Der Alarm startet die Abwesenheitserkennungsperiode für Ressource-z. OK_TO_FIRING
4:0 FIRING -- Die Abwesenheitserkennungsperiode für Ressource-z endet. Der Alarm startet den internen Rücksetzungszeitraum für Ressource-z. --
4:10 OK OK Die interne Rücksetzperiode endet für Ressource-z, sodass der Alarm nicht mehr auf Emissionen von Ressource-z prüft. Der Alarm überwacht keine Metrikstreams mehr, sodass der Alarm in den Status "OK" übergeht. RESET (nach der dreiminütigen Slack-Periode um etwa 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 Alarm in aufgeteilten Benachrichtigungen aktualisieren, kann es bis zu fünf Minuten dauern, bis der Metrikstreamstatus in der Konsole angezeigt wird.

Nachrichtentypen

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

Hinweis

Der angegebene Nachrichtentyp wird zum angegebenen Zeitpunkt zuzüglich der konfigurierten Triggerverzögerung des Alarms gesendet, sofern vorhanden.

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

In der folgenden Tabelle werden der Alarmstatus und der Übergang für jeden Nachrichtentyp aufgeführt.

Meldungstyp Status Ü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, prüfen Sie die Integrität der Ressource.

Dieser Nachrichtentyp wird gesendet, wenn der Alarm nach mindestens einem internen Zurücksetzen in den Status OK übergeht. Eine interne Rücksetzung erfolgt, wenn ein Metrikstream, der den Alarm in den Status FIRING versetzt hat, während des gesamten internen Rücksetzungszeitraums kontinuierlich fehlt. Ein Metrikstream, der intern zurückgesetzt wird, wird nicht mehr vom Alarm verfolgt.

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

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 eines Intervalls auf eine Auswahl von Rohdatenpunkten für eine Metrik. Beispiel: Sie können die Statistik max und das Intervall 1h (eine Stunde) auf die Raw-Datenpunkte 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 Grundlegenden 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 "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 Grundlegenden 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, welche die Statistik sum und das 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 zum Wählen einer Dimension für ein Metrikdiagramm oder eine Abfrage finden Sie unter Dimensionen zum Filtern von Metriken auswählen und Dimensionen 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.
Häufigkeit
Der Zeitraum zwischen jedem geposteten Rohdatenpunkt für eine Metrik. (Rohdatenpunkte werden vom Metrik-Namespace an den Monitoring-Service gepostet.) Während die Häufigkeit je nach Metrik variiert, weisen Standardservicemetriken im Allgemeinen eine Häufigkeit von 60 Sekunden auf (ein Datenpunkt wird pro Minute gepostet). Siehe auch Auflösung.
Intervall
Das Zeitfenster, in dem die Gruppe von Rohdatenpunkten konvertiert wird.
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 an. 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 ab (gilt nicht für Alarmabfragen). 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 in 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. Verwenden Sie Metadaten, um zusätzliche Informationen über eine Metrik zu bestimmen. Metrikdefinitionen finden Sie unter Unterstützte Services.
Metrik
Ein Maß für Zustand, Kapazität oder Performance einer Ressource. Beispiel: Die oci_computeagent Metrik CpuUtilization, die die Verwendung einer Compute-Instanz 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 metrischen Namespace für eine Metrik angegeben werden. Beispiel: Die oci_computeagent-Metrik DiskBytesRead wird durch Dimensionen (wie Ressourcen-ID) und Metadaten (Angabe von 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 dazu, wie Sie einen Metriknamen für einen Alarm auswählen, 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 CpuUtilization-Metrikdefinition, die von der Oracle Cloud Agent-Software auf Compute-Instanzen ausgegeben wird, listet den Metrik-Namespace oci_computeagent als Quelle der CpuUtilization-Metrik 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.
Informationen dazu, wie Sie einen Metrik-Namespace für einen Alarm auswählen, finden Sie unter Grundlegende Abfrage zum Generieren eines Alarmmetrikdiagramms erstellen und Grundlegenden Alarm erstellen.
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 (es sei denn, Sie aggregieren alle Metrikströme).
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 Wählen von Metrikstreams in einer Abfrage finden Sie unter Dimensionen zum Filtern von Metriken auswählen, Dimensionen für eine Abfrage auswählen und Dimensionen für eine Alarmabfrage auswählen.
Informationen zum Einrichten eines Alarms für Benachrichtigungen pro Metrikstream finden Sie unter Alarm erstellen, der Nachrichten nach Metrikstream aufteilt 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, die von einer Compute-Instanz verwendet wird, um Rohdatenpunkte an den Monitoring-Service zu posten. 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 für die Rückgabe aggregierter Daten ausgewertet werden sollen. 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, wodurch der maximale Zeitraum für die zurückgegebenen Daten festgelegt 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 5-Minuten-Fenster (aus dem Intervall) an. Das Ergebnis ist ein einzelner aggregierter Datenpunkt, der den höchsten CPUutilization-Zähler für dieses Fenster darstellt. 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 keine Auflösung 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, 1n bis 6:00 usw. ausgegeben werden.

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

Informationen zum Festlegen einer nicht standardmäßigen Auflösung, die vom Intervall unterscheidet, finden Sie unter Nicht standardmäßige Auflösung 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 der Rohdatenpunkte 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 der Veröffentlichung 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 zum Auswählen des Zeitraums für ein benutzerdefiniertes Metrikdiagramm oder eine benutzerdefinierte Abfrage finden Sie unter Zeitraum für Standardmetrikdiagramme ändern, Zeitraum für ein benutzerdefiniertes Metrikdiagramm ändern und Nicht standardmäßigen Zeitraum 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 die Metriken an das Monitoring ausgeben können:

Ressourcen-IDs

Die meisten Typen von Oracle Cloud Infrastructure-Ressourcen besitzen eine eindeutige, von Oracle zugewiesene ID, die als Oracle Cloud-ID (OCID) bezeichnet wird. Informationen zum OCID-Format und anderen Möglichkeiten zur Identifizierung der 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 Softwareentwicklungs-Kits und Befehlszeilenschnittstelle.

Konsole: Um über die Konsole auf Monitoring zuzugreifen, müssen Sie einen unterstützten Browser verwenden. Um zur Anmeldeseite der Konsole zu wechseln, öffnen Sie das Navigationsmenü oben auf dieser Seite, 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 lässt sich mit IAM zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) integrieren.

Ein Administrator in einer Organisation muss Gruppen , Compartments und Policys einrichten, die den Zugriffstyp sowie den Zugriff der Benutzer auf Services und Ressourcen steuern. Beispiel: Die Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und verwalten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen kann 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 sind (nicht ein Administrator), 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 Alarmbewertung hängt vom Alarmziel ab. Die Limits sind mit dem Oracle Cloud Infrastructure-Service verknüpft, der für das Ziel verwendet wird.

Monitoring verfolgt 200.000 Metrikströme 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 zur Sicherung von Monitoring, einschließlich Sicherheitsinformationen und Empfehlungen, finden Sie unter Monitoring sichern.