Aktive oder passive Zustandsprüfungen: Welche sind die richtigen für Sie?

NGINX | 11. April 2023

So wie regelmäßige ärztliche Vorsorgeuntersuchungen wichtig sind, um gesund zu bleiben, sind regelmäßige Überprüfungen des Zustands Ihrer Apps entscheidend für eine zuverlässige Leistung. Beim Reverse-Proxying und beim Load Balancing des Datenverkehrs verwendet NGINX passive Zustandsprüfungen, um die Benutzer Ihrer Anwendungen vor Ausfällen zu schützen. Dazu wird der Datenverkehr automatisch von Servern weggeleitet, die nicht auf Anfragen reagieren. NGINX Plus ergänzt dies durch aktive Zustandsprüfungen, bei denen spezielle Testanfragen gesendet werden, um fehlerhafte Server zu erkennen, noch bevor sie eine Anfrage nicht mehr verarbeiten können. Welche Art der Zustandsprüfung ist für Ihre Anwendungen sinnvoll? In diesem Beitrag erhalten Sie die Informationen, die Sie für diese Entscheidung benötigen.

Was ist eine Zustandsprüfung?

Im einfachsten Sinne ist ein Health Check eine Methode, mit der festgestellt wird, ob ein Server Anfragen verarbeiten kann. NGINX verwendet Health Checks, um die Server zu überwachen, für die es als Reverse-Proxy fungiert oder den Datenverkehr per Lastverteilung verteilt. Diese werden als „Upstream-Server“ bezeichnet.

Passive Zustandsprüfungen

Passive Systemdiagnosen – verfügbar sowohl in NGINX Open Source als auch in NGINX Plus – basieren auf der Beobachtung des Serververhaltens bei der Verarbeitung von Verbindungen und Datenverkehr. Sie tragen dazu bei, Ausfälle für Benutzer aufgrund von Server-Zeitüberschreitungen zu vermeiden: Wenn NGINX feststellt, dass ein Server fehlerhaft ist, leitet es die Anfrage sofort an einen anderen Server weiter, sendet keine weiteren Anfragen mehr an den fehlerhaften Server und verteilt künftige Anfragen auf die verbleibenden fehlerfreien Server in der Upstream-Gruppe.

Beachten Sie, dass passive Systemdiagnosen nur dann wirksam sind, wenn die Upstream-Gruppe mehrere Mitglieder umfasst. Ist nur ein Upstream-Server definiert, wird dieser nie als nicht verfügbar gekennzeichnet, sodass es bei einem fehlerhaften Zustand zu einem für die Benutzer spürbaren Ausfall kommt.

Funktionsweise passiver Integritätsprüfungen

Hier erfahren Sie im Detail, wie passive Zustandsprüfungen funktionieren. Wenn Sie das nicht interessiert, können Sie direkt zu den Aktiven Zustandsprüfungen springen.

Standardmäßig stuft NGINX einen TCP/UDP-Server (Stream) als fehlerhaft ein, wenn beim Herstellen einer Verbindung zu ihm ein einziger Fehler oder eine Zeitüberschreitung auftritt.

NGINX betrachtet einen HTTP-Server als fehlerhaft, wenn beim Herstellen einer Verbindung zu ihm, beim Weiterleiten einer Anfrage an ihn oder beim Lesen des Antwort-Headers ein einziger Fehler oder eine Zeitüberschreitung auftritt (wenn überhaupt keine Antwort empfangen wird, gilt dies ebenfalls als ein solcher Fehler). Mit der Direktive proxy_next_upstream können Sie diese Bedingungen für das HTTP-Proxying anpassen. Entsprechende Direktiven gibt es auch für die Protokolle FastCGI, gRPC, memcached, SCGI, TCP/UDP und uwsgi.

Sowohl bei HTTP als auch bei TCP/UDP wartet NGINX standardmäßig zehn Sekunden, bevor erneut versucht wird, eine Verbindung zu einem fehlerhaften Server herzustellen und eine Anfrage an ihn zu senden. Mit dem Parameter „fail_timeout“ der Direktive „server[HTTP][Stream]“ können Sie diese Zeitspanne ändern.

