Benachrichtigungen mit Labels versehen

In diesem Dokument wird beschrieben, wie Sie Benachrichtigungen und Vorfälle verwalten können, indem Sie einer Benachrichtigungsrichtlinie benutzerdefinierte Labels hinzufügen. Da benutzerdefinierte Labels in Benachrichtigungen enthalten sind, enthält die Benachrichtigung Informationen, mit denen Sie Ihre Benachrichtigungen priorisieren können, wenn Sie die Wichtigkeit eines Vorfalls angeben.

Über Labels

Labels sind Schlüssel/Wert-Paare, die mit Zeitachsen, Benachrichtigungsrichtlinien und Vorfällen verknüpft sind. Es gibt Messwertlabels, Ressourcenlabels und benutzerdefinierte Labels. Messwert- und Ressourcenlabels enthalten bestimmte Informationen zum erfassten Messwert oder zu der Ressource, für die der Messwert geschrieben wird. Im Gegensatz dazu sind benutzerdefinierte Labels die von Ihnen erstellten Labels, die bedarfsgerechte Informationen erfassen.

Wenn Zeitachsendaten geschrieben werden, werden den Daten Labels hinzugefügt, mit denen Informationen zu diesen Daten aufgezeichnet werden. Die Labels einer Zeitachse können beispielsweise eine virtuelle Maschine (VM), eine Zone, ein Google Cloud-Projekt und einen Gerätetyp identifizieren.

Sie können Benachrichtigungsrichtlinien und Vorfällen Nutzerlabels hinzufügen:

• Ein Label für eine Benachrichtigungsrichtlinie hat einen statischen Wert. Ein Beispiel, wie Sie ein Label mit dem Wert von critical hinzufügen, finden Sie unter Statische Schweregrade erstellen.

  Sie können diese Labels einer Benachrichtigungsrichtlinie hinzufügen, wenn Sie die Google Cloud Console oder die Cloud Monitoring API verwenden. Weitere Informationen finden Sie in den folgenden Dokumenten:

  • Benachrichtigungsrichtlinien für Schwellenwerte erstellen
  • Benachrichtigungsrichtlinien über die API erstellen

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

• Bei einem Vorfall in einem Label kann der Wert dynamisch festgelegt werden. Das heißt, der Wert der Zeitachsendaten kann den Labelwert bestimmen. Ein Beispiel finden Sie unter Dynamisches Schweregrad mithilfe von Monitoring Query Language (MQL) erstellen.

  Sie können diese Labels definieren, wenn Sie die Bedingung einer Benachrichtigungsrichtlinie mit MQL angeben.

Labels in Benachrichtigungen ansehen

Die Labels einer Benachrichtigungsrichtlinie oder eines Vorfalls können Sie auf der Detailseite eines Vorfalls, auf der Detailseite einer Benachrichtigungsrichtlinie und in einigen Benachrichtigungen einsehen:

• In E-Mail-Benachrichtigungen werden die Labels, die Sie der Richtlinie hinzufügen, im Abschnitt Richtlinienlabels aufgeführt. Labels, die Sie einem Vorfall hinzufügen, werden im Abschnitt Messwertlabels aufgeführt.

• In PagerDuty, Webhooks und Pub/Sub-Benachrichtigungen sind die Labels, die Sie einer Benachrichtigungsrichtlinie oder einem Vorfall hinzufügen, in den JSON-Daten enthalten. Labels für Benachrichtigungsrichtlinien sind im Feld policy_user_labels der JSON-Struktur aufgeführt:

  "policy_user_labels": {
    "severity": "critical",
  }
  

  Vorfalllabels sind im Feld metric der JSON-Struktur enthalten:

  "metric": {
    "type" : "compute.googleapis.com/instance/cpu/utilization"
    "displayName": "CPU Utilization",
    "labels": {
      "instance_name": "some_instance_name",
      "severity": "critical"
    },
  }
  

  Wie bereits gezeigt, enthält das Feld metric einen Messwerttyp, den Anzeigenamen des Messwerts, die Messwertlabels und alle benutzerdefinierten Labels, die dem Vorfall hinzugefügt wurden.

Beispiel: Schweregrad eines Berichts mit Labels

