Umfassende Einführung in Kubernetes-Monitoring mit New Relic

Einführung

Vor Kubernetes fielen bei Planung, Deployment und Verwaltung von containerisierten Anwendungen zahlreiche manuelle Aufgaben an. Diese zu bewältigen kostete Cluster-Administratoren, DevOps-Engineers, Anwendungsentwickler und Operations-Teams nicht gerade wenig Zeit. Kubernetes als Plattform zur Container-Orchestrierung hat viele dieser Aufgaben grundlegend verändert.

So sind Deployment und Betrieb von Anwendungen in einer Microservice-Architektur mit Kubernetes optimiert möglich. Dabei wird zum Anwendungs-Deployment ein Abstraktions-Layer über mehrere Hosts gelegt. Via Kubernetes werden hier folgende Aspekte verwaltet:

• Steuerung der Ressourcenauslastung nach Anwendung oder Team

• Gleichmäßige Verteilung des Applikations-Load über die Host-Infrastruktur

• Automatisches Load Balancing für Anfragen über verschiedene Anwendungsinstanzen hinweg

• Überwachung der Ressourcenauslastung und -limits mit Neustart von Anwendungen bei übermäßiger Nutzung

• Verschiebung einer Anwendungsinstanz zu einem anderen Host bei Ressourcenmangel oder Host-Ausfall

• Automatische Nutzung zusätzlicher Ressourcen bei Verfügbarkeit durch Cluster-Erweiterung um einen Host

• Rasche Canary Deployments und Rollbacks

Neue Möglichkeiten bringen jedoch auch neue Herausforderungen mit sich. Beispielsweise:

• Eine Vielzahl zusätzlicher Layer muss überwacht werden.

• Seine dynamische Struktur und die konstanten Änderungen machen die Fehlerbehebung in Kubernetes sehr komplex.

• Die automatische Planung von Pods kann zu Kapazitätsproblemen führen, insbesondere wenn die Ressourcen-Verfügbarkeit nicht überwacht wird.

• Bis vor kurzer Zeit noch war Monitoring auch gleichbedeutend mit der Umsetzung von entsprechenden Unternehmens-Guidelines, der Installation von Language Agents, Instrumentierung von Anwendungs-Code und dem Replatforming jeder Anwendung.

Kubernetes löst zwar viele altbekannte Probleme, sorgt aber auch für neue. Besonders bei der Einführung von Containern und ihrer Orchestrierung müssen Monitoring-Strategien überdacht und angepasst werden. Nur so können die neuen Infrastruktur-Layer einer verteilten Kubernetes-Umgebung entsprechend operativ eingepasst werden. 

Anforderungen und Ansätze möchten wir mit diesem Leitfaden erläutern und dabei die Grundlagen von effektivem Monitoring für Kubernetes-Deployments mit New Relic und unserer neuesten Tech-Innovation Auto-telemetry with Pixie herausarbeiten. Auto-telemetry with Pixie liefert sofortige Kubernetes-Observability ohne manuellen Instrumentierungsaufwand oder Installation von Language Agents. Besprechen werden wir zum einen Best Practices für Kubernetes-Monitoring generell, weiterführend bieten wir zudem detaillierte Hinweise zur Umsetzung mit der New Relic Plattform.

Ob Cluster-Administrator, Anwendungsentwickler, Infrastruktur-Engineer oder DevOps-Experte – zum Ende dieses Leitfadens werden Sie mit New Relic und Auto-telemetry with Pixie Kubernetes-Observability umsetzen können. Als Konsequenz werden Sie den Health-Status und die Kapazität Ihrer Kubernetes-Komponenten und -Ressourcen zu überwachen, Fehler in Anwendungen in Ihren Clustern zu beheben, Kubernetes-Events mit Kontextinformationen zu korrelieren und die UX aus Ihren Anwendungen abzulesen wissen.

Erste Schritte mit Kubernetes und New Relic

On-premise wie Cloud – New Relic vermittelt Transparenz für Kubernetes-Cluster und Workloads in Minuten für umfassendes Kubernetes-Monitoring.

Sofortige Kubernetes-Observability: Auto-telemetry with Pixie

Vor einer Weile war zum Performance-Monitoring von Kubernetes-Clustern und ihren Workloads noch die Installation von mehreren Integrationen und Language Agents unabdingbar. Einfach war dies keineswegs, und besonders beim Anwendungs-Monitoring bedurfte es der manuellen Instrumentierung von Anwendungen, Code-Updates und Redeployments. Mit unserer Übernahme von Pixie Labs eröffnen wir hier nun aber einen schnelleren, einfacheren Weg.

Einher geht dieser mit sofortiger Visibility für Kubernetes-Cluster und -Workloads in Minuten. Dies ganz ohne Installation von Language Agents oder Code-Updates dank Auto-telemetry with Pixie. Hierbei handelt es sich um eine Kubernetes-native, in-cluster Observability-Lösung, die automatisch Telemetriedaten über eBPF erfasst. Die Pixie Daten fließen dann direkt in die New Relic Telemetry Data Platform, über die skalierbare Daten-Retention, umfassende Korrelationen, intelligentes Alerting und detailführende Visualisierungen garantiert sind.

Kubernetes-Integrationen

New Relic und Pixie sind nutzbar für Kubernetes-Cluster sowohl on-premise als auch in Cloud-Deployments etwa mit den folgenden Technologien:

• Amazon Elastic Container Service for Kubernetes (Amazon EKS): Mit dem Amazon EKS kann Kubernetes als Managed Service über AWS genutzt werden. Dies vereinfacht Deployment, Verwaltung und Skalierung von containerisierten Anwendungen via Kubernetes.

• Google Kubernetes Engine (GKE): GKE bietet Ihnen eine Umgebung für Deployment, Verwaltung und Skalierung Ihrer containerisierten Anwendungen via Google-Infrastruktur.

• Microsoft Azure Kubernetes Service (AKS): Über den Microsoft AKS verwalten Sie Ihre gehostete Kubernetes-Umgebung ohne umfassende Erfahrung im Hinblick auf Container-Orchestrierung, was Deployment und Verwaltung containerisierter Anwendungen erleichtert. Vorteile ergeben sich auch für den laufenden Betrieb und Wartungsabläufe: Ressourcen können nach Bedarf bereitgestellt, skaliert oder um Upgrades erweitert werden, ohne dass Ihre Anwendungen dafür offline gehen müssen.

• RedHat OpenShift: In OpenShift erhalten Sie eine integrierte Entwicklungsumgebung für Docker-formatierte Container, die Sie nach Deployment mit Kubernetes verwalten.

• Pivotal Container Service (PKS): Die Infrastruktur und Ressourcen von PKS sorgen für effizientes Deployment und konsistente Ausführung containerisierter Workloads über Private und Public Clouds.

