It would be nice to have some sort of health check API. We recently faced an issue with an update and Discourse was producing 500 errors.
However, curl returned 200:
curl -I https://forum.gitlab.com
HTTP/2 200
server: nginx
2 „Gefällt mir“
This exists, see
/srv/status
15 „Gefällt mir“
Ah, thank you! I was searching “health check” and that didn’t yield any results.
2 „Gefällt mir“
Der Beitrag führt zu 404. Was sind die Endpunkte?
Ich habe meinen Beitrag aktualisiert.
2 „Gefällt mir“
Eigentlich glaube ich nicht, dass /srv/status Migrationsprobleme wie das oben erwähnte erkennen würde…
(und es wäre ziemlich schwierig, einen Check zu erstellen, der solche Probleme erfasst)
2 „Gefällt mir“
Ja… /srv/status ist als sehr kostengünstiger Test vorhanden. Es wird lediglich sichergestellt, dass der Middleware-Stack der Anwendung funktioniert.
Um Probleme bei automatischen Deployments zu erkennen, empfehle ich die Überwachung von 200er-Statuscodes. Bei einem starken Anstieg von Nicht-200er-Antworten sollte eine Warnung ausgelöst werden.
5 „Gefällt mir“
Wäre https://discourse.example.org/srv/status ein guter Ort, um einen Uptime-Monitor hinzuzufügen? Ich denke, es reicht vielleicht nicht aus, nur zuverlässig zu messen, ob die Seite online ist, aber es wäre schön, etwas zu haben, das weniger Last auf dem System für Überwachungszwecke verursacht.
(Alternativ: Gibt es vielleicht Pläne, die auf diesem Endpunkt aufgeführten Komponenten zu erweitern?)
3 „Gefällt mir“
Ja, das ist ein vernünftiger Ort. Du kannst auch auf ein bestimmtes Thema zeigen und nach Text suchen, wenn du etwas ausgefalleneres möchtest.
7 „Gefällt mir“
Ja, wir haben bisher /about verwendet, neigen aber dazu, stattdessen dies zu nutzen.
Mein alter Ops-/On-Call-Verstand hat mich daran erinnert, dass es immer noch interessant sein könnte (und gelegentlich hilfreich bei der Fehlersuche), wenn es so etwas wie folgendes wäre:
db ok
middleware ok
whatever-else ok
...
all systems ok
4 „Gefällt mir“