Ich bin hierher gekommen in der Hoffnung, eine Schritt-für-Schritt-Diagnose zu finden, wenn eine Discourse-Site unter der Bedingung „502 Bad Gateway“ steht. Es scheint, dass die einzigen Optionen in diese Richtung gehen:
Das Discourse-Update ist möglicherweise fehlgeschlagen, verwenden Sie ./launcher rebuild app.
Server aktualisieren und neu starten.
Das sind die Antworten, die wir von einem Support-Mitarbeiter der Stufe 1 oder einem E-Mail-Bot erhalten.
Was können wir sonst noch tun, um Protokolle einzusehen und genau zu sehen, warum die Umgebung abgestürzt ist? Mit diesen Informationen könnten wir lernen, wie wir das Problem in Zukunft vermeiden können.
Wäre es zum Beispiel angebracht, einen Cron-Prozess zu skripten, um Discourse gelegentlich anzupingen, und wenn die Antwort ein 502-Rückgabecode oder ein ähnlicher Code ist, automatisch neu zu erstellen?
Ein Neuaufbau scheint auch eine ziemlich brutale Methode zur Problemlösung zu sein. Es ist keine Diagnose.
Ich hoffe wirklich, dass jemand uns auf ein beliebtes Dokument „Diagnose von Discourse-Problemen“ hinweisen kann, das Dummköpfe wie ich übersehen haben.
Wenn man sich viele Beiträge hier durchliest, sind Forum-Administratoren typischerweise nicht die Ursache für 502er, sondern es handelt sich um einen Plugin-/Core-Fehler. Daher gäbe es nicht viel, was Sie tun könnten, um diese Probleme zu vermeiden.
Konsolenprotokolle helfen immer, sie können oft das problematische Plugin aufspüren.
Ich kann die Konsole auf diesem VPS öffnen, aber das Textfenster ist begrenzt.
Gibt es bestimmte Protokolle, die im Container oder im Betriebssystem überprüft werden können?
Gibt es bereits eine Art Ping-Prozess im Host-Betriebssystem oder im Container, der erkennt, wenn Prozesse ausgefallen sind?
Könnte ein einfacher Server-Neustart im Container ein guter Ansatz sein, anstatt einer vollständigen Neuerstellung?
Übrigens, ich verwende die neueste Beta/Entwicklerversion, daher ist es durchaus möglich, dass ein kürzliches Update den Server heruntergefahren hat, wie wir es in der Vergangenheit gesehen haben. Ich erinnere mich im Moment nicht, ob nicht standardmäßige Plugins installiert sind.
Ich habe die Freiheit, bei der Diagnose zu helfen, ohne dass unsere Community verärgert wird, obwohl wir in einigen Monaten zu stabileren Versionen wechseln müssen, nur um unsere Benutzer zufriedenzustellen. Wenn dies also etwas im Build ist, helfe ich gerne dabei, es zu finden.
Festplatte ist zu <50% belegt.
RAM bleibt meist im Bereich von 80-90%, Swap <40%. Ich vermute, hier liegt das Problem.
Logs befinden sich unter /var/discourse/shared/standalone/log/rails.
production.log und zugehörige komprimierte Dateien enthalten viele Transaktionsdetails. Was könnte ich suchen?
Es gibt überhaupt keine Einträge in production_error.log.
“Häufig”? Nein. Aber oft genug, um leicht störend zu sein und einen Beitrag hier zu veranlassen.
Ich habe syslog durchgesehen und nichts gesehen - ich bin mir nicht sicher, ob dort etwas wäre, wenn das Problem auf den Container beschränkt ist, wie es sein sollte.
Ich bin ein Docker-Noob, daher entschuldige ich mich, dass ich keine Informationen aus dem Container habe, aber ich werde gerne nach Anweisung nachschauen.
Ich denke, fast alle Threads hier über 502-Fehler treten auf, wenn Discourse ein Upgrade erhalten hat und nicht wieder zum Leben erwacht ist. Das Upgrade ist fehlgeschlagen oder der Administrator hat nicht lange genug gewartet, bis der Dienst hochgefahren ist.
Sagen Sie damit, dass Sie ein funktionierendes Discourse haben, keine Administratoraktion durchführen, aber es beginnt spontan, 502 zurückzugeben?
Und wenn das passiert, gibt es immer 502 zurück, bis es neu gestartet wird, oder funktioniert es intermittierend wieder?