Deployment von Instrumentierung

Die Kubernetes-Lösung von New Relic besteht aus mehreren Komponenten. In Kombination verschaffen Sie Ihnen End-to-End-Observability für Ihre Cluster. Auch einzelne Komponenten lassen sich installieren, doch für bestmögliche, vollständige Observability empfehlen wir definitiv die Implementierung des gesamten Pakets.

Zum Deployment der Instrumentierungslösungen aus der obigen Tabelle bieten wir mit der geführten Installation bzw. dem manuellen Setup zwei Methoden. Anhand der Informationen im Folgenden können Sie bestimmen, welche Methode sich am besten für Sie eignet.

Geführte Installation

Die geführte Installation vereinfacht Ihre Kubernetes-Instrumentierung. Um sie zu nutzen, wählen Sie einfach die Option Add more data, dann Guided install und schließlich Kubernetes. Die Option „Auto-telemetry with Pixie“ vermittelt Ihnen APM-Transparenz auf Code-Ebene ohne Installation von Language Agents.

Manuelles Setup

Falls Sie die einzelnen Komponenten Ihrer Kubernetes-Lösung manuell installieren möchten, folgen Sie den Anweisungen in diesem Kapitel.

APM: Auto-telemetry with Pixie oder Installation von New Relic Language Agents

Mit Auto-telemetry with Pixie müssen Sie keine Language Agents mehr installieren, um Einblicke auf Code-Level für Application Performance Management (APM) zu erhalten. Führen Sie das Deployment von Pixie mit der geführten Installation durch.

Falls Sie dennoch Language Agents installieren möchten, müssen Sie Ihre Anwendung zuerst mit der Kubernetes Downward API instrumentieren. Anhand unserer Beispielanwendung zeigen wir, wie dies in einer Node.js-Anwendung funktioniert. Sie können Ihren eigenen Fork aus diesem Repository erstellen. Unser Blogartikel zum Monitoring der Anwendungs-Performance in Kubernetes erläutert, wie Sie diese Art von Kubernetes-Metadaten zu APM-Anwendungstransaktionen hinzufügen.

Kubernetes-Integration

Die Kubernetes-Integration lässt sich ganz einfach installieren. Folgen Sie den Hinweisen in Kubernetes-Integration: Installation und Konfiguration.

Prometheus-Integration

Die Installation der Prometheus OpenMetrics Integration in einem Kubernetes-Cluster ist so einfach wie die Änderung zweier Variablen in einem Manifest mit anschließendem Deployment im Cluster. Folgen Sie hierzu den Hinweisen in diesem Kapitel.

Logs

Über das Fluent Bit Output-Plugin macht es New Relic möglich, mit New Relic Logs für Kubernetes Cluster-Logdaten zu erfassen. Nach dem Download des Plugins ist ein Deployment als Helm Chart oder manuell über die Kommandozeile möglich. Weitere Informationen erhalten Sie in der Dokumentation. 

Cluster-Prüfung mit dem Kubernetes Cluster Explorer

Der New Relic Kubernetes Cluster Explorer bietet eine mehrdimensionale Darstellung eines Kubernetes-Clusters. Hier können Sie in Ihre Namespaces, Deployments, Nodes, Pods, Container und Anwendungen hineinzoomen. Mit dem Cluster Explorer können Sie die Daten und Metadaten dieser Elemente ganz einfach abrufen und analysieren, wie sie miteinander in Beziehung stehen.

Der Kubernetes Cluster Explorer in New Relic One

Über den Kubernetes Cluster Explorer können Sie:

• Den zu prüfenden Cluster auswählen

• Nach Namespace oder Deployment filtern

• Statusdetails zu allen gewünschten Pods oder Nodes abrufen

Der Cluster Explorer setzt sich aus zwei Hauptkomponenten zusammen:

1. Eine visuelle Status-Darstellung für Cluster mit bis zu 24 Nodes. Innerhalb der Darstellung bildet der Cluster Explorer die Nodes mit den meisten Problemen in jeweils vier konzentrischen Ringen ab:

• Im äußersten Ring finden sich die Nodes des Clusters sowie Performance-Metrics zu CPU, Speicher und Storage.

• Im nächsten Ring werden Verteilung und Status der mit dem Node zusammenhängenden Pods abgebildet, die keine Alerts ausgeben.

• Der dritte Ring von außen zeigt Pods mit Alerts und potenziellen Health-Problemen, die noch aktiv sind.

• Im innersten Ring schließlich werden Pods dargestellt, die sich im Wartezustand befinden oder die Kubernetes nicht ausführen kann.

Sie können jeden beliebigen Pod auswählen und seine Details prüfen – Namespace, Deployment, Container, Alert-Status, CPU- und Speicherauslastung und viele mehr.

2. In der Node-Übersicht des Cluster Explorer finden Sie alle dem ausgewählten Cluster/Namespace/Deployment zugehörigen Nodes. Sie können sie nach Node-Namen und -Status sowie nach Pod-Namen und -Status, Container sowie CPU- und Memory-Auslastung im Vergleich mit dem jeweiligen Limit anordnen.

Besseres Monitoring mit dem Cluster Explorer

Der Cluster Explorer erweitert die Monitoring-Funktionen für Kubernetes der New Relic One Plattform. So können mit dem Cluster Explorer Kubernetes-Entitäten gefiltert, sortiert und durchsucht werden, um ein besseres Verständnis der Zusammenhänge und Abhängigkeiten innerhalb der Umgebung zu erlangen. Die Standard-Datenvisualisierungen vermitteln Ihnen dabei auf so rasche wie intuitive Weise wichtige Details zu Ihren Kubernetes-Umgebungen. Die komplexen Strukturen umfassender Kubernetes-Deployments werden so viel klarer navigierbar.

Mit dem Cluster Explorer erwarten Sie Performance-Steigerungen, konsistentere Ergebnisse und raschere Problemlösungen. Verifizieren Sie, dass alle Funktionen wie gewünscht ausgeführt werden, und identifizieren Sie Performance-Probleme innerhalb eines Clusters noch bevor sie sich auf Ihre Kunden auswirken können.

So konzipieren Sie eine umfassende Observability-Strategie für Kubernetes

Grundlage für Kubernetes-Observability bilden diese sieben Schritte:

1. Visualisierung von Services

2. Monitoring von Health-Status und Kapazität eines Clusters

3. Korrelation von Kubernetes-Events mit der Cluster-Health

4. Analyse von APM-Korrelationen

5. Integration mit Prometheus-Metrics

6. Kontext-Monitoring für Logs

7. Das Endbenutzer-Erlebnis in Aktion

1. Visualisierung von Services

