Ich habe erfolglos versucht, bei StackOverflow nachzufragen, daher hoffe ich, dass diese Community mir helfen kann, dieses Problem zu finden. Wir haben eine Web-App, auf die viele Leute im Unternehmen zugreifen müssen. Gelegentlich scheint die Web-App nicht mehr auf Anfragen zu reagieren.
Wenn beispielsweise eine Ressourcenindexseite (z. B. eine Auftragstabelle) während eines Ausfalls versucht, die Ressourcenliste zu aktualisieren, fordert sie die Daten über eine API an, die Anforderung schlägt jedoch nach einer Weile stillschweigend fehl. Die App wird durch lang anhaltende Anfragen an praktisch alle Mitarbeiter des Unternehmens gleichzeitig für mehrere Minuten unerreichbar, aber der Zugriff auf die App während dieser Ausfall-/Verlangsamungsphase von einem anderen Netzwerk (z. B. mobile Daten) aus funktioniert. Auch andere Websites scheinen während dieser Zeit nicht betroffen zu sein.
Die Netzwerkregisterkarte des Browsers zeigt die Anfragen nach 20-40 Sekunden als fehlgeschlagen an, aber es gibt keinen Statuscode. Der Statustext bei Auswahl der Anfrage lautet „fehlgeschlagen net::ERR_CONNECTION_TIMED_OUT“. Wenn Sie während der Verarbeitung nicht auf die Anfrage klicken und die Details später öffnen, wird auf der Registerkarte „Zeit“ anscheinend angezeigt, dass sie in der Phase „Angehalten“ hängen geblieben ist. Wenn Sie jedoch während der Verarbeitung die Anfragedetails öffnen, wird stattdessen angezeigt, dass sie in der Phase „Erste Verbindung“ hängen geblieben ist. Dies lässt die Registerkarte „Zeit“ der Anfragedetails unzuverlässig erscheinen, da ihre Anzeige davon abzuhängen scheint, ob ich die Anfrage während der Verarbeitung überprüft habe oder nicht.
Server-Setup:
Der Server scheint während dieser Zeit keine größere Überlastung zu zeigen – maximal 30 % CPU-/Speicherauslastung. Der Server läuft auf einem Digital Ocean Droplet und verwendet nginx zum Hosten der Laravel-App.
Was ich überlegt/versucht habe: Firmenverbindungen kommen von derselben IP. Die App selbst hat zwar die Drosselung aktiviert, diese ist jedoch an die Benutzer-ID gebunden, gibt die Fehlermeldung „Zu viele Versuche“ und den Statuscode 429 zurück. Wenn es sich um eine Drosselung handelt, sollte diese nicht auf App-Ebene erfolgen, da eine Drosselung dort an der Fehlermeldung und dem Statuscode erkennbar ist.
Ich habe versucht, die Nginx-Konfigurationen zu überprüfen, um eine aktivierte Drosselung zu finden, aber sie scheint nicht explizit aktiviert zu sein, es sei denn, Nginx erzwingt eine Art Standard. Aber selbst wenn sie aktiviert ist, sollte Nginx, soweit ich das verstanden habe, auch 429/503 zurückgeben. Aber in unserem Fall scheinen keine Fehler oder Codes zurückgegeben zu werden.
Ich habe versucht, sowohl DigitalOcean als auch den ISP des Unternehmens zu kontaktieren, und beide behaupten, keinerlei Drosselungs-/Ratenbegrenzungsmechanismen zu verwenden. Der Netzwerkadministrator des Unternehmens sagt auch, dass ein solcher Mechanismus nicht läuft.
Was kann ich tun, um das Problem zu debuggen/zu untersuchen? So wie ich es verstehe, kann das Problem überall liegen, von der Nginx-Konfiguration bis zur Drosselung durch den ISP-Provider. Ich denke, dass es sich im Moment um eine Art Drosselung handelt, aber es könnte sein, dass ich etwas übersehe.
Antwort1
Verwenden Sie Diagnosetools, um Engpässe oder Fehler in verschiedenen Teilen Ihrer Infrastruktur (nginx, Digital Ocean, internes Netzwerk) zu identifizieren. Zeichnen Sie während des Ausfalls Daten auf, um sie später zu analysieren.
# nginx logs
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
# Network diagnostics (replace x.x.x.x with server IP)
traceroute x.x.x.x
mtr --report --report-cycles=10 x.x.x.x
# Laravel logs
tail -f /path/to/laravel/storage/logs/laravel.log
# Digital Ocean droplet metrics
# Check droplet metrics via Digital Ocean dashboard
So können Sie feststellen, ob das Problem in Ihrem Nginx-Setup, Ihrem Digital Ocean Droplet, Ihrem internen Netzwerk oder anderswo liegt. Protokolle und Netzwerkdiagnosen können Hinweise liefern.
Auf Kommentar antworten
• So überprüfen Sie, ob mit dem Befehl Regeln zur Verkehrsgestaltung oder -drosselung angewendet werden tc, die den Fluss des Netzwerkverkehrs beeinflussen könnten:
# Display all the traffic control (qdisc) settings on all interfaces:
tc qdisc show dev [interface-name]
# Example for eth0 interface:
tc qdisc show dev eth0
Wenn bestimmte Verkehrskontrollregeln angewendet werden, werden sie hier aufgelistet. Sie können weiter analysiert werden, um festzustellen, ob sie zu den gemeldeten Zeitüberschreitungen beitragen.