So verbessert IGS sein Monitoring und senkt gleichzeitig die Kosten

Als Head of Platform Engineering bei IGS kümmere ich mich um die Frage, wie wir Entwickler:innen in die Lage versetzen können, mithilfe von Tools, Infrastruktur und durchgängigen Prozessen von der Entwicklung bis zum Endprodukt einen geschäftlichen Mehrwert zu erzielen, ohne den täglichen Aufwand für Monitoring und Fehlerbehebung zu haben. Da es sich bei dem Produkt von IGS um vertikale Anbautürme mit vielen verschiedenen Pflanzen handelt, benötigen wir ein hohes Maß an Zuverlässigkeit. Ausfälle können dazu führen, dass die Pflanzen eingehen. Außerdem sind wir ein relativ kleines Unternehmen. Daher brauchen wir diese Einblicke in die Zuverlässigkeit des Systems, insbesondere wenn wir größere Datenmengen verarbeiten und visualisieren und dabei die Kosten unter Kontrolle halten müssen.

Als ich bei IGS anfing, haben wir Application Insights als nativen Teil von Microsoft Azure verwendet, aber da wir Kubernetes intensiv nutzen, ließ sich das nicht gut mit der Menge der von uns erfassten Daten vereinbaren. Anfangs haben wir uns Open-Source-Lösungen angesehen, aber wir hatten dafür nur drei Leute im Team, und das zu verwalten wäre zu einem Vollzeitjob geworden. Als wir uns also nach SaaS-Lösungen umsahen, war uns die Einhaltung offener Standards wichtig, damit wir beim Monitoring mit Logging und Tracing arbeiten können. Zudem wünschten wir uns eine Kubernetes-native Lösung, da dies zu unserem Ziel für die universelle Rechenlaufzeit passte. Einige Faktoren führten uns zu New Relic.

Monitoring mit Kubernetes

Wir nutzen Kubernetes sehr intensiv und sind in der eBPF-Community aktiv. Die Art und Weise, wie New Relic auf Open Source setzt, zum Beispiel bei OpenTelemetry oder seinen Integrationen mit Prometheus, machte es für uns zum idealen Allrounder. Als New Relic dann Pixie übernahm, weckte das unsere Aufmerksamkeit. Es ist ein sehr Kubernetes-nativer Ansatz für das Monitoring mit einer entwicklerzentrierten Ansicht der Traces. Genau das fehlte uns nämlich, wenn es um Einblicke in Anwendungen ging: einfach zu erfassendes End-to-End-Tracing. 

Rasche Instrumentierung

Die Instrumentierungsphase war wirklich einfach. Wir hatten uns darauf eingestellt, dass es recht mühsam sein würde, den Code manuell zu instrumentieren. Doch dann stellte sich heraus, dass wir für etwa 90 % unserer Aufgaben lediglich den APM-Agent in den Container einfügen mussten. Mehr nicht. Für spezialisiertere Librarys war ein bisschen Custom-Instrumentierung nötig, aber das war im Nu erledigt. Ebenso bei den Logs. New Relic setzt relativ standardmäßige Ansätze für das Erfassen von Logs in einer bestimmten Sprache ein. Wir haben einfach unser bestehendes Logging-Setup verwendet und dann eine zusätzliche Zeile für New Relic hinzugefügt. Die gesamte Instrumentierung war in gut eineinhalb Tagen abgeschlossen.

Niedrigere Kosten und weniger Personalaufwand

New Relic hatte auch einen großen positiven Einfluss auf unser Budget und unsere monatlichen Ausgaben. Unsere Ausgaben sind um 58 % zurückgegangen. Das hat eine Menge Ressourcen freigesetzt und ist direkt in das Mehrwertversprechen für unsere Kund:innen eingeflossen. Auch die mittlere Wiederherstellungszeit (MTTR) hat sich um 80 % verbessert. Wir können feststellen, was im Code passiert ist und wie sich das an anderer Stelle auswirkt. Unser Monitoring ist proaktiv, sodass wir Probleme verhindern können, bevor sie überhaupt auftreten. Wir sehen, wo sich die Performance verschlechtert oder die Fehleranzahl erhöht hat, was auf eine zugrunde liegende Instabilität hinweisen könnte. Die Skalierung unsere Monitorings ist überhaupt kein Problem mehr. Wir können uns jetzt auf die Bereiche konzentrieren, die für unsere Kund:innen und unser Entwicklungsteam wichtig sind, anstatt Mitarbeiter:innen mit dem Monitoring zu beschäftigen.