In einer Kubernetes-Umgebung ist es zumeist gar nicht so einfach, alle internen Abhängigkeiten zwischen Anwendungen und Infrastruktur auszumachen oder durch alle Entitäten zu navigieren. Welche Container, Pods, Nodes, Deployments und Namespaces an einem Problem beteiligt sind, lässt sich ebenso oft nur schwer vollständig feststellen. Eine genaue Kenntnis aller Performance-Faktoren und Abhängigkeiten in der gesamten Kubernetes-Umgebung ist jedoch unabdingbar.

Dabei sollten unter anderem die folgenden Service-Kernbereiche visualisiert werden:

• Anwendungsstruktur und Abhängigkeiten 

• Interaktionen zwischen Microservices

So kann New Relic helfen

Mit dem Cluster Explorer generieren Sie mehrdimensionale Cluster-Visualisierungen und verschaffen sich so einen transparenten Überblick auch komplexer Umgebungen. Kubernetes-Daten und -Metadaten lassen sich nun über eine kompakte Benutzeroberfläche präzise analysieren. Im Ergebnis beheben Sie mit dem Cluster Explorer Problemstellungen, Bottlenecks und andere irreguläre Vorgänge in Ihrer Kubernetes-Umgebung durchwegs rascher.

Empfohlene Alerts

Beim erstmaligen Deployment der New Relic Kubernetes-Integration werden für das zugehörige Konto einige Standard-Alert-Bedingungen importiert. Die Alert-Policy wird dabei ohne einen Benachrichtigungskanal konfiguriert, um unerwünschte Alerts zu vermeiden.

Die Alert-Thresholds können für jede Umgebung angepasst, die Alert-Policy auf Benachrichtigungen umgestellt werden. Details hierzu finden Sie in der Alerts-Dokumentation für New Relic Infrastructure.

2. Monitoring von Health-Status und Kapazität eines Clusters

Kubernetes-Umgebungen sind grundsätzlich von Deployment zu Deployment unterschiedlich. Gleichzeitig weisen sie aber auch Parallelen bei Kernkomponenten, Ressourcen und potenziellen Fehlern auf. In den folgenden Abschnitten gehen wir auf Best Practices in diesem Zusammenhang ein. So zeigen wir unter anderem auf, wie Sie New Relic und Alerts zum Monitoring des Health-Status und der Kapazität einer Kubernetes-Umgebung nutzen können:

• Cluster-Ressourcenauslastung erfassen
• Monitoring der Node-Ressourcenauslastung
• Monitoring auf fehlende Pods
• Nicht ausgeführte Pods identifizieren
• Container-Neustarts beheben
• Container-Ressourcenauslastung erfassen
• Monitoring von Datenspeicher-Volumes
• Monitoring des Controller Managers

Cluster-Ressourcenauslastung erfassen

Beim Verwalten von Clustern benötigen Sie ausreichend verwendbare Ressourcen in Ihrem Cluster, um Probleme beim Pod-Scheduling oder beim Container-Deployment zu vermeiden. Steht nicht genügend Kapazität zur Verfügung, um die Mindestanforderungen aller Container zu erfüllen, können Sie die Kapazität Ihrer Nodes erhöhen oder weitere hinzufügen und die Arbeitslast so besser verteilen.

Folgende Informationen sollten vorliegen:

• Gesamtauslastung Ihrer Cluster-Ressourcen zu jedem beliebigen Zeitpunkt

• Details zu Über- bzw. Unterprovisionierung Ihrer Cluster

• Systemanfragen und -anforderungen

So kann New Relic helfen

Über unsere Kubernetes-Integration ergeben sich Tracking- und Monitoring-Möglichkeiten für die Kern- und Speicherauslastung aller Nodes in Ihrem Cluster. Ressourcenanforderungen können so leichter erfüllt und Ihre Anwendungs-Performance optimiert werden.

Das Standard-Dashboard von New Relic Infrastructure zeigt die Kern- und Speicherauslastung.

Empfohlene Alerts

Definieren Sie Alerts zur Kern- und Speicherauslastung der Hosts in Ihrem Cluster.

Monitoring der Node-Ressourcenauslastung

Nodes in Ihrem Cluster nur zu erfassen ist unzureichend: Auch CPU-, Speicher-, und Festplattenauslastung für Kubernetes-Nodes (Worker und Master) müssen überwacht werden, um den Health-Status aller Nodes im Cluster fortlaufend verifizieren zu können.

Mit diesen Daten gewährleisten Sie, dass ...

• ... eine ausreichende Anzahl an Nodes im Cluster zur Verfügung steht.

• ... die Ressourcenzuweisung zu vorhandenen Nodes für bereitgestellte Anwendungen adäquat ist.

• ... keine Ressourcen-Beschränkungen erreicht werden.

• ... etcd funktionsfähig ist

So kann New Relic helfen

New Relic überwacht die Ressourcenauslastung (genutzte Kerne und Speicher) für jeden Kubernetes-Node. Hierdurch können Sie die Anzahl der Netzwerkanfragen nachverfolgen, die über Container auf verschiedenen Nodes innerhalb eines verteilten Service erfolgen. Auch Ressourcen-Metrics für alle Container auf einem bestimmten Node können getracked werden – ganz unabhängig davon, zu welchem Service sie gehören.

Das New Relic Infrastructure Standard-Dashboard zum Monitoring des Node-Ressourcenverbrauchs 

Achten Sie immer darauf, dass Ihr aktuelles Deployment über ausreichende Ressourcen verfügt, um skalieren zu können, damit neue Node-Deployments nicht aufgrund mangelnder Ressourcen blockiert werden.

Empfohlene Alerts

Definieren Sie Alerts, um Benachrichtigungen zu erhalten, wenn Hosts keine Berichte mehr senden oder wenn die CPU- oder Speicherauslastung eines Nodes unter einen bestimmten Grenzwert fällt.

Monitoring auf fehlende Pods

Unter Umständen stellen Sie gelegentlich fest, dass einem Cluster ein Pod fehlt. Ein Pod kann verloren gehen, wenn die Engineers beim Scheduling nicht genügend Ressourcen zur Verfügung gestellt haben. Möglicherweise wurde der Pod nie gestartet, befindet sich in einer Neustartschleife oder ging wegen eines Konfigurationsfehlers verloren.

Um sicherzustellen, dass Kubernetes ordnungsgemäß funktioniert, müssen Sie die Integrität und Verfügbarkeit von Pod-Deployments überprüfen. Ein Pod-Deployment definiert die Anzahl der Instanzen, die für jeden Pod vorhanden sein müssen, einschließlich der Backup-Instanzen. (In Kubernetes wird dies als ReplicaSet bezeichnet.) Gelegentlich ist die Zahl der aktiven Pods nicht im Feld für Replicas eines Deployments angegeben. Auch wenn dies nicht der Fall ist, kann Kubernetes anhand der vom Administrator definierten Ressourcen feststellen, ob es eine weitere Instanz ausführen kann.

