Discourse-health-check: panoramica one-shot da CLI del tuo server Discourse

Un piccolo script bash che ho creato per il mio forum personale, che fornisce una panoramica rapida dello stato di salute del server Discourse. Lo condivido con chiunque trovi utile questo tipo di panoramica rapida.

Verifica le risorse di sistema: Docker, servizi Discourse (Postgres, Redis, Nginx, Unicorn, Sidekiq), freschezza dei backup, TLS e sicurezza di base. Si conclude con un riepilogo pass / warning / critical e un codice di uscita adatto per cron.

Installazione

curl -O https://raw.githubusercontent.com/haydenjames/discourse-health-check/main/discourse-health-check.sh
chmod +x discourse-health-check.sh
sudo ./discourse-health-check.sh

Codice sorgente, opzioni ed esempio di configurazione cron nel README:


Nuova versione v1.0.4:

Due correzioni:

  1. Discourse ha sostituito Unicorn con Pitchfork (predefinito nella versione 2026.2, Unicorn rimosso completamente nella 2026.4), quindi il controllo del server web ora rileva entrambi. Grazie a @RGJ per aver segnalato questo problema a giugno.

  2. Le verifiche dei servizi stavano abbinando la propria riga di comando. pgrep -f <nome> faceva sì che pgrep si abbinasse a se stesso, quindi il controllo risultava superato indipendentemente dal fatto che il servizio fosse effettivamente attivo. Sidekiq segnalava “in esecuzione” incondizionatamente dalla versione 1.0.0. Poteva essere fermo e tu avresti comunque ricevuto un controllo verde e un codice di uscita 0 da cron. Stessa causa radice del falso positivo di Puma nella versione 1.0.1, che si è rivelato essere stato rinominato piuttosto che corretto.

9 Mi Piace

Discourse non esegue Puma.

3 Mi Piace

Unicorno. Fatto, grazie.

1 Mi Piace

Pitchfork ai giorni nostri!!

2 Mi Piace

Ottima proposta, grazie!

Per i backup, ti suggerirei di verificare l’ultimo backup per vedere se è stato letto dopo essere stato scritto. Questo è un indicatore indiretto per controllare se è stato copiato fuori sede. (O, se non si verifica solo l’ultimo, forse controllarli tutti.)

Se nessun backup è stato copiato fuori sede da una settimana, vale la pena emettere un avviso.

(Credo che tu possa sottrarre stat -c %Y da stat -c %X o forse semplicemente confrontarli. Saranno diversi se il file di backup è stato letto dopo essere stato scritto.)

5 Mi Piace

@Ed_S Ottima suggerimento. Aggiunto nella v1.0.2. Confronta atime e mtime sull’ultimo backup e avvisa se non è stato letto dall’ultimo aggiornamento, con un controllo noatime per saltare in modo pulito quando atime non è affidabile. Ti abbiamo inserito nei crediti, grazie!

4 Mi Piace