Alerts spielen bei der Gestaltung einer hochwertigen UX eine entscheidende Rolle. Schließlich helfen sie, Probleme zu identifizieren und zu adressieren, bevor sie sich auf Ihre Kund:innen auswirken können. Doch auch hier gilt wie so oft die klassische Maxime aus dem Titel unseres Artikels: Qualität vor Quantität. Zu viele redundante Alerts arten leicht in wahre Informationsfluten aus. In der Summe sind die Alerts dann plötzlich kontraproduktiv: Sie helfen nicht mehr weiter, sondern stiften Verwirrung, legen einen Schleier über tatsächlich relevante Informationen und sind damit sogar der Behebung von Incidents hinderlich, statt sie im Sinne ihres Erfinders zu beschleunigen. Daher ist eine präzise abgestimmte Alert-Strategie auch wichtige Tragsäule für erfolgreiche Observability. Alerts mit Feinabstimmung fungieren als wirksame Wegweiser durch komplexe Infrastrukturen und Prozessketten, bringen Ihr Team zur richtigen Zeit an die richtige Stelle – und sorgen so auch ganz direkt für bessere Uptime, Verfügbarkeit und Performance. Dabei steht Ihnen mit Alert Quality Management (AQM) eine eigene Methodik zur Verfügung. Mit ihr gestalten Sie eine Alert-Strategie, die zwar weniger, aber für sich wie auch in der Summe hochwertigere Alerts liefert, den Scheinwerfer rascher auf Incidents richtet und Störfaktoren durch Alert-Rauschen signifikant verringert.
Bevor Sie sich dieser Feinabstimmung Ihrer Strategie widmen, empfehlen wir vorab unsere Best Practices zu den Themenpunkten Problemanalyse, Alerts, Incidents und Anomalien.
1. Ihr Business, Ihre Alerts
Ganz grundlegend gilt für Alerts in New Relic: Wenn etwas instrumentierbar ist, lassen sich dafür auch nahtlos Alert Policies definieren. Ob dies Sinn ergibt, steht dann bei jedem Element aber immer noch auf einem anderen Blatt, und so sollten Sie Ihre Alert-Bedingungen insgesamt mit Bedacht wählen, damit Ihr Team letztlich nicht von einer wahren Alert-Schwemme überrollt wird. Sind beispielsweise keine Kund:innen von einem nachts auftretenden Problem betroffen, kann seine Lösung dann nicht vielleicht bis zum nächsten Morgen warten?
Nicht umsonst gehen mit einem hohen operativen Reifegrad in Fachabteilungen häufig auch tendenziell weniger denn mehr Alerts einher, die auf Kern-Metrics mit Relevanz für das Kundenerlebnis basieren. Der Fokus liegt häufig etwa auf Metrics für Service-Level Management (SLM) wie Reaktionszeiten und Fehlerraten.
2. Automatische Anomalie-Erkennung
Bei Anomalien handelt es sich um Verhaltenstrends in einem System, die nicht zu bestehenden Schemata und Beobachtungen passen. Die Anomalie-Erkennung in New Relic benachrichtigt Sie in diesem Zusammenhang automatisch über Probleme, die Ihrer Aufmerksamkeit bedürfen: Mit dieser Komponente unseres AIOps Feature Set werden ungewöhnliche Verhaltensmuster in allen Anwendungen, Services und Log-Daten identifiziert. Diese automatischen Alerts basieren auf goldenen Signalen wie Throughput, Fehlern und Latenz.
3. Benachrichtigungs-Workflows: Ihre internen Experten zur rechten Zeit am rechten Ort
Bedarf ein System Aufmerksamkeit, können Sie den Blick der richtigen Mitarbeiter:innen rasch darauf lenken – mit automatischen Alerts an Slack Channels, via E-Mail oder über andere Plattformen wie Atlassian Jira, ServiceNow oder PagerDuty. Alternativ lassen sich Ihre Daten über Webhooks an jeden beliebigen externen Service übermitteln („Destinations“ in New Relic). Alle aktuell unterstützten Destination-Plattformen finden Sie hier.
Um einer Überinformation Ihrer Teams in Form von Alert-Rauschen vorzubeugen, wählen Sie Kanäle und Timing für Ihre Alerts mit Bedacht. Sollte Ihr Team wirklich bei jedem Auftreten eines Problems benachrichtigt werden? Wäre es ggf. sinnvoll, ähnliche Alerts in einer Benachrichtigung zusammenzufassen? Sollten alle Team-Mitglieder die Alerts erhalten oder nur bestimmte Mitarbeiter:innen?
Mit Workflows in New Relic steuern Sie genau, wann und wo Probleme im System mit einem Alert versehen werden sollen. Dabei lässt sich etwa festlegen, in welchen Fällen eine Übermittlung an eine Destination erfolgen soll. Ebenso können für einzelne Probleme und betroffene Services sowie weitere Parameter spezifische Empfänger und Rollen ausgewählt werden.
4. Alert-Metrics definieren und tracken
Alerts informieren die Empfänger rasch, wenn etwas ihrer Aufmerksamkeit bedarf. Doch zu viel des Guten ist auch hier nicht wünschenswert. Werden Alerts zu häufig ausgelöst, schlagen die Thresholds zu rasch an oder sind einige Alerts schlicht nicht relevant, kommt es schnell zu einer wahren Schwemme nicht relevanter Meldungen.
Konsistentes Tracking von Metrics hilft, die Aussagekraft Ihrer Alerts und der ihnen zugehörigen Methodik auf einem hohen Niveau zu halten. Ziel muss es sein, mit entsprechenden KPIs die Alerts herauszufiltern, die für das meiste Rauschen bzw. den geringsten Mehrwert sorgen, um ihre Feinabstimmung zu optimieren oder sie unter Umständen ganz zu eliminieren. So lassen sich etwa über Ihre AQM-Daten Metrics prüfen und Anpassungen an Alert Policies vornehmen.
Nächste Schritte
- Lesen Sie unseren Blog: 4 Best Practices für operative Effizienz
- Mehr zum Thema KPIs lesen Sie in unserem Implementation Guide zu Uptime, Performance und Stabilität.
- Wie Sie einen Alert Webhook und ein Dashboard erstellen, erfahren Sie auf unserer Seite zu Alert Quality Management auf GitHub.
- Hier können Sie sich für ein New Relic Konto registrieren. Das Einstiegskonto ist komplett kostenlos – dies mit 100 GB zur Datenerfassung, einer Komplettlizenz und unbegrenzten Basic-Lizenzen.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.