So kann New Relic helfen

Mit New Relic lässt sich dieses Problem leichter vermeiden, da Sie die Ressourcenbeschränkungen des Clusters kennen.  

Verfügen Sie nicht über ausreichende Ressourcen zum Scheduling eines Pods, fügen Sie dem Cluster weitere Containerinstanzen hinzu oder tauschen Sie eine Containerinstanz gegen eine mit der adäquaten Menge an Ressourcen aus. Mit der New Relic Kubernetes-Integration können Sie überwachen, ob Pods fehlen, und sofort Deployments identifizieren, die Ihre Aufmerksamkeit erfordern. Oft können so Ressourcen- oder Konfigurationsprobleme behoben werden, bevor sie sich auf die Verfügbarkeit oder Performance von Anwendungen auswirken.

Das Standard-Dashboard von New Relic Infrastructure zur Überwachung von fehlenden Pods nach Deployment.

Empfohlene Alerts

Richten Sie Alerts ein für Szenarien, in denen die fehlenden Pods in einem Deployment für einen bestimmten Zeitraum einen gewissen Schwellenwert überschreiten. Wenn die Zahl der verfügbaren Pods für ein Deployment die Zahl unterschreitet, die Sie beim Erstellen des Deployments angegeben haben, wird ein Alert gesendet. Der Alert wird für jedes Deployment angewendet, das den von Ihnen festgelegten Filterkriterien entspricht.

Nicht ausgeführte Pods identifizieren

Kubernetes plant Pods dynamisch im Cluster ein. Bei Ressourcenproblemen oder Konfigurationsfehlern schlägt die Planung wahrscheinlich fehl. Wenn ein Pod nicht ausgeführt wird oder gar nicht geplant ist, besteht wahrscheinlich entweder ein Problem mit dem Pod oder Cluster oder mit dem gesamten Kubernetes-Deployment.

Wenn Sie feststellen, dass Pods nicht ausgeführt werden, sind Antworten auf folgende Fragen wichtig:

• Befinden sich Pods in einer Neustartschleife?

• Wie oft schlagen Anfragen fehl?

• Liegen Ressourcenprobleme oder Konfigurationsfehler vor?

• Wurde ein Pod terminiert?

So kann New Relic helfen

Wie bereits erwähnt kann es bei Ressourcenproblemen oder Konfigurationsfehlern dazu kommen, dass Kubernetes die Pods nicht planen kann. In solchen Fällen sollten Sie den Health-Status Ihrer Deployments überprüfen und mögliche Konfigurationsfehler oder Ressourcenprobleme identifizieren.

Mit der Kubernetes-Integration von New Relic Infrastructure (automatisches Deployment über die geführte Installation) können Sie mithilfe von Standard-Deployment-Daten Pods ausmachen und überwachen, die möglicherweise nicht ausgeführt werden, und diese nach Cluster und Namespace anordnen.

Das Standard-Dashboard von New Relic Infrastructure zum Monitoring von Pods nach Cluster oder Namespace 

Weiter können Sie mit der zugehörigen Metric Fehlerursachen für nicht mehr ausgeführte Pods analysieren. Wird ein Pod etwa terminiert, da der Anwendungsspeicher das auf den Containern eingestellte Limit erreicht hat, wird er vom Out of Memory Killer (OOM-Killer) beendet. In einem solchen Fall zeigt New Relic den Grund für die Pod-Terminierung auf.

Empfohlene Alerts

Richten Sie Alerts für den Status Ihrer Pods ein. Alerts sollten ausgelöst werden, wenn ein Pod für die von Ihnen angegebene Zeitdauer den Status „Fehler“, „Ausstehend“ oder „Unbekannt“ aufweist.

Container-Neustarts beheben

Unter normalen Umständen sollten sich Container nicht neu starten. Container-Neustarts sind ein Zeichen dafür, dass vermutlich ein Speicherlimit für die Container erreicht wurde. Neustarts können auch auf ein Problem mit dem Container selbst oder seinem Host hinweisen. Aufgrund der Funktionsweise der Containerplanung von Kubernetes kann es außerdem schwierig sein, Container-Ressourcenprobleme zu beheben, da Kubernetes die Container neu startet (oder beendet), wenn sie das Limit erreichen.

Monitoring von Container-Neustarts liefert Ihnen zudem Antworten auf folgende Fragen:

• Befinden sich Container in einer Neustartschleife?

• Wie viele Container-Neustarts sind im Zeitraum X vorgefallen?

• Weshalb kommt es zu Container-Neustarts?

So kann New Relic helfen

Zu den Containerdaten, die New Relic standardmäßig mit der Kubernetes-Integration erfasst, gehört eine fortlaufende Zählung der Container-Neustarts.

Das Standard-Dashboard von New Relic Infrastructure zur Überwachung von Container-Neustarts.

Empfohlene Alerts

Definieren Sie Alerts für die Anzahl der Neustarts von Kubernetes-Containern. Sie können einstellen, dass Sie sofort einen entsprechenden Alert erhalten. Von Ihrem wohlverdienten Schlaf brauchen Sie sich von Container-Neustarts aber nicht abhalten lassen.

Container-Ressourcenauslastung erfassen

Durch Monitoring der Container-Ressourcenauslastung können Sie sicherstellen, dass Container und Anwendungen fehlerfrei funktionieren. Wenn ein Container beispielsweise die Grenzen seiner Speicherauslastung erreicht, könnte es sein, dass er vom Kubelet-Agent beendet wird.

Beim Monitoring der Container-Ressourcenauslastung sind folgende Informationen wichtig:

• Erreichen Ihre Container Ressourcenlimits und beeinträchtigen die Performance von Anwendungen?

• Gibt es Spitzen in der Ressourcenauslastung?

• Gibt es Muster bei der Fehlerverteilung je Container?

So kann New Relic helfen

Identifizieren Sie zunächst die Mindestmenge an CPU und Speicher, die ein Container zur Ausführung benötigt und die vom Cluster garantiert werden muss, und überwachen Sie diese Ressourcen mit New Relic.

Überwachen Sie nun die Ressourcenlimits für Container. Hierbei geht es um die Ressourcen, die ein Container maximal beanspruchen darf. In Kubernetes sind die Ressourcen standardmäßig unbegrenzt.

Das Standard-Dashboard von New Relic Infrastructure zur Überwachung der Speicherauslastung von Containern 

Das Standard-Dashboard von New Relic Infrastructure zur Überwachung der CPU-Auslastung von Containern.

