In der Konfiguration unserer Anwendung fungiert nginx als Reverse-Proxy vor gunicorn.
Unsere Anwendung antwortet auf Frontend-Anfragen mit im Allgemeinen kleinen Antworten … aber einige Endpunkte generieren Antworten, die größer als eine Speicherseite (4 KB) sind.
Wenn dies geschieht, protokolliert nginx diese Warnung:
an upstream response is buffered to a temporary file
/path/to/nginx/proxy_temp/4/86/0000000864 while reading upstream,
client: 1.2.3.4, server: api.ourdomain.com, request: "GET /pdf/..."
Unsere Nginx-Protokolle werden mit dieser Warnung überflutet - und soweit ich sehe, sind die einzigen Lösungen, um diese Warnung aus unseren Protokollen verschwinden zu lassen,schlechte Lösungen:
Ich kann nginx
proxy_max_temp_file_sizeauf 0 setzen – und damit grundsätzlich das Puffern von relativ großen Antworten deaktivieren. Dies würde das Puffern in Dateien stoppen – aber es würde auch bedeuten, dass bei Endpunkten, die große Antworten generieren (z. B. solche, die PDFs generieren und Antworten von 1–2 MB erzeugen), ein langsam arbeitender Client den entsprechenden Gunicorn-Worker blockieren würde … Tatsächlich würde es bei N Gunicorn-Workern nur N Clients erfordern, die PDFs hinter langsamen Netzwerkverbindungen generieren, und unsere Anwendung würde ausfallen …Ich kann das auf mehr als 4 KB erhöhen
proxy_buffer_size(also eine Speicherseite). Ich bin ziemlich sicher, dass dies die Leistung von Nginx stark beeinträchtigen würde – 70 % unserer Antworten passen tatsächlich in 4 KB, und wir würden Nginx zwingen, ... was? 2 MB Puffer für jede einzelne davon zuzuweisen, nur um für die gelegentliche PDF-generierende Anfrage bereit zu sein? BEARBEITEN: Tatsächlich ist dies überhaupt keine Option – Michael (unten) hat angemerkt, dass die einzigen zulässigen Werte 4K und 8K sind.Ich könnte es abschalten
proxy_buffering– aber das ist genauso schlimm wie die erste Lösung (langsame Clients => Tod).
Im Wesentlichen überflutet nginx unsere Protokolle mit etwas, das wir WOLLEN – temporäres Puffern in Dateien, wenn die Antworten umfangreich sind.
Wir möchten lediglich verhindern, dass unsere Protokolle überflutet werden, indem wir es als keine echte Warnung „markieren“ (ich bin nicht einmal sicher, warum dies eine Warnung ist – vor welcher „schlimmen Sache“ warnt es uns?)
Gibt es außer dem Bearbeiten nginxdes Quellcodes und dem Neukompilieren noch eine andere Lösung, die ich übersehe?
Antwort1
Dies ist ein Ergebnis der Protokollebene der error_log-Direktive von Nginx.
https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
error_log logs/error.log warn;
Es werden Meldungen der Stufen „Warnen“, „Kritischer Fehler“, „Alarm“ und „Notfall“ protokolliert.
Die Standardeinstellung des Fehlerprotokolls ist global. Um sie zu überschreiben, platzieren Sie die Direktive error_log im Hauptkonfigurationskontext (oberste Ebene). Einstellungen im Hauptkontext werden immer von anderen Konfigurationsebenen übernommen. Die Direktive error_log kann auch auf den Ebenen http, Stream, Server und Standort angegeben werden und überschreibt die von den höheren Ebenen übernommene Einstellung.
Diese Zeile zum Puffern befindet sich auf der Warnebene:
[warn] 30055#0: *1428 an upstream response is buffered to a temporary file
Wenn Sie also sicherstellen, dass Ihr Fehlerprotokolllevel nicht auf „Warnen“ eingestellt ist, also den Standardwert beibehalten oder verringern, werden Sie diese Warnung nicht mehr sehen. Eine der folgenden Lösungen unterdrückt sie:
Belassen Sie die Standardeinstellung (Stufe „Fehler“ und höher):
error_log logs/error.log;
Gleiche Sache:
error_log logs/error.log error;
Sie können den Schwellenwert auch über error, bis auf crit, alert, und erhöhen emerg.