Vorfälle mit Labels versehen

In diesem Dokument wird beschrieben, wie Sie Vorfälle mithilfe benutzerdefinierter Labels organisieren und priorisieren können. Diese Labels werden in Benachrichtigungsrichtlinien konfiguriert und in Benachrichtigungsrichtlinien und Vorfällen aufgeführt. Je nach Konfiguration werden die Labels auch in bestimmten Benachrichtigungen aufgeführt.

Über Labels

Labels sind Schlüssel/Wert-Paare, mit denen Informationen an eine Zeitreihe, eine Benachrichtigungsrichtlinie, einen Vorfall oder eine Benachrichtigung angehängt werden. Die Labels einer Zeitachse können beispielsweise die spezifische VM-Instanz identifizieren, aus der Daten erfasst wurden. Labels sind entweder benutzerdefiniert oder vordefiniert.

Benutzerdefinierte Labels

Benutzerdefinierte Labels enthalten von Ihnen festgelegte Informationen. Diese Labels können entweder statische oder dynamische Werte haben:

• Statische benutzerdefinierte Labels haben Werte, die nicht geändert werden können. Sie können statische benutzerdefinierte Labels erstellen, wenn Sie eine Benachrichtigungsrichtlinie über die Google Cloud Console oder die Cloud Monitoring API konfigurieren. Weitere Informationen finden Sie in folgenden Dokumenten:

  • Benachrichtigungsrichtlinien für Messwertgrenzwerte erstellen
  • Benachrichtigungsrichtlinien per API erstellen

• Dynamische benutzerdefinierte Labels haben Werte, die sich basierend auf Werten der Zeitreihendaten ändern können. Sie können dynamische benutzerdefinierte Labels erstellen, wenn Sie die Bedingung einer Benachrichtigungsrichtlinie mit MQL konfigurieren. Ein Beispiel finden Sie unter Beispiel: Benutzerdefinierte Labels mit dynamischen Werten hinzufügen.

Labelschlüssel müssen mit einem Kleinbuchstaben beginnen. Sowohl Labelschlüssel als auch Labelwerte dürfen nur Kleinbuchstaben, Ziffern, Unterstriche und Bindestriche enthalten.

Vordefinierte Labels

Vordefinierte Labels sind in Ressourcendeskriptoren enthalten. Diese Labels müssen ausgefüllt werden, wenn Zeitreihendaten geschrieben werden. Diese Labels geben Informationen zum erfassten Messwert oder zur Ressource an, in die der Messwert geschrieben wird. Die Labels auf einer Zeitachse können beispielsweise eine virtuelle Maschine (VM), eine Zone, ein Google Cloud-Projekt und einen Gerätetyp identifizieren. Wenn Monitoring anhand dieser Zeitachse einen Vorfall erstellt, übernimmt der Vorfall diese Labels.

Labels ansehen

Die Labels einer Benachrichtigungsrichtlinie oder eines Vorfalls finden Sie auf der Detailseite eines Vorfalls, der Detailseite einer Benachrichtigungsrichtlinie und in einigen Benachrichtigungen.

• Benachrichtigungsrichtlinien: Statische benutzerdefinierte Labels werden im Abschnitt Nutzerlabels aufgeführt. Dynamische benutzerdefinierte Labels und vordefinierte Labels sind nicht sichtbar.
• Vorfälle: Statische benutzerdefinierte Labels werden im Abschnitt Richtlinienlabels und dynamische benutzerdefinierte Labels im Abschnitt Messwertlabels aufgeführt. Vordefinierte Labels sind in den Abschnitten Überwachte Ressourcenlabels und Messwertlabels aufgeführt.

• Benachrichtigungen: Vordefinierte Labels und benutzerdefinierte Labels sind in den folgenden Benachrichtigungstypen aufgeführt:

  • E-Mail
  • Google Chat
  • PagerDuty
  • Pub/Sub
  • Webhook

Beispiel: Benutzerdefinierte Labels mit dynamischen Werten hinzufügen

Mit MQL können Sie ein Label so konfigurieren, dass sein Wert sich basierend auf Zeitreihendaten dynamisch ändert. Beispiel: Sie möchten, dass Ihre Vorfälle das Label criticality haben, dessen Wert sich abhängig vom Wert des Messwerts für die überwachte CPU-Auslastung ändert:

fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
    add[
      criticality:
        if(val() >= 90 '%', 'CRITICAL',
          if(val() >= 80 '%', 'WARNING',
            if(val() >= 70 '%', 'INFO', 'GOOD')))
    ]
| condition val() >= 70 '%'

Hinweis: Wenn der Wert der Daten den Wert des Labels bestimmt, müssen Sie auch die Standardeinstellungen überschreiben, die steuern, wie Monitoring Vorfälle handhabt, wenn keine Daten mehr eingehen. Diese Einstellungen werden im Abschnitt Best Practices dieses Dokuments beschrieben.

Die folgende Abbildung zeigt, wie Benachrichtigungsrichtlinien, die MQL-Abfragen verwenden, die von ihnen überwachten Zeitreihendaten verarbeiten:

Der Richtlinien-Handler verarbeitet die CPU-Auslastungsdaten und gibt eine Zeitachse aus, die anzeigt, wann die Bedingung erfüllt ist. Im vorherigen Beispiel ist die Bedingung erfüllt, wenn die CPU-Auslastung mindestens 70 % beträgt. Der Richtlinien-Handler kann für jede Eingabezeitachse eine von vier Zeitachsen generieren:

