Hallo liebe Proxmox-Community,
ich habe ein Problem mit TCP-Timeouts auf den VMs. Ich beschreibe das ganze mal: Vor inzwischen zwei Monaten habe ich in Checkmk aktive Checks eingerichtet. Diese überprüfen ob eine Website per https erreichbar ist (1. Check) und ob das Zertifikat noch eine ausreichend lange Restlebensdauer hat. (2. Check). Diese Checks habe ich für unsere Kunden und unsere Infrastruktur eingerichtet. Von da an habe ich regelmässig nachdem alle Checks erstellt waren, d.h. etwa 1-2 mal pro Tag eine Fehlermeldung von Checkmk bekommen. Ich kopiere die hier anonymisiert mal rein:
Wenn ich die Email mit der Fehlermeldung bekommen habe während ich am Computer saß, habe ich die entsprechende Seite aufgerufen und festgestellt, daß diese erreichbar war. Der gemeldete Ausfall ist auch sehr kurz, gleich eine Minute später kriege ich wieder ein "Ok" von Checkmk. Ich vermute der Timeout dauert nur wenige Sekunden. Ich hielt die Emails am Anfang für False Positives und habe sie ignoriert. Vor einigen Wochen ist das ganze einem meiner Kollegen bei einer (wichtigen) Jitsi-Konferenz passiert worauf die Teilnehmer im Idealfall neu laden oder im nicht so idealen Fall neu joinen mussten. Seit dem hat das Problem für mich eine höhere Priorität und ich glaube auch nicht mehr, daß es False Positives sind - die Ausfälle sind nur sehr kurz und wieder weg bevor ich die Seite im Browser öffnen kann.
Ich habe das Problem erst an anderen Stellen gesucht. Ich habe in den Nginx-Logs gesucht und dort einen Fehler gefunden, der aber nach längerer Beobachtung viel zu selten auftritt um mit den Timeouts etwas zu tun zu haben. In den letzten Wochen hinterließen die Timeouts keine Meldungen im Nginx-Log. Die Nginx-Versionen in Debian sind ja nicht immer ganz aktuell. Ich habe also schnell ein kleines Playbook für Ansible zusammengebastelt, daß die bestehende alte Stable-Version durch eine aktuellen Mainline-Version ersetzt. (Mainline bekommt mehr Bugfixes, diese werden nur bei Bedarf nach Stable geportet, das "Stable" vor allem in Hinsicht auf Third-Party-Plugins ist - die wir nicht verwenden.) Leider hat das keine Verbesserung gebracht - die TCP-Timeouts bleiben. Ich habe dann als Schuss ins Blaue den Kernel des oben genannten Matomo-Systems auf eine aktuelle Version aus den Bullseye-Backports gehoben, was aber auch nichts gebracht hat.
Ich beschreibe nochmal mein Setup. Ich habe hier einen recht jungen Proxmox-Drei-Node-Cluster (ist aber nicht mein erster Proxmox-Cluster) auf dem erst etwa 60 VMs laufen. Die VMs sind bis auf zwei Ausnahmen Debian 11.5, immer in der aktuellen Version. Darauf laufen üblicherweise Nginx, verschiedene Versionen von PHP-FPM und Mariadb. Auf dieser Basis entwickelt mein Arbeitgeber Webapps und Websites, entweder mit Typo3 oder im Fall der Anwendungen mit Laravel. Zusätzlich haben wir noch solche PHP-Anwendungen wie Nextcloud oder eben das bereits erwähnte Matomo laufen. Die VMs werden mit Ansible provisioniert und weisen eine recht hohe Homogenität auf. (Natürlich verbessere ich gelegentlich auch mal was in meinen Ansible-Rollen). Unser Netz haben wir vom Hostingprovider gemietet, die Maschinen sind direkt von außen verfügbar und werden durch die integrierte Proxmox-Firewall geschützt.
Ich habe gestern Kontakt mit unserem Hosting-Provider aufgenommen und wir haben uns ein paar Punkte überlegt, die man ausprobieren sollte:
- ich habe die betroffenen VMs gestern auf andere Nodes in den Cluster gezogen
- ich habe für die stark betroffenen VMs HA ausg(sic!)schaltet. Das ist sonst für unseren A-Kunden und für unsere Infrastruktur aktiv.
- die neuen Nginx-Versionen hatte ich ja bereits erwähnt
Hat leider nichts gebracht, heute morgen bin ich wieder mit einer Fehlermeldung begrüßt worden. Sie scheinen sich, wenn ich die letzte Woche betrachte, auf eine kleinere Anzahl von Maschinen eingeschossen zu haben, im wesentlichen Matomo, Gitlab und unsere Jitsi-Instanzen.
Mein Gegenüber bei unserem Hostingprovider hat als erster die Vermutung geäußert, daß das Problem mit Proxmox zusammenhänge könnte. Wie sehen das die Proxmox-Entwickler? Was sollte ich ausprobieren um das Problem noch weiter einzugrenzen oder im Idealfall ganz zu beheben?
Viele Grüße
Stefan Schumacher
PS: Boote gleich mal die Nodes neu nachdem ich die VMs wegmigriert habe. Ist sowieso mal fällig.
ich habe ein Problem mit TCP-Timeouts auf den VMs. Ich beschreibe das ganze mal: Vor inzwischen zwei Monaten habe ich in Checkmk aktive Checks eingerichtet. Diese überprüfen ob eine Website per https erreichbar ist (1. Check) und ob das Zertifikat noch eine ausreichend lange Restlebensdauer hat. (2. Check). Diese Checks habe ich für unsere Kunden und unsere Infrastruktur eingerichtet. Von da an habe ich regelmässig nachdem alle Checks erstellt waren, d.h. etwa 1-2 mal pro Tag eine Fehlermeldung von Checkmk bekommen. Ich kopiere die hier anonymisiert mal rein:
| Host | matomo.justanotherdomain.com (matomo.justanotherdomain.com) |
| Service | HTTPS Webserver |
| Event | OK → CRITICAL |
| Address | 195.34.***.*** |
| Date / Time | Wed Oct 5 06:25:46 CEST 2022 |
| Summary | CRITICAL - Socket timeout after 10 seconds |
| Details | |
| Host Metrics | rta=0.176ms;200.000;500.000;0; pl=0%;80;100;; rtmax=0.380ms;;;; rtmin=0.100ms;;;; |
| Service Metrics |
Wenn ich die Email mit der Fehlermeldung bekommen habe während ich am Computer saß, habe ich die entsprechende Seite aufgerufen und festgestellt, daß diese erreichbar war. Der gemeldete Ausfall ist auch sehr kurz, gleich eine Minute später kriege ich wieder ein "Ok" von Checkmk. Ich vermute der Timeout dauert nur wenige Sekunden. Ich hielt die Emails am Anfang für False Positives und habe sie ignoriert. Vor einigen Wochen ist das ganze einem meiner Kollegen bei einer (wichtigen) Jitsi-Konferenz passiert worauf die Teilnehmer im Idealfall neu laden oder im nicht so idealen Fall neu joinen mussten. Seit dem hat das Problem für mich eine höhere Priorität und ich glaube auch nicht mehr, daß es False Positives sind - die Ausfälle sind nur sehr kurz und wieder weg bevor ich die Seite im Browser öffnen kann.
Ich habe das Problem erst an anderen Stellen gesucht. Ich habe in den Nginx-Logs gesucht und dort einen Fehler gefunden, der aber nach längerer Beobachtung viel zu selten auftritt um mit den Timeouts etwas zu tun zu haben. In den letzten Wochen hinterließen die Timeouts keine Meldungen im Nginx-Log. Die Nginx-Versionen in Debian sind ja nicht immer ganz aktuell. Ich habe also schnell ein kleines Playbook für Ansible zusammengebastelt, daß die bestehende alte Stable-Version durch eine aktuellen Mainline-Version ersetzt. (Mainline bekommt mehr Bugfixes, diese werden nur bei Bedarf nach Stable geportet, das "Stable" vor allem in Hinsicht auf Third-Party-Plugins ist - die wir nicht verwenden.) Leider hat das keine Verbesserung gebracht - die TCP-Timeouts bleiben. Ich habe dann als Schuss ins Blaue den Kernel des oben genannten Matomo-Systems auf eine aktuelle Version aus den Bullseye-Backports gehoben, was aber auch nichts gebracht hat.
Ich beschreibe nochmal mein Setup. Ich habe hier einen recht jungen Proxmox-Drei-Node-Cluster (ist aber nicht mein erster Proxmox-Cluster) auf dem erst etwa 60 VMs laufen. Die VMs sind bis auf zwei Ausnahmen Debian 11.5, immer in der aktuellen Version. Darauf laufen üblicherweise Nginx, verschiedene Versionen von PHP-FPM und Mariadb. Auf dieser Basis entwickelt mein Arbeitgeber Webapps und Websites, entweder mit Typo3 oder im Fall der Anwendungen mit Laravel. Zusätzlich haben wir noch solche PHP-Anwendungen wie Nextcloud oder eben das bereits erwähnte Matomo laufen. Die VMs werden mit Ansible provisioniert und weisen eine recht hohe Homogenität auf. (Natürlich verbessere ich gelegentlich auch mal was in meinen Ansible-Rollen). Unser Netz haben wir vom Hostingprovider gemietet, die Maschinen sind direkt von außen verfügbar und werden durch die integrierte Proxmox-Firewall geschützt.
Ich habe gestern Kontakt mit unserem Hosting-Provider aufgenommen und wir haben uns ein paar Punkte überlegt, die man ausprobieren sollte:
- ich habe die betroffenen VMs gestern auf andere Nodes in den Cluster gezogen
- ich habe für die stark betroffenen VMs HA ausg(sic!)schaltet. Das ist sonst für unseren A-Kunden und für unsere Infrastruktur aktiv.
- die neuen Nginx-Versionen hatte ich ja bereits erwähnt
Hat leider nichts gebracht, heute morgen bin ich wieder mit einer Fehlermeldung begrüßt worden. Sie scheinen sich, wenn ich die letzte Woche betrachte, auf eine kleinere Anzahl von Maschinen eingeschossen zu haben, im wesentlichen Matomo, Gitlab und unsere Jitsi-Instanzen.
Mein Gegenüber bei unserem Hostingprovider hat als erster die Vermutung geäußert, daß das Problem mit Proxmox zusammenhänge könnte. Wie sehen das die Proxmox-Entwickler? Was sollte ich ausprobieren um das Problem noch weiter einzugrenzen oder im Idealfall ganz zu beheben?
Viele Grüße
Stefan Schumacher
PS: Boote gleich mal die Nodes neu nachdem ich die VMs wegmigriert habe. Ist sowieso mal fällig.
Last edited:
