Best Practices für Ihre Alarme
Informieren Sie sich über Best Practices für Alarme.
Alarme für jede Metrik erstellen
Erstellen Sie Alarme für jede von Ressourcen ausgegebene Metrik, die das folgende Ressourcenverhalten definieren:
- Gefährdet. Die Ressource ist gefährdet und kann nicht ausgeführt werden, wie mit Metrikwerten angegeben.
- Nicht optimal Die Performance der Ressource ist nicht optimale, wie mit Metrikwerten angegeben.
- Die Ressource ist hoch- oder heruntergefahren. Die Ressource ist entweder nicht zugänglich oder wird nicht ausgeführt.
In folgenden Beispielen wird die Metrik CpuUtilization verwendet, die von dem Metrik-Namespace oci_computeagent ausgegeben wurde. Diese Metrik überwacht die Auslastung der Compute-Instanz und der Aktivitätsebene aller auf der Instanz ausgeführten Services und Anwendungen. CpuUtilization ist eine wichtige Performancemetrik für einen cloud service, da sie die CPU-Auslastung für die Compute-Instanz angibt und zur Untersuchung von Performanceproblemen verwendet werden kann. Weitere Informationen zur CPU-Auslastung finden Sie unter der folgenden URL: https://en.wikipedia.org/wiki/CPU_time.
Beispiel für gefährdeten Schwellenwert
Ein typischer gefährdeter Schwellenwert für die Metrik CpuUtilization ist ein beliebiger Wert über 80 Prozent. Eine Compute-Instanz, die diesen Schwellenwert überschreitet, ist möglicherweise nicht mehr funktionsfähig. Häufig sind die Ursache dieses Verhaltens eine oder mehrere Anwendungen, die einen hohen Prozentsatz der CPU belegen.
In diesem Beispiel beschließen Sie, das Vorgangsteam sofort zu benachrichtigen, und setzen den Schweregrad des Alarms auf "Kritisch", da eine Reparatur erforderlich ist, um die Instanzen wieder auf optimale Betriebsebenen zu bringen. Sie konfigurieren Alarmbenachrichtigungen für das verantwortliche Team sowohl über PagerDuty als auch über E-Mails, um eine Untersuchung und entsprechende Behebungsmaßnahmen anzufordern, bevor die Instanzen in einen nicht betriebsbereiten Status wechseln. Sie legen minütliche Wiederholungsbenachrichtigungen fest. Wenn jemand auf die Alarmbenachrichtigungen antwortet, stoppen Sie vorübergehend die Benachrichtigungen anhand der Best Practices zur Unterdrückung des Alarms . Wenn Metriken wieder zu optimalen Werten zurückkehren, entfernen Sie die Unterdrückung.
NonOptimal-Beispiel
Ein typischer, nicht optimaler Schwellenwert für die CpuUtilization-Metrik liegt von 60 bis 80 Prozent. Wenn die Metrikwerte für eine Compute-Instanz innerhalb dieses Bereichs liegen, überschreitet die Instanz den optimalen Betriebsbereich.
In diesem Beispiel entscheiden Sie, die entsprechende Person oder das Team darüber zu benachrichtigen, dass eine Anwendung oder ein Prozess mehr CPU als gewöhnlich belegt. Sie konfigurieren einen Schwellenwertalarm zur Benachrichtigung der entsprechenden Kontakte. Dabei wird der Schweregrad des Alarms auf "Warnung" gesetzt, da keine unmittelbaren Maßnahmen zur Untersuchung und Reduzierung der CPU erforderlich sind. Sie legen die Benachrichtigung auf "Nur E-Mail" an den entsprechenden Entwickler oder das Team fest. Das Wiederholungsintervall setzen Sie auf 24 Stunden, um die Anzahl der E-Mail-Benachrichtigung zu reduzieren.
Ressource ist hoch- oder heruntergefahrene Ressource - Beispiel
Ein typischer Indikator der Ressourcenverfügbarkeit ist das Fehlen der CpuUtilization-Metrik für fünf Minuten. Eine Compute-Instanz, die diesen Schwellenwert überschreitet, ist nicht zugänglich oder wird nicht ausgeführt. Die Ressource reagiert nicht länger, oder sie ist aufgrund von Konnektivitätsproblemen möglicherweise nicht verfügbar.
In diesem Beispiel entscheiden Sie, das Vorgangsteam sofort zu benachrichtigen und den Schweregrad des Abwesenheitsalarms auf "Kritisch" zu setzen, da die Instanzen erst durch Reparatur online gesetzt werden müssen. Sie konfigurieren Alarmbenachrichtigungen für das verantwortliche Team sowohl über PagerDuty als auch über E-Mail und fordern eine Untersuchung und eine Verschiebung der Workloads an eine andere verfügbare Ressource an. Sie legen minütliche Wiederholungsbenachrichtigungen fest. Wenn jemand auf die Alarmbenachrichtigungen antwortet, stoppen Sie vorübergehend Benachrichtigungen anhand der Best Practices zur Unterdrückung des Alarms. Wenn die CpuUtilization-Metrik erneut in der Ressource erkannt wird, entfernen Sie die Unterdrückung.
Manchmal möchten Sie benachrichtigt werden, wenn ein Ereignis eintritt, z. B. das Herunterfahren einer Datenbankinstanz. Stellen Sie in diesem Szenario Wiederholungsbenachrichtigungen auf null Minuten ein, um einen ereignisbasierten Alarm zu erstellen. Anweisungen finden Sie unter Ereignisbasierte Benachrichtigungen für einen Alarm abrufen.
Richtiges Alarmintervall für die Metrik auswählen
Wählen Sie ein Alarmintervall basierend auf der Häufigkeit, mit der die Metrik ausgegeben wird. Beispiel: Eine alle fünf Minuten ausgegebene Metrik erfordert ein Alarmintervall von mindestens 5 Minuten. Die meisten Metriken werden jede Minute ausgegeben, was bedeutet, dass die meisten Metriken jedes Alarmintervall unterstützen. Um gültige Alarmintervalle für eine spezifische Metrik zu bestimmen, prüfen Sie die Metrikreferenz des relevanten Service.
Alarme bei Untersuchungen unterdrücken
Sobald ein Teammitglied auf einen Alarm reagiert, unterdrücken Sie Benachrichtigungen, während das Problem untersucht oder behoben werden soll. Durch das vorübergehende Stoppen von Benachrichtigungen werden Ablenkungen während der Untersuchung und Fehlerbehebung vermieden. Entfernen Sie die Unterdrückung, wenn das Problem gelöst wurde. Anweisungen hierzu finden Sie unter Einzelnen Alarm unterdrücken und Mehrere Alarme unterdrücken.
Routinemäßig Ihre Alarme optimieren
Prüfen Sie regelmäßig, z.B. wöchentlich, die Alarme, um eine optimale Konfiguration sicherzustellen. Kalibrieren Sie den Schwellenwert, Schweregrad und die Benachrichtigungsdetails jedes Alarms, einschließlich Methode, Häufigkeit und Zielgruppe.
Die optimale Alarmkonfiguration umfasst die folgenden Faktoren:
- Kritikalität der Ressource.
- Angemessenes Ressourcenverhalten. Prüfen Sie das Verhalten einzeln und innerhalb des Kontextes des Serviceökosystems. Prüfen Sie die Schwankungen von Metrikwerten für einen gewissen Zeitraum, und passen Sie die Schwellenwerte dann nach Bedarf daran an.
- Annehmbare Anzahl von Benachrichtigungen. Prüfen Sie die Benachrichtigungsmethode (wie E-Mail oder PagerDuty), die entsprechenden Empfänger und die Häufigkeit der wiederholten Benachrichtigungen.
Die folgende Tabelle zeigt ein Beispiel für eine Alarmkalibrierung.
| CPU-Schwellenwert in % | Schweregrad | Benachrichtigungsmethode | Häufigkeit | Zielgruppe |
|---|---|---|---|---|
| >80% | Kritisch | PagerDuty + E-Mail | 1 Minute | Compute, Ops und Customer Communications |
| >60% und <80% | Warnung | Einmal täglich | Compute + Ops |
Anweisungen hierzu finden Sie unter Alarm aktualisieren.