Ustats-Modul: Statistik der Backend-Anfragen

    Grüße

    In diesem Artikel wird ein neues Modul für Nginx beschrieben, mit dem der Benutzer Statistiken zum Serverzugriff auf Backends erfassen und bereitstellen kann. Unter den Schnittdetails finden Sie Anwendungsbeispiele, Screenshots, Links sowie die Entstehungsgeschichte.


    Die Geschichte


    Vor nicht allzu langer Zeit kam die Server-Support-Abteilung unseres Unternehmens zu dem Schluss, dass es Zeit war, etwas zu ändern. Genauer gesagt, es war notwendig, die Probleme mit der Verteilung der erhöhten Last zu lösen - unsere Fronten begannen, ihre Aufgabe mühsam zu bewältigen.

    Mit Hilfe von JMeter haben wir Nginx, HAProxy, Brocade Server Iron ADX 1000 und eine Reihe anderer Balancer am Stand gefahren. Das Hauptauswahlkriterium war die Fähigkeit, ungefähr 50.000 gleichzeitige SSL-Sitzungen in Spitzenzeiten zu beenden. Nach Langzeittests verschwanden aus verschiedenen Gründen alle Optionen mit Ausnahme von Nginx und dessen Wettbewerber Brocade Server, und am Ende blieb nur die erste übrig. Andere Faktoren, die für Nginx ausschlaggebend waren, waren die Flexibilität der Konfiguration und die Leichtigkeit.

    Das problem


    Zuvor verwendeten wir HAProxy an einigen Stellen als Balancer. Nach dem Umstieg auf nginx wurde klar, dass es uns an aussagekräftigen Statistiken zur Arbeit mit Backends mangelt. Tatsache ist, dass derselbe HAProxy über solche Statistiken verfügte, und mit deren Hilfe wir die Probleme auf den Backends verfolgten und schnell darauf reagierten. Mit dem neuen Balancer sind wir wie ohne Hände ohne diese Statistiken gelandet. stub_status und ähnliche Module passten nicht zu uns, weil Ihre Funktion besteht darin, Statistiken nicht im Kontext eines separaten Upstreams, sondern des Servers als Ganzes anzuzeigen. Für jedes Upstream / Backend wollten wir Daten über Parameter wie die Anzahl der Aufrufe an jedes Backend und die Anzahl der HTTP-Fehler 499/500/503 und TCP haben. Später wurde diese Liste erweitert.

    Lösung


    Da wir keine vorgefertigten Lösungen für unser Problem gefunden haben, wurde versucht, ein Modul zu schreiben, das die erforderlichen Informationen in visueller Form bereitstellt. Der Versuch schien mir ein Erfolg zu sein, und das Ergebnis der Arbeit war das Modul ustats ( Upstream Statistics ).

    Was sind die Statistiken?

    Mit ustats können Sie Statistiken zu Back-End-Metriken wie z
    • Die Anzahl der Anfragen .
    • Fehler 499/500/503 .
    • Die Anzahl der HTTP-Zeitüberschreitungen beim Lesen und Schreiben .
    • Die Anzahl der TCP-Verbindungsfehler .
    • Fehlerzeitgeber (fail_timeout) . In nginx wird dieser Parameter von der gleichnamigen Direktive konfiguriert und bestimmt den Zeitraum, in dem mehrere erfolglose Aufrufe des Backends nacheinander erfolgen müssen (die genaue Nummer wird von der Direktive max_fails angegeben). Danach wird das Backend auf die Blacklist gesetzt und es wurden keine Aufrufe mehr durchgeführt time fail_timeout. Normalerweise weiß der Administrator selbst, welche Zeitüberschreitungen in seiner Serverkonfiguration vermerkt sind, aber es schien uns dennoch eine gute Idee zu sein, sie vor Augen zu haben.
    • Die Anzahl der erfolglosen Versuche, mit dem Backend zu arbeiten (Anzahl der fehlgeschlagenen Versuche). Innerhalb von nginx wird für jedes Backend ein Zähler für fehlgeschlagene Versuche geführt. Diese Zahl gibt an, wie oft nginx während eines Timeout-Fehlers versucht hat, am Backend anzuklopfen, und was als Fehler zu betrachten ist, siehe die Beschreibung der proxy_pass-Direktive. Das Funktionsprinzip des Zählers ist recht einfach. Wenn nginx im Begriff ist, eine Anfrage umzuleiten, wird zuerst geprüft, welches Backend als nächstes in der Zeile steht (ob es sich um einen Round-Robin-Ausgleich handelt), der Status überprüft (auf der schwarzen Liste oder nicht) und wenn das Backend "ignoriert" wird, wird der Zeitpunkt des letzten Ausfalls angezeigt . Wenn die Fail_timeout-Zeit seitdem bereits abgelaufen ist, wird der Zähler für erfolglose Versuche für das Back-End zurückgesetzt und die Anforderung gesendet. Wenn das Backend nicht auf der schwarzen Liste war, wird die Anfrage sofort gesendet und der Zähler kann je nach Zeit zurückgesetzt werden.
    • Die maximale Anzahl fehlgeschlagener Aufrufe (max_fails) . Definiert den Schwellenwert für die Anzahl der fehlgeschlagenen Versuche, mit dem Backend zu arbeiten, bei deren Erreichen das Backend für einen Zeitraum von fail_timeout auf die schwarze Liste gesetzt wird. Dieser Parameter wird auch in der Nginx-Konfiguration angegeben, und der Übersichtlichkeit halber haben wir seine Anzeige in der Statistik hinzugefügt.
    • Der Zeitpunkt des letzten erfolglosen Aufrufs des Backends. Sein Zweck sollte sich aus den vorhergehenden Absätzen ergeben :)

    Zusätzliche Funktionen

    Außerdem kann ustats anzeigen, welche Backends derzeit auf der schwarzen Liste stehen. Ich stelle fest, dass das Backend nicht so verstanden wird, wie es in der Nginx-Konfiguration von der Server-Direktive angegeben wird, sondern direkt die Adresse, in die der in der Direktive angegebene Name aufgelöst wird. Wenn im DNS mehrere Adressen unter einem Namen aufgeführt sind, zeigt das Modul diese als separate Backends an (ohne zu vergessen, von welchem ​​Namen sie stammen).

    Zusätzlich zum Hervorheben von Backends von der Blacklist hebt ustats Server hervor, d.h. beschrieben in nginx config als
    ...
    server some.server.name down;
    ...
    

    Und schließlich können Sie mit dem Modul den Server über die Weboberfläche direkt während des Betriebs über die Nginx-Topologie ein- und ausschalten. Änderungen werden nicht in der Konfiguration gespeichert und sollen die Implementierung dieser erleichtern. arbeitet mit vorübergehender Trennung von Backends. Ich möchte Sie warnen: ustats bietet keinen Schutz vor der unbefugten Ausführung dieser Aktion. Sie müssen also sicherstellen, dass eine zufällige Person nicht die Hälfte der Backends von Ihrer Website ausschließt. :)

    Anwendungsfälle

    Es gibt zwei von ihnen. Erstens stellt das Modul alle Statistiken in Form einer Webseite mit einer Tabelle zur Verfügung, deren Anzeige an einem beliebigen Ort abgelegt werden kann, wie z. B. stub_status:
    lage / ustats {
    	ustats auf;
    	...
    }
    

    Die Seite wird automatisch aktualisiert und das Aktualisierungsintervall (in Millisekunden) kann in der Konfiguration konfiguriert werden:
    ...
    ustats_refresh_interval 7000
    ...
    

    Im zweiten Szenario wird das Modul als Datenquelle für andere Überwachungsdienstprogramme verwendet. In diesem Fall werden die entsprechenden Anfragen an ihn gerichtet, woraufhin er eine gewöhnliche XML mit den erforderlichen Informationen zurückgibt. Sie können Daten für einen Upstream oder für ein Backend anfordern. Zum Beispiel Anfrage

    / ustats? u = offline
    

    gibt Daten für alle Backends im Upstream offline und auf Anfrage zurück

    / ustats? u = break & b = the_mold
    

    Die Daten auf dem the_mold- Backend in der Upstream- Pause werden zurückgegeben . Wenn der Upstream oder das Backend nicht gefunden wird, wird dies in der Antwort-XML angegeben.

    Einige Bilder


    Um nicht unbegründet zu sein, gebe ich ein paar Screenshots der Ergebnisseite des Moduls. Es gibt 2 Upstream-Einstellungen in Nginx aus dem ersten Bild, in denen alle Server lokal sind, die auf demselben Nginx erstellt wurden, mit Ausnahme des Www-Servers. Er wird in Yandex-Adressen aufgelöst.

    Auf dem Bild sehen Sie die grauen Linien. Dies sind die mit gekennzeichneten Backends "Down" in der Nginx-Konfiguration oder deaktiviert über die Modul-Seite. Bisher keine Zahlen.

    Im zweiten Screenshot hoben die roten Linien drei Backends aus dem ersten Upstream hervor, die sich in der schwarzen Liste befanden, wodurch verhindert wurde, dass Anforderungen an sie gesendet wurden.

    Zusammen mit der Tatsache, dass drei weitere Backends ausgeschaltet waren, übernahm das einzige verbleibende die Last.

    Schließlich wurde die letzte Aufnahme im Arbeitsbereich von unserer Seite gemacht:

    Das Bild zeigt eine weitere Funktion, die ich noch nicht erwähnt habe. Der Upstream von unten ist etwas heller - dies ist ein Zeichen dafür, dass sie implizit in der Konfiguration definiert sind, d. H. nicht so
    Upstream give_me_a_name {
      ...
    }
    

    und so
    lage / ort {
    ...
    proxy_pass http://192.168.0.75:8080
    ...
    }
    


    Zusammenfassung


    Wir haben den Quellcode des Moduls auf der Google Code-Seite veröffentlicht. Das Repository enthält die Patch-Datei für nginx, die Datei mit der Quell- und Konfigurationsdatei. Auf der Modulseite finden Sie Installationsanweisungen, dort werden auch zusätzliche Konfigurationsanweisungen beschrieben. Die aktuelle Version des Moduls wurde mit Nginx Version 0.8.53 in Chrome, Firefox und Opera getestet. Abschließend muss ich sagen, dass ustats nur ein Versuch ist, den grundlegendsten Mechanismus zum Anzeigen von Daten zur Arbeit mit Backends zu nginx hinzuzufügen. In Zukunft würde ich gerne solche nutzlosen Module im Hauptserverzweig sehen, wie zum Beispiel vor den Backends für Health Checks.

    Jetzt auch beliebt: