Um ein zuverlässiges System zu betreiben, muss man das messen, worauf es ankommt. Und zwar worauf es für das Unternehmen wie auch für die Fehlerbehebung ankommt. New Relic misst dies mit New Relic, genauer gesagt mit unseren Agents und unseren Produkten für Service-Level Objectives (SLOs) und Alerting.
APM Agents bei New Relic
Für ihre Services nutzen Engineering-Teams gern den APM Agent (Application Performance Monitoring), und die gesamte Hardware wird in der Regel mit dem New Relic Infrastructure Agent überwacht. Dadurch entsteht ein einheitlicher Satz von Health-Metriken, so dass Engineers auch beim Wechsel zwischen Teams oder Services stets wissen, worum es geht.
Die APM Agents von New Relic sind präzise darauf abgestimmt, die relevanten Metriken für die Erkennung und Diagnose von Serviceproblemen zu liefern. Zu den wichtigsten Metriken gehören HTTP-Antwortzeit, Datenbankaufrufzeiten und externe HTTP-Aufrufzeiten.
Zusätzlich fügen nicht nur dedizierte Agent-Teams unseren Agents häufig neue Instrumentierung hinzu: Auch andere Engineering-Teams, die die Agents zum Monitoring ihrer eigenen Infrastruktur, Datenbanken und Streamingdienste einsetzen, leisten ihren Instrumentierungsbeitrag. Ein gutes Beispiel ist die aktuelle Kafka-Instrumentierung im Java-Agent. Diese Instrumentierung wurde ursprünglich von einem New Relic Team erstellt, das viele essenzielle Kafka-Streamingdienste betreibt, und zwar zunächst als Java-Agent-Erweiterung. Nachdem diese Instrumentierung bei vielen internen Teams Anklang fand, wurde sie schließlich in das APM-Produkt integriert. Die Kafka-UI, die diese Metriken anzeigt, wurde ebenfalls gemeinsam von einem APM-Produktteam zusammen mit unseren Kafka- und Streamingdienst-Teams erstellt.
Effektive Instrumentierung
Dashboards und Nerdpacks vermeiden Kontextwechsel
Die Teams bei New Relic werden dazu angehalten, schon während der Entwicklung Observability-Daten zu berücksichtigen. Zusätzlich zur Standardinstrumentierung in unseren Agents haben Engineering-Teams die Möglichkeit, weitere Custom-Instrumentierung zu erstellen. Einige Teams senden ihre Custom-Instrumentierung über APM Agents an New Relic. Andere haben Bibliotheken erstellt, damit die Instrumentierung direkt an unsere öffentlichen Endpunkte für Metriken, Events, Logs und Traces gesendet wird. Beispiele für Custom-Instrumentierung sind ein New Relic Event für jede Abfrage der New Relic Datenbank (NRDB) sowie ein Event für jede Erstverbindung des APM Agent mit New Relic. Diese Custom-Events werden dann in Dashboards oder Custom-Nerdpacks (benutzerdefinierte Anwendungen) angezeigt, in denen Textanweisungen mit Live-Abfrageergebnissen und Visualisierungen kombiniert werden.
Zum Beispiel können Probleme mit Kafka-Pipeline-Stalls über Ansichten auf einem Custom-Nerdlet diagnostiziert werden, das zudem automatisch den erforderlichen Befehl generiert, um die Daten-Retention zu verlängern und einen mehrstufigen manuellen Prozess in einen einzigen Copy-Paste-Vorgang zu verwandeln. Dadurch werden mühselige Kontextwechsel deutlich reduziert und die Problembehebung wird beschleunigt.
Service-Level Objectives
Erreichen von Geschäftszielen mit SLOs
SLOs sind wichtig, da sie die Customer Experience über einen festgelegten Zeitraum definieren und messen. Um Arbeiten an der Zuverlässigkeit und neue Funktionen in Einklang zu bringen, sind sie unerlässlich. Bei New Relic wird heute von allen Teams erwartet, dass sie einen internen Satz an SLOs pflegen. Bevor dies im gesamten Unternehmen galt, war uns aufgefallen, dass unsere Telemetriedaten zwar sehr umfangreich waren, aber auf das Troubleshooting zugeschnitten waren – nicht auf die Bewertung der Customer Experience. Wir entwickelten also ein „Bar-Raiser“-Programm für SLOs, in dem Teams kundenorientierte SLOs mit Werten erstellen konnten, die die damalige Realität widerspiegelten.
Anhand dieser Messungen konnten wir die Betriebskosten, die durch Einhaltung der aktuellen SLOs anfielen, sowie die zum Erreichen höherer SLOs erforderlichen Arbeiten ermitteln und mit den Verantwortlichen im Unternehmen teilen. Teams, denen SLOs einen echten Nutzen gebracht haben, prüfen ihre eigenen SLOs täglich und ergreifen bei Bedarf Gegenmaßnahmen. Diese Teams konnten nicht nur ihre Customer Experience verbessern, sondern erhielten auch deutlich weniger Alarmrufe.
Alerting und Terraform
So automatisieren Sie proaktive Einblicke
Bei New Relic verwenden unsere Teams New Relic Alerting, um über Systemanomalien informiert zu werden. So können unsere Engineers schnell Maßnahmen ergreifen, um eine mögliche Systemverschlechterung im Rahmen zu halten. Die meisten Teams verwenden Terraform in der Versionskontrolle, um ihre Alerts zu erstellen und zu verwalten. Überwiegend werden zudem Facet-Alerts eingesetzt, um sicherzustellen, dass Alerts für jede neue Zelle oder Umgebung erstellt werden. Ein Beispiel für einen Facet-Alert für den Hostnamen sehen Sie hier:
SELECT latest(etcdServerProposalsFailedRate) FROM K8sEtcdSample WHERE clusterName = 'my-cluster' FACET hostname
Um sicherzustellen, dass Teams über die richtigen Alerts verfügen, umfassen unsere New Relic Engineering-Standards eine Reihe empfohlener Alerts für Teams. Dazu gehören Alerts zu OOM-Kills (Out of Memory), Warten auf Pods, Kafka Lag, Fehlerquoten und mehr. Auf ihren Dashboards können Führungskräfte die Alerts ihres Teams aufrufen, da jeder Alert in NRDB aufgezeichnet wird, und die Trends von Woche zu Woche nachverfolgen.