Mit dem Parameter max_fails der Direktive server können Sie die Anzahl der Fehler oder Zeitüberschreitungen erhöhen, die auftreten müssen, damit NGINX den Server als fehlerhaft einstuft. In diesem Fall legt der Parameter fail_timeout sowohl den Zeitraum fest, innerhalb dessen diese Anzahl von Fehlern oder Zeitüberschreitungen auftreten muss, als auch die Zeitspanne, die NGINX wartet, bevor es nach der Einstufung des Servers als fehlerhaft erneut versucht, eine Verbindung zu ihm herzustellen.

Aktive Zustandsprüfungen

Aktive Zustandsprüfungen, die ausschließlich in NGINX Plus verfügbar sind, sind spezielle Anfragen, die regelmäßig an Anwendungsendpunkte gesendet werden, um sicherzustellen, dass diese ordnungsgemäß antworten. Sie werden unabhängig von passiven Zustandsprüfungen und zusätzlich zu diesen durchgeführt. Beispielsweise kann NGINX Plus regelmäßig eine HTTP-Anfrage an den Webserver der Anwendung senden, um sicherzustellen, dass dieser mit einem gültigen Antwortcode und den korrekten Inhalten antwortet. Aktive Zustandsprüfungen ermöglichen die kontinuierliche Überwachung des Zustands bestimmter Anwendungskomponenten und -prozesse. Sie stellen eine direkte Messung der Anwendungsverfügbarkeit dar, wobei deren Aussagekraft davon abhängt, wie repräsentativ die angegebene Zustandsprüfung für den Gesamtzustand der Anwendung ist.

Sie können viele Aspekte einer aktiven Zustandsprüfung anpassen; siehe „Anwendungsfälle für aktive Zustandsprüfungen“.

Diagramm mit den von NGINX Open Source und NGINX Plus für passive und aktive Systemzustandsprüfungen verwendeten Datenverkehrstypen

Anwendungsfälle für passive Integritätsprüfungen

Passive Integritätsprüfungen sind eine Grundvoraussetzung. Es gilt als Best Practice, dass jedes Team in den Bereichen Anwendungsentwicklung, DevOps, DevSecOps und Plattformbetrieb passive Integritätsprüfungen als Teil seines Überwachungsprogramms für die Produktionsinfrastruktur durchführt. NGINX führt standardmäßig passive Integritätsprüfungen für Traffic mit Lastverteilung durch, einschließlich HTTP-, TCP- und UDP-Konfigurationen.

Zu den Vorteilen passiver Zustandsprüfungen gehören:

  • Verfügbar in NGINX Open Source
  • Standardmäßig aktiviert für die Server, die in einem upstream{}-Konfigurationsblock enthalten sind
  • Keine zusätzliche Belastung der Upstream-Server
  • Konfigurierbar hinsichtlich der Mindestanzahl von Fehlern innerhalb eines bestimmten Zeitraums, wie beschrieben unter Funktionsweise passiver Integritätsprüfungen
  • Konfigurierbarer langsamer Start (exklusiv in NGINX Plus) – wenn ein Server wieder fehlerfrei arbeitet, erhöht NGINX Plus schrittweise den an ihn weitergeleiteten Datenverkehr, damit er Zeit zum „Aufwärmen“ hat

Die Vorteile von NGINX Open Source sind die Kosten (offensichtlich keine), die Konfigurierbarkeit und eine umfangreiche Bibliothek mit Modulen von Drittanbietern. Da der Quellcode verfügbar ist, können Entwickler die Funktionalität an ihre spezifischen Anforderungen anpassen und erweitern.

Für viele Anwendungen (und deren Entwickler) sind passive Zustandsprüfungen ausreichend. Aktive Zustandsprüfungen wären beispielsweise für Microservices, die nicht direkt von Kunden genutzt werden und kleinere Aufgaben ausführen, möglicherweise überdimensioniert. Ebenso sind sie unter Umständen nicht erforderlich für Anwendungen, bei denen Caching das Risiko von Latenzproblemen verringern kann oder Content Delivery Networks (CDNs) einen Teil der Anwendungsaufgaben übernehmen können. Zusammenfassend eignen sich ausschließlich passive Zustandsprüfungen am besten für:

  • Überwachung des HTTP-Datenverkehrs
  • Infrastruktur getrennt von Anwendungen überwachen
  • Überwachung von Anwendungen, bei denen Latenz tolerierbar ist
  • Überwachung interner Anwendungen, bei denen eine hohe Leistung nicht wichtig ist

