O tópico da comunidade IceWhale de 2023 sobre o Uptime Kuma é mais uma introdução do que um guia de instalação. A publicação diz que o tutorial aborda a instalação no CasaOS, enquanto as respostas se centram nas razões pelas quais as pessoas valorizam o Uptime Kuma: notificações de interrupções, monitorização em produção de serviços não críticos e monitores push. O texto do fórum não conserva a configuração passo a passo do instalador.
Por isso, uma página atual deverá manter o contexto do CasaOS e os casos de utilização da comunidade, utilizando os requisitos Docker mantidos pelo Uptime Kuma para a implementação propriamente dita.
O que o Uptime Kuma acrescenta a um servidor doméstico
O Uptime Kuma é um painel de monitorização autoalojado. Pode testar se um site, serviço TCP, endpoint DNS, destino de ping, serviço relacionado com Docker ou tarefa baseada em push está a funcionar corretamente e enviar notificações quando o estado muda.
As respostas originais destacaram repetidamente as notificações como o valor prático. Um painel é útil, mas o principal benefício é descobrir que um serviço está indisponível antes de alguém em casa o comunicar.
Utilize o contentor atual do Uptime Kuma
As instruções atuais de implementação do Uptime Kuma utilizam a imagem mantida louislam/uptime-kuma:2. A aplicação Web escuta na porta 3001 e armazena a base de dados persistente e a configuração em /app/data.
Para uma aplicação personalizada atual no CasaOS, traduza as definições de instalação Docker mantidas do Uptime Kuma para o formulário de aplicações do CasaOS, em vez de utilizar uma etiqueta de imagem antiga de um vídeo de 2023.
Exponha o painel na porta 3001
O serviço Web no contentor utiliza a porta TCP 3001. Se essa porta no anfitrião já estiver ocupada, associe outra porta do anfitrião à porta 3001 do contentor e abra a aplicação CasaOS através da porta escolhida no anfitrião.
Alterar a porta do anfitrião não exige alterar a porta interna do Uptime Kuma, a menos que a aplicação a montante suporte explicitamente essa alteração e necessite dela.
Torne /app/data persistente
Associe uma pasta do anfitrião no CasaOS ou um volume Docker a /app/data. Este é o destino de cópia de segurança importante, pois contém a configuração da monitorização, os dados dos utilizadores e a base de dados SQLite.
Recriar o contentor sem esse volume persistente fará com que se comporte como uma instalação nova do Uptime Kuma.
Mantenha a base de dados num sistema de ficheiros com bloqueio fiável
As orientações atuais do Uptime Kuma avisam que a base de dados SQLite necessita de bloqueio de ficheiros POSIX fiável e alertam especificamente contra sistemas de ficheiros como muitas configurações NFS para o respetivo diretório de dados.
Num servidor doméstico, manter /app/data num armazenamento local é a opção mais simples. Depois, pode fazer uma cópia de segurança desse diretório local para outro disco ou destino remoto.
Escolha monitores adequados à experiência pretendida
Um monitor de ping apenas comprova que uma máquina responde a ICMP. Se o requisito real for “o Jellyfin deve carregar”, um monitor HTTP para o endpoint do Jellyfin é mais significativo.
Um conjunto prático pode incluir:
- verificações HTTP para aplicações Web;
- verificações TCP para serviços sem um endpoint Web útil;
- verificações DNS para o Pi-hole ou o AdGuard Home;
- verificações de ping para a acessibilidade básica do anfitrião;
- monitores push para tarefas agendadas que devem comunicar a conclusão.
Porque é importante a menção aos monitores push no tópico
Um participante da comunidade afirmou especificamente que utilizava monitores push com frequência. Em vez de o Uptime Kuma consultar um serviço, um script de cópia de segurança ou uma tarefa agendada chama um URL único quando é concluído com êxito. Se esse sinal de atividade não chegar dentro do intervalo esperado, o Uptime Kuma marca o monitor como não saudável.
Isto é útil para tarefas em que “o servidor está online” não comprova que a tarefa foi realmente executada.
Teste as notificações antes da primeira interrupção
Configure pelo menos um canal de notificação e acione deliberadamente um alerta de teste. Um sistema de monitorização que falha silenciosamente ao enviar notificações é apenas um painel histórico.
Para serviços domésticos, tenha também em conta a fadiga causada pelos alertas. Monitorizar todos os endpoints menores com notificações imediatas pode fazer com que as interrupções reais sejam mais fáceis de ignorar.
Mantenha o painel de monitorização privado, a menos que o acesso remoto seja intencional
O Uptime Kuma pode revelar nomes de anfitriões internos, nomes de serviços, endereços de rede e histórico de interrupções. Não o exponha diretamente à Internet pública apenas porque a monitorização remota é útil. Utilize uma VPN, uma rede de sobreposição privada ou um proxy inverso autenticado se for necessário o acesso remoto.
Não trate o tópico do CasaOS de 2023 como uma versão atual fixa
A discussão original elogia uma aplicação bem mantida, mas não conserva uma versão da imagem. Isto é vantajoso: utilize a versão atual disponibilizada a montante, em vez de tentar recriar exatamente o contentor que existia em setembro de 2023.
Perguntas frequentes sobre o Uptime Kuma no CasaOS
Que porta utiliza a versão atual do Uptime Kuma?
A porta 3001 para a interface Web.
Que diretório deve ser persistente?
/app/data.
Porque deve o diretório de dados permanecer num armazenamento local?
A base de dados SQLite necessita de bloqueio de ficheiros fiável, e as orientações atuais a montante alertam contra sistemas de ficheiros de rede inadequados.
O que é que a comunidade original mais valorizou?
As notificações e a funcionalidade de monitores push foram destacadas repetidamente nas respostas.