Mit dieser Monitoring-Variante können Schwachstellen bei der Ressourcenauslastung proaktiv korrigiert werden, bevor sie Anwendungen beeinträchtigen.

Empfohlene Alerts

Richten Sie Alerts zur CPU- und Speicherauslastung von Containern sowie zu Limits für diese Metrics ein.

Monitoring von Datenspeicher-Volumes

Es gilt, Datenverluste und Anwendungsausfall als Resultat mangelnder Speicher-Volumes zu vermeiden.

In Kubernetes werden Speicher-Volumes Pods zugewiesen. Sie verfügen über dieselbe Lebensdauer wie der Pod. In anderen Worten: Wird ein Container neu gestartet, beeinflusst dies das Volume in keiner Form. Doch wird ein Pod beendet, geschieht dies auch analog mit dem Volume. Dies eignet sich gut für Stateless-Anwendungen oder Batch-Verarbeitungen, in denen die Daten das Ende ihrer Lebensdauer parallel zur Transaktion erreichen.

Persistent Volumes hingegen kommen bei Stateful-Anwendungen zum Einsatz und wenn Daten über die Lebensdauer des Pods hinaus zu erhalten sind. Sie finden beste Verwendung für Datenbank-Instanzen oder Messaging-Queues.

Zum Monitoring von Kubernetes-Volumes sind folgende Schritte wichtig:

• Stellen Sie sicher, dass Ihre Anwendung einerseits über ausreichend Festplattenspeicher für Ihre Pods verfügt und dass für Ihre Pods ausreichend Speicherplatz bereit steht.

• Prüfen Sie die Volume-Auslastung und passen Sie entweder je nach Auslastung die von der Anwendung generierten Daten oder die Volume-Kapazität an.

• Identifizieren Sie Ihre Persistent Volumes. Sie enthalten mit einiger Wahrscheinlichkeit wichtige Anwendungsdaten. Definieren Sie daher einen Alert-Schwellenwert bzw. eine zugehörige Benachrichtigung.

So kann New Relic helfen

Etwaige Probleme in punkto Festplatten-Volume sollen via Monitoring erfasst und entsprechende Alerts ausgegeben werden. Dies ist vor allem zutreffend im Kontext von Persistent Volumes: Hier müssen Daten Stateful-Anwendungen fortlaufend zur Verfügung stehen. Ansonsten kommt es beim Rescheduling oder der Neuerstellung eines Pods zu einer Terminierung. Dies ist etwa dann der Fall, wenn ein Container-Image auf eine neue Version aktualisiert wird.

Mit Kubernetes Volume-Monitoring in New Relic One richten Sie passende Alerts ein. Erreicht ein Volume einen bestimmten Grenzwert, erfahren Sie direkt davon. So adressieren Sie Probleme in der Anwendungs-Performance oder -Verfügbarkeit proaktiv.

Das New Relic Infrastructure Standard-Dashboard zum Monitoring des Kubernetes-Volumes

Empfohlene Alerts

Definieren Sie Alerts für Byte-Verfügbarkeit, Kapazität oder Node-Auslastung in Ihrem Cluster. 

Monitoring des Controller Managers

Über die Kontrollebene wird sichergestellt, dass der aktuelle Cluster-Status dem gewünschten entspricht. Dies erfolgt durch Starten und Neustarten von Containern und Skalierung von Anwendungs-Replicas. Dabei werden hier auch alle Kubernetes-Objekte im Cluster erfasst und getracked. Kontrollschleifen verwalten den Status dieser Objekte.

Dank der Kontrollebene haben Kubernetes-Anwender also stets Kenntnis des Health-Status von Komponenten auf der Kontrollebene und können somit pro-aktiv reagieren, bevor etwaige Probleme sich auf Services und Endbenutzer auswirken.

Über die Kubernetes-Integration werden Metrics zu den folgenden Komponenten auf der Kontrollebene überwacht und erfasst:

etcd

Hier werden der aktuelle und gewünschte Cluster-Status gespeichert, so auch alle Informationen zu Pods, Deployments, Services, Secrets etc. Es handelt sich hierbei um den einzigen Kubernetes-Speicherort.

Zum Monitoring von etcd sollten folgende Datenpunkte erfasst werden:

• Leader und Änderungsrate

• Bestätigte, angewendete, ausstehende und fehlgeschlagene Proposals

• gRPC-Performance

Empfohlene Alerts

Legen Sie Alerts fest, um informiert zu werden, falls ausstehende oder fehlgeschlagene Proposals ungewünschte Schwellenwerte erreichen.

API-Server

Über die zentrale RESTful HTTP API laufen alle Anfragen von Benutzern, Nodes, Komponenten der Kontrollebene und Automatisierung. Der API-Server zeichnet verantwortlich für Authentifizierung, Autorisierung und Objektvalidierung und Speicherung dieser in etcd. Er kommuniziert als einzige Komponente direkt mit etcd.

Zum Monitoring des API-Servers sollten folgende Datenpunkte erfasst werden:

• Frequenz und Anzahl der HTTP-Anfragen

• Frequenz und Anzahl der apiserver-Anfragen

Empfohlene Alerts

Definieren Sie Alerts, die Benachrichtigungen ausgeben, wenn die Frequenz oder Anzahl der HTTP-Anfragen einen bestimmten Wert übersteigen.

Scheduler

Mit dem Scheduler werden neu erstellte Pods zu Worker-Nodes zugewiesen, die diese Pods ausführen können. Hierzu aktualisiert der Scheduler die Pod-Definition über den API-Server.

Bei der Auswahl eines Worker-Nodes berücksichtigt der Scheduler mehrere Faktoren wie z. B. angefragte CPU bzw. Speicher im Vergleich zur verfügbaren Kapazität auf dem Node. Hierzu aktualisiert der Scheduler die Pod-Definition über den API-Server.

Zum Monitoring des Schedulers sollten folgende Datenpunkte erfasst werden:

• Frequenz, Anzahl und Latenz der HTTP-Anfragen

• Scheduling-Latenz

• Scheduling-Versuche nach Ergebnis

• Scheduling-Latenz end-to-end (Scheduling-Summe) 

Empfohlene Alerts

Definieren Sie Alerts, die Benachrichtigungen ausgeben, wenn die Frequenz oder Anzahl der HTTP-Anfragen einen bestimmten Wert übersteigen.

Controller Manager

Hier werden alle Controller ausgeführt. Genauso wie der Scheduler nutzen die Controller die Watch-Funktionen der API-Server zur Benachrichtigung bei Status-Änderungen. Bei Erhalt einer Benachrichtigung versuchen sie den Cluster in den gewünschten Status zu überführen. Erstellen wir etwa ein neues Objekt, das Y Pods generiert, liegt es am zugehörigen Controller, aus dem aktuellen Cluster-Status von X Pods Y Pods zu machen.