Name der Ausgabezeitreihe	Bedingung erfüllt	Beschreibung
„GUT“	Nein	Diese Zeitachse hat dieselben Labels wie die Eingabezeitachse. Sie hat kein Label für den Schweregrad.
„KRITISCH“	Yes	Die CPU-Auslastung beträgt mindestens 90%. Die Ausgabezeitachse hat die gleichen Labels wie die Zeitreihe „GUT“ sowie ein Wichtigkeitslabel mit dem Wert „KRITISCH“.
„WARNUNG“	Yes	Die CPU-Auslastung beträgt mindestens 80 %, aber weniger als 90%. Die Ausgabezeitachse hat die gleichen Labels wie die Zeitreihe „GUT“ sowie ein Wichtigkeitslabel mit dem Wert „WARNING“.
„INFO“	Yes	Die CPU-Auslastung beträgt mindestens 70 %, aber weniger als 80%. Die Ausgabezeitachse hat die gleichen Labels wie die Zeitreihe „GOOD“ sowie ein Wichtigkeitslabel mit dem Wert „INFO“.

Die vom Richtlinien-Handler generierten Zeitreihendaten werden in den Vorfallmanager eingegeben. Dieser bestimmt, wann Vorfälle erstellt und geschlossen werden. Um zu bestimmen, wann ein Vorfall geschlossen werden muss, verwendet der Vorfall Manager die Werte der Felder duration, evaluationMissingData und autoClose.

Best Practices

So sorgen Sie dafür, dass immer nur ein Vorfall geöffnet ist, wenn Sie Labels erstellen, deren Werte dynamisch festgelegt werden:

• Überschreiben Sie im Objekt MetricThreshold die Standardwerte für die folgenden Felder:

  • Feld duration: Legen Sie einen Wert ungleich null fest.
  • Feld evaluationMissingData: Legen Sie fest, dass Vorfälle geschlossen werden, wenn keine Daten mehr eingehen. Wenn Sie die Cloud Monitoring API verwenden, legen Sie dieses Feld auf EVALUATION_MISSING_DATA_INACTIVE fest. Wenn Sie die Google Cloud Console verwenden, legen Sie das Feld auf „Fehlende Datenpunkte, die als Werte behandelt werden, die nicht gegen die Richtlinienbedingung verstoßen“ fest.

• Legen Sie im Objekt AlertStrategy das Feld autoClose auf den Mindestwert von 30 Minuten fest. Wenn Sie die Cloud Monitoring API verwenden, legen Sie dieses Feld auf 30m fest.

Weitere Informationen finden Sie unter Teilmesswertdaten.

Ablauf eines Vorfalls

Angenommen, die Messungen der CPU-Auslastung liegen beim Erstellen der Benachrichtigungsrichtlinie unter 70 %. Die folgende Abfolge zeigt, wie Vorfälle geöffnet und geschlossen werden:

1. Da die Messungen der CPU-Auslastung unter 70 % liegen, generiert der Richtlinien-Handler die Zeitachse „GOOD“ und es werden keine Vorfälle geöffnet.

2. Nehmen wir als Nächstes an, dass die CPU-Auslastung auf 93 % steigt. Der Richtlinien-Handler beendet das Generieren der Zeitreihendaten „GUT“ und beginnt mit der Erzeugung von Daten für die Zeitachse „KRITISCH“.

   Der Vorfallmanager sieht eine neue Zeitachse vom Typ „KRITISCH“, die die Bedingung erfüllt, und erstellt dann einen Vorfall. Die Benachrichtigung enthält das Label für den Schweregrad mit dem Wert CRITICAL.

3. Angenommen, die CPU-Auslastung sinkt auf 75%. Der Richtlinien-Handler beendet das Generieren der Zeitachse „CRITICAL“ und beginnt mit der Erzeugung der Zeitachse „INFO“.

   Der Vorfallmanager sieht eine neue Zeitachse „INFO“, die die Bedingung erfüllt, und erstellt dann einen Vorfall. Die Benachrichtigung enthält das Label für den Schweregrad mit dem Wert INFO.

   Der Vorfallmanager sieht, dass für die Zeitachse „KRITIK“ keine Daten eingehen und dass ein Vorfall für diese Zeitreihe offen ist. Da die Richtlinie so konfiguriert ist, dass Vorfälle geschlossen werden, wenn keine Daten mehr ankommen, schließt der Vorfallsmanager den Vorfall, der mit der Zeitachse „KRITISCH“ verknüpft ist. Daher bleibt nur der Vorfall offen, dessen Schweregradlabel den Wert INFO hat.

4. Nehmen wir abschließend an, die CPU-Auslastung sinkt auf 45%. Dieser Wert ist kleiner als alle Schwellenwerte. Daher generiert der Richtlinien-Handler die Zeitachse „INFO“ nicht mehr und beginnt mit der Erzeugung der Zeitachse „GOOD“.

   Der Vorfallmanager sieht, dass für die Zeitachse „INFO“ keine Daten eingehen und dass ein Vorfall für diese Zeitreihe offen ist. Da die Richtlinie die empfohlenen Einstellungen verwendet, wird der Vorfall geschlossen.

Wenn Sie den empfohlenen Wert für das Feld evaluationMissingData nicht verwenden, werden offene Vorfälle nicht sofort geschlossen, wenn keine Daten mehr eingehen. Dies kann dazu führen, dass für dieselbe Eingabezeitachse mehrere offene Vorfälle angezeigt werden. Weitere Informationen finden Sie unter Teilmesswertdaten.

Nächste Schritte

• Benachrichtigungsrichtlinien mit der Monitoring API erstellen
• Benachrichtigungsrichtlinien mit MQL
• Mit partiellen Messwertdaten umgehen