New Relic Infrastructure 360 kartiert Cloud-Abhängigkeiten und Konfigurationsänderungen, um die MTTR zu senken

Vom CPU-Alarm zur verursachenden Änderung

New Relic argumentiert, dass klassisches Infrastruktur-Monitoring, das meist nur meldet, dass ein Host degradiert oder ein CPU-Schwellenwert überschritten wurde, den Einsatzteams den Gesamtüberblick vorenthält. Dem Unternehmen zufolge gehen die Hälfte aller größeren Produktionsausfälle direkt auf nicht erfasste Infrastrukturänderungen zurück. Zudem brauchten Engineers einen Blick auf nachgelagerte Abhängigkeiten, um die geschäftlichen Auswirkungen für Kunden einschätzen zu können.

Das Beispiel des Unternehmens: Ein automatisiertes Deployment ändert um 2:00 Uhr nachts eine Regel am Azure Application Gateway, und bei nachgelagerten Kubernetes-Microservices treten Latenzspitzen auf. Laut New Relic korreliert Infrastructure 360 den Latenzalarm auf der APM-Entity-Seite mit dem exakten Konfigurationsunterschied am Gateway. SREs müssen so nicht raten, welches Team mit seinem Deploy die Anwendung beeinträchtigt hat.

Drei Stufen der Diagnosetiefe

New Relic beschreibt einen schrittweisen Triage-Ablauf in drei Stufen:

• Surface Health and Alert Context: Den grundlegenden Zustand von Entities, den Ressourcenverbrauch und aktive Alarmbedingungen über eine Multi-Cloud-Umgebung hinweg prüfen.
• Automated Dependency and Blast Radius Mapping: Nachvollziehen, wie eine ausfallende Komponente mit vorgelagerten Application Gateways, Load Balancern und nachgelagerten Microservices verbunden ist.
• Configuration Change Impact Analysis: Konfigurationsänderungen auf Property-Ebene sichtbar machen, die vor der Anomalie vorgenommen wurden, und sie mit Einbrüchen der Anwendungsleistung verknüpfen.

Das Produkt setzt in einem zweistufigen Modell auf der bestehenden Plattform auf. Die Basisebene, Core Infrastructure Observability, deckt den grundlegenden Zustand und die Ursachenanalyse bei Standardalarmen ab. Infrastructure 360 liefert zusätzlich Antworten darauf, was tatsächlich läuft, wie Komponenten miteinander verbunden sind, wo Lücken in der Instrumentierung blinde Flecken erzeugen und wie sich jüngste Konfigurationsänderungen auf Zuverlässigkeit und Performance ausgewirkt haben.

Topologie über AWS, Azure und Kubernetes

Nach Angaben von New Relic verschafft Infrastructure 360 Platform Engineers, SREs und Entwicklern eine automatisierte Sichtlinie über hybride, Multi-Region- und Multi-Cloud-Landschaften hinweg, einschließlich Kubernetes-Umgebungen wie Amazon EKS und Azure AKS. Die Topologie reicht vom AWS Application Load Balancer (ALB) und von Azure Application Gateways über Kubernetes-Ingress-Controller und Container bis hinunter zu einzelnen APM-Microservices. Dem stellt das Unternehmen eine typische APM-Übersichtsseite gegenüber, deren Sichtbarkeit meist auf einfache Datenbank- oder Host-Verbindungen beschränkt ist.

Das Produkt bietet eine eigene aggregierte Startseite, die aktive Alarme, Inventare von Cloud-Ressourcen und ebenenübergreifende Beziehungen zeigt, und zwar durch die Brillen Zuverlässigkeit, Kosten und Sicherheit. Engineers können für die übliche Fehlersuche vertraute Workflows nutzen und anschließend in die Oberfläche von Infrastructure 360 wechseln, um Beziehungen genauer zu kartieren. Abhängigkeitskarten und Erkenntnisse zu Cloud-Konfigurationsänderungen sind zudem direkt in den einzelnen Entity-Seiten eingebettet, etwa bei APM-Services, Infrastrukturressourcen und Katalogansichten.

Beim Onboarding legt Infrastructure 360 laut New Relic einen einheitlichen Geltungsbereich über alle Cloud-Anbieter hinweg fest und vereinfacht die Kontoanbindung auf Organisationsebene. Das Unternehmen nennt außerdem eine agentenlose Erkennung von AWS- und Azure-Assets, die nach eigenen Angaben unüberwachte Schatten-IT beseitigen hilft und Teams dazu anhält, Lücken in der Instrumentierung zu schließen.

Konfigurationskontext und KI-Tauglichkeit

Der Configuration Explorer ermöglicht eine Analyse von Konfigurationsänderungen auf Property-Ebene und korreliert sie mit Leistungseinbrüchen. New Relic erklärt zudem, die von Infrastructure 360 gelieferten Topologiekarten und der Änderungskontext sollen New Relic Autopilot für die automatisierte Fehlerbehebung speisen.

New Relic CTO Michael Frendo ordnete das Produkt in die Strategie der einen zentralen Datenbank des Unternehmens ein. „Im Gegensatz zu herkömmlichen Monitoring-Plattformen, die Engineers zwingen, Hostdaten aus fragmentierten Produktsilos zusammenzusetzen, bündelt New Relic Infrastruktur, Anwendungen und Logs in einer einzigen, einheitlichen Datenbank“, sagte er laut dem Blogbeitrag des Unternehmens.

Was das für Betriebsteams bedeutet

Für SREs und Platform-Teams, die über mehrere Clouds hinweg arbeiten, besteht das Versprechen darin, bei einem Ausfall weniger zwischen Tools wechseln zu müssen und schneller zu erfahren, was sich geändert hat und was sonst noch betroffen ist. Diese Vorteile sind Eigenangaben von New Relic. Preise, Verfügbarkeitsdetails oder gemessene MTTR-Ergebnisse nennt die Quelle nicht.