Anwendungsfälle für aktive Zustandsprüfungen

Bei geschäftskritischen Anwendungen sind aktive Zustandsprüfungen häufig unverzichtbar, da sich Probleme unmittelbar auf Kunden und wichtige Prozesse auswirken. Bei diesen Anwendungen ist es entscheidend, die Anwendung im Wesentlichen so zu testen, wie es ein Kunde oder Nutzer der Anwendung tun würde. Dafür sind aktive Zustandsprüfungen erforderlich. Aktive Zustandsprüfungen ähneln Tools zur Überwachung der Anwendungsleistung wie New Relic und AppDynamics, die Out-of-Band-Prüfungen verwenden, um die Anwendungslatenz und die Antworten der Anwendung zu messen. Für aktive Zustandsprüfungen bietet NGINX Plus eine Reihe von Funktionen und Möglichkeiten, die in NGINX Open Source nicht enthalten sind:

  • Out-of-Band-Zustandsprüfungen für die Anwendungsverfügbarkeit
  • Konfigurierte Endpunkte testen und auf bestimmte Antworten prüfen
  • Testen Sie andere Ports als diejenigen, über die der tatsächliche Anwendungsdatenverkehr läuft.
  • HTTP-Keepalive-Verbindungen für Integritätsprüfungen, sodass nicht für jede Prüfung eine neue Verbindung aufgebaut werden muss
  • Mehr Kontrolle über Fehler- und Erfolgskriterien
  • Optional können neu hinzugefügte Server getestet werden, bevor sie echten Anwendungsdatenverkehr erhalten.

Mit aktiven Integritätsprüfungen können Entwickler NGINX Plus so konfigurieren, dass automatisch erkannt wird, wenn ein Backend-Server ausgefallen ist oder Probleme aufweist. Der Datenverkehr wird dann an fehlerfrei funktionierende Server weitergeleitet, bis das Problem behoben ist. Dank der umfangreicheren Konfigurationsmöglichkeiten aktiver Integritätsprüfungen lassen sich komplexere Prüfungen durchführen, die Anwendungsprobleme möglicherweise erkennen, bevor sie sich auf tatsächliche Anwendungsbenutzer auswirken. Dadurch können Ausfallzeiten minimiert und Unterbrechungen beim Benutzerzugriff auf die Anwendung vermieden werden.

So konfigurieren Sie Integritätsprüfungen

Passive Integritätsprüfungen sind standardmäßig aktiviert. Sie können jedoch deren Häufigkeit und die Anzahl der Fehler anpassen, nach denen ein Dienst als fehlerhaft eingestuft wird. Weitere Informationen finden Sie unter „Funktionsweise passiver Integritätsprüfungen“. Eine vollständige Anleitung zur Konfiguration passiver und aktiver Integritätsprüfungen finden Sie in unserer Dokumentation:

Fazit: Wählen Sie die Health Checks, die zu den Anforderungen Ihrer Anwendung passen

Integritätsprüfungen sind ein wichtiger Bestandteil, um einen reibungslosen Betrieb und kurze Reaktionszeiten von Produktionsanwendungen sicherzustellen. Sie sind die beste Möglichkeit, Probleme zu erkennen und zunehmende Latenzquellen zu identifizieren, bevor sie sich auf die Endbenutzer auswirken. Für viele Anwendungen sind passive Integritätsprüfungen ausreichend.

Für kritischere Anwendungen, bei denen direkte Einblicke in das Anwendungsverhalten auf Benutzerebene erforderlich sind, eignen sich aktive Prüfungen besser. NGINX Open Source kann kostenlos genutzt werden und bietet konfigurierbare passive Systemzustandsprüfungen. NGINX Plus bietet erweiterte Funktionen für aktive Systemzustandsprüfungen sowie kommerziellen Support.

Möchten Sie aktive Zustandsprüfungen mit NGINX Plus ausprobieren? Starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.


Teilen

Über den Autor

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.