Das Container-Fabric-Team, das für die Bereitstellung einer Self-Service-Kubernetes-Plattform für interne Engineering-Teams verantwortlich ist, nutzt New Relic ebenfalls zum Monitoring und Optimieren einer umfassenden Multicloud-Umgebung. Das Container-Fabric-Team, das für die Bereitstellung einer Self-Service-Kubernetes-Plattform für interne Engineering-Teams verantwortlich ist, nutzt New Relic ebenfalls zum Monitoring und Optimieren einer umfassenden Multicloud-Umgebung. Mit seinen Hunderten von Kubernetes-Clustern und Zehntausenden von Nodes bei großen Public-Cloud-Anbietern vertraut das Team auf New Relic für End-to-End-Transparenz, proaktive Problemlösung, Kostenoptimierung und Förderung der teamübergreifenden Zusammenarbeit. Zudem nutzt das Container-Fabric-Team New Relic für Observability – tief in die Kubernetes- und Multicloud-Operationen integriert.
Verwendete New Relic Features
- Infrastructure Agent: Wird auf allen Kubernetes-Nodes bereitgestellt, um Metriken auf Host- und Containerebene zu erfassen.
- Custom-Instrumentierung: Wird häufig verwendet, um bestimmte Metriken von Kubernetes-Controllern, Automatisierung, CoreDNS und sogar Linux-Betriebssystemdetails für detaillierte Einblicke zu erfassen.
- Cloud-Integrationen: Werden verwendet, um Metriken von den APIs der wichtigsten Public-Cloud-Anbieter abzurufen, liefern eine umfassende Übersicht der Cloudanbieterdienste sowie der internen Telemetrie.
- Dashboards und Query Builder: Unverzichtbar für die grafische Darstellung von Plattform-Health und Performance-Trends sowie für Ad-hoc-Datenexploration bei Incident-Untersuchungen.
- Alerting: Proaktive Alerts auf Basis der wichtigsten Health-Indikatoren der Plattform.
- Zentrale Data Platform: New Relic liefert einen gemeinsamen Datenkontext, sodass Datensilos beim Container-Fabric-Team und den von diesem Team unterstützten Anwendungs- und Entwicklungsteams kein Thema mehr sind.
Das Team konzentriert sich auf Health und Effizienz auf Plattformebene und verwendet daher folgende Leistungsindikatoren (KPIs):
- Kubernetes-Health
- Anzahl ungeplanter Pods
- Probleme im Zusammenhang mit der Workerknoten-Skalierung
- Pod-Zustände (z. B. „CrashLoopBackOff“)
- Kubernetes-API-Server-, Scheduler- und CoreDNS-Metriken
Kubernetes-Pod-Health
- Ressourcennutzung und Kostenoptimierung
- Erhebliche CPU-Auslastung bei Workern
- Leerlauf-CPU und Speicher für Nodes (für besseres Bin Packing und effizientere Ressourcennutzung)
- Cloud-Infrastruktur
- Virtual-Machine(VM)-Instanzmetriken (CPU, Arbeitsspeicher, Festplatten-E/A, Netzwerk)
- Kafka-Broker-Metriken (z. B. Replikationsfaktor, Netzwerkunterbrechungen)
- Monitoring der zugrunde liegenden Cloudanbieter-Services und ihrer Performance
Nachstehend sehen Sie einige der Resultate, die das Container-Fabric-Team dank New Relic erzielt:
- Erhöhte Verfügbarkeit und Zuverlässigkeit
- Proaktive Problembehebung: Durch kontinuierliche Beobachtung der Plattform kann das Team potenzielle Probleme identifizieren und angehen, bevor sie sich auf die Kundschaft auswirken.
- Schnellere Untersuchung und Behebung von Incidents: New Relic Dashboards, Custom-Instrumentierung und die Möglichkeit, Daten über verschiedene Ebenen hinweg zu korrelieren, von Anwendungen und Services über Kubernetes-Ebenen (Pods, Nodes) bis hin zur grundlegenden Cloud-Infrastruktur, sorgen für eine deutlich verkürzte mittlere Zeit bis zur Behebung (MTTR). Als das Browserteam beispielsweise ein Problem mit dem Frontend meldete, konnte das Container-Fabric-Team das Problem mit ungeplanten Pods in Verbindung bringen und es schnell auf einen Istio-Kontrollebenen-Alert zurückführen. Durch Skalieren von Istio-Pods ließ sich das Problem dann beheben.
- Ermitteln externer Abhängigkeiten: Dank der detaillierten Telemetrie konnte das Team ein Netzwerkproblem auf den Speicherservern eines Cloudanbieters als Grundursache für bestimmte Leistungsspitzen identifizieren, obgleich erste Untersuchungen auf etwas anderes hinzudeuten schienen. Diese umfassende Visibility in Cloudservices von Drittanbietern ist entscheidend für die Aufrechterhaltung der Plattformzuverlässigkeit.
- Deutliche Kostenoptimierung
- Datengestützte Instanzauswahl: Durch Performance-Benchmarking anhand von New Relic Daten kann das Team die Kosteneffizienz und Performance verschiedener Instanztypen und Cloudanbieter vergleichen und so die für ihre Workloads finanziell optimale Infrastruktur auswählen.
- Verbesserte Ressourcennutzung: Durch Überwachung von CPU und Arbeitsspeicher im Leerlauf kann das Team proaktiv Möglichkeiten zur Optimierung des Bin Packing von Services auf Nodes finden. Das verbessert die Ressourcennutzung und senkt die Cloudkosten und ermöglicht auch die Herunterskalierung von nicht ausgelasteten Nodes.
- Effektive teamübergreifende Zusammenarbeit
- Frei verfügbarer Observability-Kontext: New Relic ist die zentrale Sprache und Datenquelle für interne Teams. Dank der gemeinsamen Nutzung von Dashboards und NRQL-Abfragen kann Kontext leichter geteilt werden, was wiederum Reibungsverluste beim Troubleshooting von Incidents verringert. Teams arbeiten effektiv zusammen und lokalisieren sowie beheben Probleme gemeinsam.
- Bidirektionaler Wissenstransfer: Da die Daten gemeinsam genutzt und Probleme ebenfalls kollaborativ angegangen werden, können sich Teams leichter über Arbeitslast und Funktionen anderer Teams informieren. Und das kommt den Best Practices im Engineering zugute.
Self-Service für interne Kund:innen
Das Container-Fabric-Team stellt internen Entwicklungsteams die notwendigen Tools und Daten in New Relic zur Verfügung, damit sie ihre eigenen Services auf Anwendungsebene überwachen können. Während sich das Plattformteam auf die Infrastruktur-Health konzentriert, können die Anwendungsteams sich selbstständig um ihre Observability-Anforderungen kümmern. Dadurch sinkt die Abhängigkeit vom Plattformteam beim Routine-Monitoring der Services.
Fundierte strategische Entscheidungsfindung
New Relic unterstützt nicht nur die Incident-Behebung, sondern liefert auch die granularen Performance- und Kostendaten aus der Praxis, die für langfristige strategische Entscheidungen erforderlich sind – ganz gleich, ob es darum geht, den Cloud-Footprint zu erweitern, Cloudanbieter zu vergleichen oder die Multicloud-Strategie zu optimieren.