Dieser Abschnitt enthält zwei Beispiele, die zeigen, wie Sie mithilfe von Labels Informationen in eine Benachrichtigung einbinden können.

Angenommen, Sie möchten benachrichtigt werden, wenn die CPU-Auslastung einer VM einen Grenzwert überschreitet, und Sie möchten die folgenden Schweregradinformationen hinzufügen:

• critical: Die CPU-Auslastung liegt bei mindestens 90%.
• warning: Die CPU-Auslastung liegt bei mindestens 80 %, aber unter 90%.
• info: Die CPU-Auslastung liegt bei mindestens 70 %, aber unter 80%.

Statische Schweregrade erstellen

Sie erstellen drei Benachrichtigungsrichtlinien. Sie konfigurieren für jede Richtlinie die Bedingung, die ausgelöst wird, wenn die CPU-Auslastung höher ist als der Grenzwert. Außerdem fügen Sie für jede Richtlinie ein Schweregrad-Label hinzu, dessen Wert den Grenzwert der Richtlinie bestimmt.

Sie erstellen drei Richtlinien, da Labels in Benachrichtigungsrichtlinien statische Werte haben. Deshalb müssen Sie für jeden Wert des Labels eine Richtlinie erstellen.

• Richtlinie A: Die Bedingung wird ausgelöst, wenn die CPU-Auslastung mindestens 90 % beträgt. Das Label severity ist auf critical gesetzt:

  "userLabels": {
     "severity": "critical",
  }
  

• Richtlinie B: Die Bedingung wird ausgelöst, wenn die CPU-Auslastung mindestens 80 % beträgt. Das Label severity ist auf warning gesetzt:

  "userLabels": {
     "severity": "warning",
  }
  

• Richtlinie C: Die Bedingung wird ausgelöst, wenn die CPU-Auslastung mindestens 70 % beträgt. Das Label severity ist auf info gesetzt:

  "userLabels": {
     "severity": "info",
  }
  

Wenn die CPU-Auslastung in diesem Beispiel 90 % überschreitet, erhalten Sie drei Benachrichtigungen, eine davon von jeder Richtlinie. Mit dem Wert des Labels severity können Sie bestimmen, welcher Vorfall zuerst untersucht werden soll.

Wenn die CPU-Auslastung auf einen Wert von weniger als 70 % sinkt, werden in Monitoring automatisch alle offenen Vorfälle geschlossen. Informationen zur Schließung von Vorfällen finden Sie unter Vorfälle schließen.

Dynamische Schweregrade mit MQL erstellen

Wenn Sie Labels für Vorfälle erstellen, können Sie eine Richtlinie verwenden und den Wert der Daten in der Benachrichtigung festlegen lassen. Sie müssen also nicht für jeden Wert des Labels eine andere Benachrichtigungsrichtlinie erstellen.

Hinweis: Wenn der Wert der Daten durch den Wert der Daten bestimmt wird, müssen Sie auch die Standardeinstellungen überschreiben, mit denen festgelegt wird, wie in Monitoring Vorfälle verwaltet werden, wenn keine Daten mehr eingehen. Diese Einstellungen werden im Abschnitt Best Practices dieses Dokuments beschrieben.

Hier ein Beispiel für die MQL-Abfrage, mit der ein Severity-Label hinzugefügt wird:

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

Die folgende Abbildung zeigt, wie MQL-Benachrichtigungsrichtlinien die Zeitachsendaten verarbeiten, die sie überwachen:

Der Richtlinien-Handler verarbeitet die Daten zur CPU-Auslastung und gibt eine Zeitachse aus, die angibt, wann die Bedingung ausgelöst wird. Im vorherigen Beispiel wird die Bedingung ausgelöst, wenn die CPU-Auslastung mindestens 70 % beträgt. Für jede Eingabezeitachse kann der Richtlinien-Handler eine von vier Zeitachsen generieren:

