fb
API Management 2 min

Health Checks für WSO2 Produkte

Steve Liem
Steve Liem
Technical Consultant
Health Check for WSO2 products
Scrollen

Für einfache Health Checks direkt in einem Carbon-Container benötigen Sie eine Schnittstelle, die gerade genug Informationen bereitstellt, um festzustellen, ob die Umgebung in Ordnung ist. Es sollte auch ein einfacher Prozess sein, der keine Auswirkungen auf die Systemlast hat. Der Prozess sollte sicher sein und keine sensiblen Systeminformationen preisgeben, die für mögliche Hackerangriffe von Nutzen sein könnten. In diesem Blog werde ich Ihnen erklären, wie Sie einen Health Check durchführen können. in der Vergangenheit gab es viele verschiedene Möglichkeiten, um herauszufinden, ob ein WSO2 Container noch gesund ist. Zum Beispiel:

  • Bereitstellung von Verwaltungsdiensten, um Informationen über Datenquellen zu erhalten.
  • Bereitstellen eines Echo-Dienstes und Offenlegung über den Proxy.
  • Bereitstellung von JMX-Schnittstellen, die den Containern die volle Kontrolle geben.

Keiner der oben genannten Punkte sollte in Betracht gezogen werden, da sie potenzielle Sicherheitslücken darstellen.

Wenn ein einfacher Service auf dem Carbon-Container bereitgestellt wird, den ein Agent oder ein Skript regelmäßig lokal aufrufen kann, haben wir eine vollständige Kette zur Durchführung von Health Checks. Solch ein Service existiert bereits. Er heißt /api/health-check/v1.0/health REST API. Eingeführt mit WSO2 Identity Server v5.7.0 und verfügbar gemacht durch WUM-Updates für v5.5.0 und v5.6.0 des Identity Servers. Mit dieser API ist es möglich, Health Checks zu konfigurieren: 

  • HTTP/HTTPs-Verbindungen
  • JDBC für gängige Datenquellen
  • Verbindungsstatus des Benutzerspeichers

Da es sich bei der Health-Check-API um eine generische, auf Carbon-Containern basierende API handelt, stellt WSO2 Richtlinien für die Bereitstellung auf allen WSO2-Produkten zur Verfügung, solange diese minimal auf Java 8 basieren und von WSO2 Carbon 4.4.x abhängig sind. Für die Bereitstellung der API werden ein OSGi-Modul, eine WAR-Datei und eine Konfigurations-XML-Datei benötigt. Wir können also beispielsweise Health Checks für komplette verteilte APIM-Setups durchführen, bei denen wir mehrere Carbon-Container wie Traffic Manager, Gateways, Publisher und Store, Identity Server (Key Manager) oder einen Cluster von Enterprise Integrator-Modulen einsetzen. Ganz wie Sie wünschen.

Internal Network Health check

Wichtiger Hinweis

Die Health-Check-API ist eine offene API. Es ist keine Authentifizierung/Autorisierung erforderlich. Diese API sollte niemals nach außen hin offengelegt werden. Halten Sie sie als internen Prozess hinter der Firewall / dem Proxy.

Wie geht es weiter?

Die JSON-Antwortnachricht der Health-check API gibt Auskunft über den aktuellen Status des Carbon-Containers. Sie können das API häufig abfragen (z.B. alle 5 Sekunden) und die JSON-Antwortnachrichten in einer Health-Check-Protokolldatei speichern. So können Sie zum Beispiel den ELK-Stack verwenden, um diese Protokolldatei abzuhören. Sie können ein Skript anwenden, das die API regelmäßig abfragt, um Änderungen im Status des Carbon-Container-Zustands zu erkennen und Warn-E-Mails zu versenden, wenn etwas nicht stimmt. Schauen Sie sich im Blog meines Kollegen Vinay ein Skript zu Health Check für Webserver und Dienste mit WSO2 an. Sie können diverse Monitor-Lösungen prüfen, wie Sie die API integrieren und die Alarmierung bei bestimmten Statusänderungen konfigurieren können. Die Entscheidung hängt von Ihren eigenen Produktpräferenzen und Ihrer individuellen Architektur ab.

Vollständige Einrichtungsrichtlinien und Informationen über die Health-Check-API finden Sie hier. Bei weiteren Fragen zögern Sie bitte nicht, uns zu kontaktieren!