Zum Monitoring des Schedulers sollten folgende Datenpunkte erfasst werden:

• Tiefe der Work Queue

• Anzahl der Retries durch die Work Queue

Empfohlene Alerts

Definieren Sie Alerts, die Benachrichtigungen ausgeben, wenn die Worker Queue den Grenzwert überschreitet.

3. Korrelation von Kubernetes-Events mit der Cluster-Health

Für schnellere Fehlersuche und -behebung können Sie den Health-Status Ihres Clusters und anderer Objekte mit Kubernetes-Events korrelieren. Falls Sie komplexe Kubernetes-Umgebungen ausführen oder über keinen Kommandozeilen-Zugriff auf Ihr Cluster verfügen, können Sie die Abläufe in Ihrem Cluster über Kubernetes-Events ablesen.

Ein Beispiel: Das Scheduling für einen Pod wird nicht korrekt ausgeführt und dieser nicht gestartet, da der ihm zugewiesene Node nicht über ausreichend Kapazität verfügt. In diesem Fall kann der Node den Pod nicht aufnehmen, sodass dieser den Ausstehend-Status nicht verlässt. Allerdings bieten keine Metrics oder Metadaten genauere Informationen zu diesem Problem. Mit Kubernetes-Events hingegen erhalten Sie eine klare Information:

FailedScheduling [...]  0 nodes are available: Insufficient memory

Falls Sie eine Kubernetes-Umgebung verwalten oder Anwendungen darüber entwickeln, benötigen Sie:

• Transparenz für die Kubernetes-Events jedes Clusters

• Transparenz für die Kubernetes-Events im Zusammenhang mit einem bestimmten Objekt wie einem Pod oder einem Node

• Alerts zu Kubernetes-Events

So kann New Relic helfen

Wie im vorangehenden Beispiel dargestellt bieten Kubernetes-Events zusätzliche Kontextinformationen, die Metrics und Metadaten nicht liefern. Verwenden Sie Kubernetes-Events zusammen mit dem Cluster Explorer, erhalten Sie einen umfassenden Überblick zum Health-Status Ihrer Plattform.

Kubernetes-Events können über die Events-Registerkarte des Kubernetes Cluster Explorer aufgerufen werden.

Bei der Fehlerbehebung in einem Pod bringen Sie Kubernetes-Events mit Kontext direkter zu den Fehlerursachen. New Relic reichert jeden Event mit nützlichen Details an, anhand derer Sie erkennen können, ob er mehrere Pods oder Nodes in einem Cluster betrifft. Etwa bei Skalierung eines ReplicaSet oder bei Erstellung eines neuen Pods durch StatefulSet.

Mit dem New Relic Chart Builder fragen Sie Kubernetes-Events ab oder sehen sie über den Cluster Explorer ein.

Empfohlene Alerts

Definieren Sie Alerts für bestimmte Event-Arten auf Objekten und Ressourcen in Ihrem Cluster. New Relic kann beispielsweise Alerts ausgeben, wenn eine geplante Autoscaling-Aktion nicht durchgeführt wird.

4. Analyse von APM-Korrelationen

Ein wichtiger Vorteil von Kubernetes findet sich in der Abkopplung Ihrer Anwendung und der zugehörigen Anwendungslogik von den spezifischen Details ihrer Laufzeitumgebung. Wenn Sie die zugrunde liegende Infrastruktur beispielsweise einmal auf eine neue Linux-Version umstellen müssen, ist es nicht vonnöten, den Anwendungscode völlig neu zu schreiben.

Können Anwendungsfehler-Traces direkt mit dem Container, Pod oder Host korreliert werden, auf dem die Anwendung ausgeführt wird, vereinfacht dies Debugging und Fehlerbehebung. Äußerst nützlich ist dies etwa beim Monitoring von Anwendungen, die über einen Orchestrierungs-Layer verwaltet werden.

Auf der Anwendungsebene sollten Sie die Performance und Verfügbarkeit von Anwendungen überwachen, die in Ihrem Kubernetes-Cluster ausgeführt werden. Dies können Sie tun, indem Sie Metrics wie Anfragefrequenz, Throughput und Fehlerrate überwachen.

Mit New Relic APM können Sie benutzerdefinierte Attribute hinzufügen. Diese Metadaten sind dann in für Ihre Anwendung erfassten Transaktions-Traces verfügbar. Erstellen Sie Custom-Attribute und rufen Sie über diese Informationen zum Kubernetes-Node, -Pod oder -Namespace ab, auf dem eine bestimmte Transaktion erfolgt ist.

In den folgenden Abschnitten wird auf wichtige Aspekte zum Monitoring Ihrer mit Kubernetes gehosteten Anwendungen eingegangen:

• Monitoring des Health-Status einer Anwendung
• Fehler vermeiden

Monitoring des Health-Status einer Anwendung

Bei Kubernetes bewegen sich die Container, in denen die Anwendungen ausgeführt werden, häufig im Cluster, wenn Instanzen hoch- bzw. heruntergefahren werden. Diese Planung erfolgt in Kubernetes automatisch, kann jedoch die Performance oder Verfügbarkeit Ihrer Anwendungen beeinträchtigen. Für Anwendungsentwickler ist es wichtig, Kubernetes-Objekte für das Debugging und die Fehlerbehebung mit Anwendungen korrelieren zu können.


Dafür sind folgende Informationen wichtig:

• Welche Anwendungen sind mit welchem Cluster verknüpft?

• Wie viele Transaktionen erfolgen in einem bestimmten Pod?

• Welche Servicelatenz/welchen Service-Throughput weist eine bestimmte Produktionsanwendung auf?

So kann New Relic helfen

Um Transaktions-Traces in Kubernetes zu überwachen, benötigen Sie eine codezentrierte Übersicht Ihrer Anwendungen. Sie müssen Anwendungen mit dem Container, Pod oder Host korrelieren, in dem sie ausgeführt werden. Außerdem ist es wichtig, Pod-spezifische Performanceprobleme für Anwendungs-Workloads zu identifizieren.

Über die Pod-Detailansicht im Cluster Explorer analysieren Sie die Performance der Anwendungen, die über den jeweiligen Pod ausgeführt werden.

Wenn Sie die Namen des Pods und des Nodes kennen, auf denen ein Fehler aufgetreten ist, kann das Problem deutlich schneller behoben werden. Durch den Einblick in Transaktions-Traces werden Abweichungen in Ihrer mit Kubernetes gehosteten Anwendung schnell aufgezeigt.