Neue Features sind in wenigen Tagen programmiert

Dank des funktionsreichen Integrationssystems von New Relic konnten wir auch unsere Produktionsabläufe straffen. Wir arbeiten mit Flagger, einem in New Relic integrierten Tool, das als Quality Gate fungiert. Damit haben wir einen ringförmigen Bereitstellungsansatz, bei dem der Übergang zwischen den einzelnen Ringen auf echten Monitoringdaten basiert. Auf diese Weise können wir die automatische Instrumentierung von New Relic mit unseren Service-Health-Checks und den New Relic Workloads nutzen und haben ein hohes Maß an Vertrauen in unsere Prozesse rund um Feature-Releases, ohne dass wir eigene Tools entwickeln müssen. Dank dieses optimierten Ansatzes konnten wir die Zeit, die ein Feature von der ersten Codezeile bis zum Einsatz bei unseren Kund:innen benötigt, von durchschnittlich 22 Tagen auf 4 Tage reduzieren.

Logs in Context

Wir nutzen mehrere Umgebungen mit vielen Microservices und vielen verschiedenen Systemen, die Logs erzeugen. In der Vergangenheit wurden die Logs direkt vom Pod abgerufen. Es gab keinerlei Beziehung zwischen der Funktionalität, dem Teil des Unternehmens, das den Service nutzte, der Sichtweise der Entwickler:innen und der Sichtweise der Infrastruktur bezüglich des Loggings. Es gab Logs und Traces – oder eben Logs, die zu einem Service gehörten. Es gab aber keine Verbindung dazwischen. Für das Log-Management hatten wir ein internes Wiki mit Hunderten von Abfragen. Wenn man etwas nachschlagen wollte, musste man ins Wiki gehen, die entsprechende Abfrage suchen und hoffen, dass sie funktionierte. Und wenn nicht, musste man versuchen, sie zu ändern. Herauszufinden, ob jemand bereits eine Lösung gefunden hatte, war ein langwieriger Prozess. 

Aufgrund unserer verteilten Umgebung arbeiten wir sehr intensiv mit Logs. Ein großer Vorteil von New Relic sind die Logs in Context. Jetzt können wir ein Log mit einem einzelnen Trace verknüpfen und alles zusammen in einer einzigen Ansicht sehen: hier ein Service, hier das, wovon er abhängig ist, und hier die ausgegebenen Logs. In New Relic sehen wir, um welchen Service es sich handelt und wie er mit dem Rest unserer Infrastruktur verbunden ist. Dann können wir die Logs für diesen Service im Kontext seiner Interaktion mit den anderen Services in unserer Infrastruktur betrachten – das macht das Ganze so erfolgreich. Jetzt können wir die Anwendungsansicht aufrufen und von dort aus die Logs einsehen. Das sind nur ein paar Klicks, was den Aufwand erheblich reduziert.

Alerts für mehr Produktivität

Wir haben unsere Alerts so eingestellt, dass sie direkt an unseren Microsoft Teams-Kanal gesendet werden. In New Relic können Alerts geteilt werden. Das ist nur eine kleine Funktion, die aber viel bringt. Jede Seite hat eine Schaltfläche zum Teilen. Wenn wir zum Beispiel einen bestimmten Trace haben, können wir einfach den Link samt Zeitfenster des Traces kopieren und im Chat teilen. Anstatt Zeit mit Meetings zu verschwenden, bei denen jemand bestimmte Daten laden und dann versuchen muss, seine Abfrage zu reproduzieren, um sie mit anderen zu teilen, können wir diese Daten jetzt in ein paar Sekunden teilen. 

Automatisierung mit Terraform

New Relic verfügt über eine funktionsreiche API mit einem wirklich guten Terraform-Anbieter. IGS hat viele dynamische Umgebungen. Für jede Code-Änderung erstellen wir eine. Die Möglichkeit, mit Terraform Dashboards und Workload-Ansichten zu erstellen und alle Anpassungen oder Alerts hinzuzufügen, die wir für eine bestimmte Umgebung benötigen, bedeutet, dass wir diese Alerts in die Codeprüfung einbeziehen können. Dass wir die gleiche Technologie in den gleichen Sprachen verwenden, ist ein großer Vorteil. Wir können den Infrastrukturcode dafür genauso programmieren wie für alles andere auch. Dann können wir das für jede Umgebung einzeln bereitstellen. Wir haben damit einen standardisierten Arbeitsablauf geschaffen, sowohl für die Softwareentwicklung als auch für die Website.