Discourse-health-check: visão geral em linha de comando do seu servidor Discourse

Um pequeno script em Bash que criei para meu próprio fórum, fornecendo uma visão geral rápida da saúde do servidor Discourse. Compartilho aqui caso alguém ache útil esse tipo de resumo rápido.

Verifica recursos do sistema: Docker, serviços do Discourse (Postgres, Redis, Nginx, Unicorn, Sidekiq), atualização dos backups, TLS e noções básicas de segurança. Termina com um resumo de aprovado / aviso / crítico e um código de saída adequado para uso no cron.

Instalação

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

Código-fonte, opções e um exemplo de configuração no cron estão no README:


Nova versão v1.0.4:

Duas correções:

  1. O Discourse substituiu o Unicorn pelo Pitchfork (padrão na versão 2026.2, com o Unicorn removido completamente na 2026.4), então a verificação do servidor web agora detecta ambos. Obrigado @RGJ por sinalizar isso ainda em junho.

  2. As verificações de serviço estavam correspondendo à sua própria linha de comando. pgrep -f <nome> fazia com que o pgrep correspondesse a si mesmo, e a verificação passava independentemente de o serviço estar realmente em execução. O Sidekiq estava relatando “em execução” incondicionalmente desde a versão 1.0.0. Ele poderia estar parado, mas você ainda receberia um indicador verde e o código de saída 0 do cron. Mesma causa raiz do falso positivo do Puma na versão 1.0.1, que acabou sendo renomeado em vez de corrigido.

9 Curtiram

O Discourse não roda o Puma.

3 Curtiram

Unicórnio. Corrigido, obrigado.

1 Curtiu

Pitchfork hoje em dia!!

2 Curtiram

Ótima sugestão, obrigado!

Para backups, sugiro verificar o backup mais recente para ver se ele foi lido desde que foi escrito. Isso serve como um indicador para saber se foi copiado para outro local. (Ou, se não for verificar apenas o mais recente, talvez verificar todos.)

Se nenhum backup tiver sido copiado para outro local há uma semana, isso merece um alerta.

(Acho que você pode subtrair stat -c %Y de stat -c %X ou talvez apenas compará-los. Eles serão diferentes se o arquivo de backup foi lido desde que foi escrito.)

5 Curtiram

@Ed_S Ótima sugestão. Incluído na versão 1.0.2. Compara atime vs mtime no backup mais recente e alerta se não foi lido desde que foi gravado, com uma verificação noatime para ignorar corretamente casos em que atime é pouco confiável. Você foi creditado, obrigado!

4 Curtiram