Via Distributed Tracing können Sie außerdem die Distributed Traces für jede Anwendung in Ihrem Cluster erfassen. Mit einem Klick auf einen Span in einem Distributed Trace können Sie direkt alle relevanten Kubernetes-Attribute für die zugehörige Anwendung einsehen und so etwa identifizieren, zu welchem Pod, Cluster und Deployment ein Span gehört.

New Relic Distributed Tracing erfasst Details zu Traces aus Ihren Anwendungen in Kubernetes

New Relic Distributed Tracing liefert Features für automatisierte Anomalie-Erkennung und identifiziert so langsame Spans und Bottlenecks. Weiter sollten Alerts für wichtige Transaktionen und Kommunikationsläufe mit den APIs Dritter eingerichtet werden.

Weitere Informationen zur Detailanalyse von Transaktions-Traces in Kubernetes finden Sie im Blogartikel Monitoring Application Performance in Kubernetes.

Empfohlene Alerts

Sie sollten Alerts für alle Anwendungen einrichten, die in der Produktion ausgeführt werden. Insbesondere Alerts zu API-Serviceanfragen, Transaktionen, Servicelatenzen, Uptime und Throughput sind sinnvoll, damit Sie wissen, ob eine dieser Metrics unter den von Ihnen festgelegten Schwellenwert fällt.

Fehler vermeiden

Wenn ein einzelner Pod oder eine bestimmte Pod-IP ausfällt oder Fehler verursacht, müssen Sie die Fehler beheben, bevor sie dem Cluster oder der Anwendung schaden. Hier gilt es, die Fehlerursache rasch auszumachen und auszumerzen.

Dafür sind folgende Informationen wichtig:

• In welchem Namespace, auf welchem Pod oder Host ist eine Transaktion fehlgeschlagen?

• Funktioniert die Anwendung in allen Pods wie erwartet?

• Performance von Anwendung X auf Pod Y

So kann New Relic helfen

New Relic One bietet Ihnen eine codezentrierte Übersicht der in Ihrem Cluster ausgeführten Anwendungen. Sie können Ihre mit Kubernetes gehosteten Anwendungen auf Performance-Ausreißer überwachen und einzelne Fehler zurückverfolgen.

APM-Fehlerprofile erkennen automatisch, wenn Fehler innerhalb derselben Pods und von Pod-IP-Adressen auftreten.

Empfohlene Alerts

Konfigurieren Sie Alerts, um Fehlerraten für alle Anwendungen zu verfolgen, die in Produktionsumgebungen in Kubernetes ausgeführt werden.

5. Integration mit Prometheus-Metrics

Prometheus ist ein Open-Source-Toolkit zum Monitoring und zur Alert-Definition für Services und Anwendungen in Containern. Es kommt umfassend bei der Erfassung von Metrics-Daten aus Kubernetes-Umgebungen zum Einsatz, inzwischen sogar als De-facto-Standard für Kubernetes in dieser Hinsicht.

Prometheus setzt dabei auf ein abrufzentrisches System zur Erfassung mehrdimensionaler Zeitreihen-Metrics aus Services über HTTP-Endpunkte, anstatt die Ausgabe durch die Services passiv abzuwarten. Dank dieser Methodik können Lösungsanbieter wie New Relic Integrationen konzipieren, die mit den Metrics-Exportern von Prometheus interagieren und so wertvolle Speicher- und Visualisierungsdaten abrufen können.

So kann New Relic helfen

Die Prometheus OpenMetrics Integration von New Relic erfasst Telemetriedaten aus vielen Services (wie Traefik, Envoy und etcd), die Metrics in einem mit Prometheus kompatiblen Format wiedergeben. Mit dieser Integration erhalten Sie Monitoring-Möglichkeiten für wichtige Aspekte Ihrer Kubernetes-Umgebungen, so zum Beispiel für Performance- und Health-Metrics von etcd, die Kapazität des Kubernetes Horizontal Pod Autoscaler (HPA) sowie die Node-Verfügbarkeit.

Die Integration unterstützt sowohl Docker als auch Kubernetes via Prometheus 2. 

Nach erfolgreicher Integration von Docker oder Kubernetes können Sie damit beginnen, Abfragen zur Erfassung und Visualisierung Ihrer Prometheus Daten in New Relic zu erstellen. Bei der Fehlerbehebung in Ihren Kubernetes-Clustern sind die mit dieser Integration abgerufenen Metrics zusammen mit denen aus New Relic APM und Pixie verfügbar.

Weitere Informationen zu Kompatibilität und Anforderungen, Installationsoptionen, Datenlimits, Konfiguration, Metrics-Abfragen, Fehlerbehebung, Metrics-Transformation und mehr erhalten Sie in unserer Dokumentation. 

Nutzung von Daten aus Prometheus in New Relic 

Prometheus-Daten lassen sich auf verschiedenem Wege in New Relic nutzen, zu den interessantesten Use Cases zählen jedoch die folgenden:

etcd-Monitoring

etcd ist ein auf Schlüssel-Wert-Paaren basierender Datenspeicher und Grundlage zur Ausführung von Kubernetes-Clustern. Prometheus ruft Metrics von etcd ab. Möchten Sie also sichergehen, dass der Health-Status Ihrer Cluster Ihren Vorstellungen entspricht, können Sie mit der Prometheus OpenMetrics Integration Monitoring-Prozesse für etcd Server-, Festplatten- und Netzwerk-Metrics umsetzen. Hierzu gehören etwa die folgenden:

• etcd_server_has_leader
• etcd_server_proposals_failed_total
• etcd_network_peer_sent_bytes_total
• etcd_disk_wal_fsync_duration_seconds

Kubernetes Horizontal Pod Autoscaler (HPA)

Der HPA skaliert das Kubernetes-Deployment automatisch basierend auf benutzerkonfigurierten Limits. Nach der Installation der Prometheus OpenMetrics Integration können Sie über die folgende Abfrage im New Relic One Chart Builder (oder New Relic Insights) ein Dashboard-Widget erstellen und die verbleibende HPA-Kapazität überwachen.

FROM Metric select latest(kube_hpa_status_current_replicas),latest(kube_hpa_spec_max_replicas) where clusterName = '<YOUR CLUSTER NAME>'  facet hpa

Node-Verfügbarkeit

In Kubernetes gilt ein Node als bereit, wenn er Workloads (Pods) annehmen kann. Kommt es bei einem Node hingegen zu Problemen, vermerkt ihn Kubernetes als „nicht bereit“. Zur Erstellung einer Alert-Bedingung mit der Integration nutzen Sie die folgende Abfrage:

FROM Metric select latest(kube_node_status_condition) where condition='Ready' and status = 'true' and clusterName = '<YOUR CLUSTER NAME>' facet nodeName

Erstellung einer Alert-Bedingung zum Node-Status