Name der Ausgabezeitachse	Bedingung ausgelöst	Beschreibung
Gut	Nein	Diese Zeitachse hat dieselben Labels wie die Eingabezeitachse. Sie hat kein Label für den Schweregrad.
„Kritisch“	Ja	Die CPU-Auslastung liegt bei mindestens 90%. Die Ausgabezeitachse hat dieselben Labels wie die Zeitachse „Gut“ plus ein Schweregrad-Label mit dem Wert „CRITTIC“.
„Warnung“	Ja	Die CPU-Auslastung liegt bei mindestens 80 %, aber unter 90%. Die Ausgabezeitachse hat dieselben Labels wie die Zeitachse „Gut“ sowie ein Schweregrad mit dem Wert „WARNUNG“.
„Info“	Ja	Die CPU-Auslastung liegt bei mindestens 70 %, aber unter 80%. Die Ausgabezeitachse hat dieselben Labels wie die Zeitachse „Gut“ plus ein Schweregrad-Label mit dem Wert „INFO“.

Die vom Richtlinien-Handler generierten Zeitachsendaten sind die Eingaben an den Incident Manager, der bestimmt, wann Vorfälle erstellt und geschlossen werden. Der Vorfallmanager ermittelt mit den Werten der Felder duration, evaluationMissingData und autoClose, wann ein Vorfall geschlossen werden soll.

Best Practices

Führen Sie die folgenden Schritte aus, damit beim Erstellen von Labels, deren Werte dynamisch festgelegt werden, maximal ein Vorfall geöffnet ist:

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

  • Feld „duration“: Wird auf einen Wert ungleich null gesetzt.
  • Feld evaluationMissingData: Legen Sie fest, dass Vorfälle geschlossen werden sollen, 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, setzen Sie das Feld auf „Fehlende Datenpunkte, die als Werte behandelt werden, die nicht gegen die Richtlinienbedingung verstoßen“.

• Legen Sie im Objekt AlertStrategy den Wert 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 Daten zu Teilmesswerten.

Vorfallfluss

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

1. Da die CPU-Auslastung weniger als 70 % beträgt, generiert der Richtlinien-Handler die Zeitachse „Gut“ und es werden keine Vorfälle geöffnet.

2. Angenommen, die CPU-Auslastung steigt auf 93 % an. Der Richtlinien-Handler generiert keine Zeitachsendaten vom Typ „Gut“ mehr, sondern generiert Daten für die Zeitachse „Kritisch“.

   Der Vorfallmanager sieht eine neue Zeitachse, die die Bedingung „Kritische“ auslöst, und erstellt einen Vorfall. Die Benachrichtigung enthält das Label „Schweregrad“ mit dem Wert CRITICAL.

3. Angenommen, die CPU-Auslastung sinkt auf 75%. Der Richtlinien-Handler generiert keine Zeitachsen vom Typ „Critical“ mehr, sondern generiert die Zeitachse „Info“.

   Der Vorfallmanager sieht eine neue Zeitachse, die die Bedingung, die Zeitachse "Info", auslöst und einen Vorfall öffnet. Die Benachrichtigung enthält das Label „Schweregrad“ mit dem Wert INFO.

   Der Vorfallmanager sieht, dass für die Zeitachse "Kritisch" keine Daten eingehen und dass für diese Zeitachse ein Vorfall offen ist. Da die Richtlinie so konfiguriert ist, dass Vorfälle geschlossen werden, wenn keine Daten mehr eingehen, schließt der Vorfallmanager den Vorfall, der der Zeitachse „Kritisch“ zugeordnet ist. Daher bleibt nur der Vorfall offen, dessen Schweregrad einen Wert von INFO hat.

4. Gehen Sie schließlich davon aus, dass die CPU-Auslastung auf 45 % sinkt. Dieser Wert ist niedriger als alle Grenzwerte, sodass der Richtlinien-Handler die Zeitachse „Info“ nicht mehr generiert und die Zeitachse „Gut“ generiert.

   Der Vorfallmanager sieht, dass für die Zeitachse "Info" keine Daten eingehen und für diese Zeitachse ein Vorfall offen ist. Da die Richtlinie die empfohlenen Einstellungen verwendet, ist der Vorfall geschlossen.

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

Nächste Schritte

• Benachrichtigungsrichtlinien mit der Monitoring API erstellen
• Benachrichtigungsrichtlinien mit MQL
• Umgang mit Messwertdaten