6. Kontext-Monitoring für Logs

New Relic Logs steht im Kubernetes Cluster Explorer zur Verfügung und macht Suchen nahezu in Echtzeit mit vollständigen Kontext-Informationen möglich. Durch Kontextkonfiguration können Sie Ihre Log-Nachrichten mit Anwendungs-, Infrastruktur-, Kubernetes- und Event-Daten korrelieren.

So ist es beispielsweise ganz einfach, Log-Nachrichten zu Anwendungen mit zugehörigen Distributed Traces in New Relic APM in Zusammenhang zu bringen. New Relic fügt Trace-IDs zu den entsprechenden Anwendungs-Logs hinzu und filtert diese Logs automatisch aus den Distributed Trace UIs. Durch Zusammenführung aller Daten in einem Tool stoßen Sie schneller zur grundlegenden Fehlerursache vor. Rasch entsteht hier ein klares Bild begonnen bei der Gesamtheit Ihrer Logs bis hin zu genau den Log-Zeilen, die Sie benötigen, um ein Problem auszumachen und es zu lösen.

Sie erhalten dadurch End-to-End-Transparenz und eine Detailtiefe, die mit Logdaten in Silos schlichtweg nicht erreichbar ist.

New Relic Logs erfasst Log-Daten aus Ihren Clustern

7. Das Endbenutzer-Erlebnis in Aktion

Stellen Sie sich vor, Sie haben ein Produkt bei einem Onlineversand bestellt und es kommt zu spät oder beschädigt bei Ihnen an: Wollen Sie wirklich wissen, wo genau im Lieferprozess es gehapert hat? Ob der Fehler nun beim Hersteller, beim Händler oder beim Lieferdienst lag – das Endergebnis ist in jedem Fall ärgerlich.

Ähnlich sieht es bei in Kubernetes gehosteten Anwendungen aus: Wenn ein Kunde eine Website besucht und sie nicht oder zu langsam lädt, ist ihm die technische Ursache dafür herzlich egal. Genau deshalb reicht es auch nicht aus, nur die Performance Ihrer eigenen Systeme zu überwachen. Mindestens genauso wichtig ist die Frontend-Performance Ihrer Anwendung, um zu wissen, wie das Kundenerlebnis wirklich aussieht.

Obwohl Ihre Anwendung in Kubernetes ausgeführt wird, können Sie dennoch die wichtigsten Indikatoren für das Kundenerlebnis identifizieren und überwachen. Dabei werden Sie genauer sehen, wie sich die mobile oder Browser-Performance einer Anwendung auf das Geschäft auswirkt. 

So kann New Relic helfen

Bei der erstmaligen Migration zu Kubernetes können Entwickler beispielsweise eine Baseline vor der Migration erstellen, um die durchschnittliche Ladezeit ihrer Frontend-Anwendung vor und nach der Migration zu vergleichen. Sie können dieselben Strategien wie in punkto Anwendungs-Performance nutzen, um Einblicke in wichtige Indikatoren für die Performance mobiler Anwendungen und Browser zu erhalten, beispielsweise Reaktionszeit und Fehler. Auch Ladezeit und Verfügbarkeit sollten unbedingt überwacht werden, um ein hohes Maß an Kundenzufriedenheit stets zu gewährleisten. New Relic Browser und New Relic Mobile bieten Ihnen genau diese kritischen Informationen zum Kundenerlebnis.

Die New Relic Browser-Übersichtsseite zeigt eine Zusammenfassung der Browser-Performance für die Anwendung.

Mit New Relic Mobile schnell Absturzvorfälle, Anwendungsstarts und mehr einsehen

Entwickler und Ops-Teams müssen außerdem die Verfügbarkeit von mit Kubernetes gehosteten Services durchgängig erfassen können, dies häufig von Standorten auf der ganzen Welt. Hier setzt New Relic Synthetics an, ermöglicht die Überwachung der Anwendungsverfügbarkeit und -Performance von zahlreichen Standorten.

New Relic vereint Informationen auf Unternehmensebene und Performance-Daten in einer zentralen Übersicht. Dies hilft Dev-, Ops-, Produkt- und Support-Teams, Optimierungsmöglichkeiten in ihren Produkten zu erkennen. Ebenso nehmen sie neue Möglichkeiten zum Debugging von Fehlern mit Einfluss auf das Kundenerlebnis wahr.
 

Empfohlene Alerts

New Relic Mobile-Alerts:

• Mobile Netzwerkfehlerrate und Reaktionszeit, um sicherzustellen, dass Sie über die wichtigsten Endpunkte benachrichtigt werden

New Relic Browser-Alerts: 

• Sinkende Zahl der Browsersitzungen als möglicher Hinweis auf Verfügbarkeitsprobleme 

• Browser-JavaScript-Fehlerrate oder -Fehlerzahl 

• Dauer der Browser-Interaktionen

New Relic Synthetics-Alerts:

• Synthetics-Fehlerrate oder -Fehlerzahl

• Synthetics-Reaktionszeiten

• Synthetics Ping-Checks 

Kubernetes smart skaliert: Ein Praxisbeispiel

Wer Kubernetes erst seit kurzer Zeit im Einsatz hat oder diesen aktuell plant, für den wird es hilfreich sein, zu sehen, wie andere eine Implementierung dank Monitoring mit nachhaltigem Erfolg umsetzen konnten.   

Mit seiner Gründung im Jahr 1997 hat es sich Phlexglobal zur Aufgabe gemacht, Unternehmen aus der Biowissenschaft bei der Rationalisierung klinischer Studien zu unterstützen. So hilft es ihnen etwa, alle Abläufe rund um Trial Master Files (TMF) besser zu verwalten. Eine äußerst wichtige Aufgabe, handelt es sich dabei doch um die vollständige Dokumentation zu einer klinischen Studie.

HERAUSFORDERUNGEN

• Performance-Skalierung, -Monitoring und -Management für die Dokumentationsplattform des Unternehmens bei gleichzeitiger Migration von Workloads zu Kubernetes 

• Gewährleistung hoher Qualitätsstandards für die Plattform im Einklang mit gesetzlichen und Branchenvorschriften sowie zur optimalen Zusammenarbeit mit an den Studien beteiligten Partnern

LÖSUNG

Gefragt war eine Lösung, die dem Unternehmen zu mehr Agilität verhelfen würde. Seitens der internen Entwickler und IT-Teams lagen hierfür verschiedene spezifische Anforderungen vor. Von New Relic erwartete sich Phlexglobal dabei Transparenz für sein Gesamtsystem und infolgedessen umfassende Möglichkeiten für konsequentes pro-aktives Monitoring. Lesen Sie alle Details in der vollständigen Monitoring-Erfolgsgeschichte unseres Kunden.