Cada vez que me sentava em minha estação de trabalho, abria instintivamente vários painéis para ver o status do meu laboratório doméstico antes de fazer qualquer coisa. E isso se tornou uma rotina tão grande que eu mal percebi que estava fazendo isso. Normalmente começo com Beszel para verificar a integridade do servidor e depois mudo para Uptime Kuma; se eu vir algo estranho, abro o Portainer para ver o status geral do servidor e o Scrutiny para qualquer coisa relacionada ao disco.
Não tive problemas com nenhuma das ferramentas de monitoramento. Mas passei mais tempo em vários painéis do que realmente fazendo qualquer coisa. Eu precisava de um painel onde pudesse simplesmente olhar, ver se estava tudo bem e seguir em frente. Foi quando conheci Puls. Parecia um painel que poderia substituir todos os outros, mas não exatamente.
A parte mais difícil de administrar um laboratório doméstico não é a configuração. É saber onde procurar se algo estiver errado.
Na verdade, nada foi quebrado
Acabei de verificar muitos lugares.
À medida que meu laboratório doméstico cresceu, passei a levar mais a sério o horário de trabalho e a saúde. O monitoramento foi algo que acrescentei ao longo do tempo conforme a necessidade crescia, não desde o primeiro dia. Inicialmente, comecei com alguns serviços e eu mesmo como o único usuário, então os serviços de monitoramento pareciam um exagero. Talvez eu abra o Portainer de vez em quando para verificar as coisas. Mas à medida que o número de contentores cresceu de alguns para dezenas e depois para vinte, a monitorização manual de cada contentor tornou-se impossível.
Eu estava preocupado não apenas com o status do contêiner, mas também com a integridade do meu servidor. Para contextualizar, construí meu servidor de laboratório doméstico a partir de um laptop reaproveitado de 8 anos. O laptop era um Dell Latitude 7480 com CPU Core i5-6300U, cerca de 12 GB de RAM e um SSD de 256 GB. Então, colocar mais de 20 pratos parecia tirar todo o suco dele. Depois de quase um ano em meu laboratório doméstico, adicionei gradualmente vários serviços de monitoramento – Uptime aos serviços públicos de Kuma (usando Pangolin), recursos de servidor de Beszel e saúde SMART de disco do Scrutiny. E o Portainer já estava lá para contêineres internos do Docker.
Juntos, eles resolveram todas as minhas dúvidas sobre a saúde e o tempo de atividade do meu laboratório doméstico. Foi “Meu serviço nacional acabou?” ou “O servidor está ocupado?” Abri qualquer painel que respondesse ao problema e ele respondeu imediatamente. Mas essa era a questão. Eu tinha todas as informações, mas elas estavam fragmentadas em quatro painéis diferentes. Nenhum deles se contradisse. Eles simplesmente não sabiam um do outro.
Por exemplo, um contêiner pode ser executado no Portainer enquanto o servidor no Beszel estava sob pressão de memória. Ao mesmo tempo, o Uptime Kuma pode aparecer em verde enquanto o contêiner é reiniciado repetidamente. Não houve conexão direta entre os painéis – eu os costurei manualmente. Então, há muito tempo procuro algo que possa me dizer se preciso abrir os outros.
Então o Pulse começou a conectar tudo
Um painel substituiu os dois primeiros.
Como sempre, eu estava navegando pelos tópicos do Reddit em meu tempo livre e me deparei com um tópico em que o OP estava solicitando ferramentas de monitoramento e gerenciamento de GUI. Abri aleatoriamente e li os comentários; a maioria deles recomendou o Beszel e algumas ferramentas baseadas em CLI. Um até sugeriu Komodo e outro sugeriu Pulse. Alguns comentaristas concordaram. Então decidi visitar o repositório GitHub e a página principal.
A própria página principal me convenceu no meio do caminho, a linha do banner do herói.Um administrador de sistema que monitora toda a sua infraestrutura 24 horas por dia, 7 dias por semana“, fez grande parte do trabalho. A outra metade veio da demonstração ao vivo fornecida. Decidi então experimentá-lo hospedando eu mesmo a versão da comunidade em meu laboratório doméstico. A primeira vez que fiz login após a configuração, tive as mesmas informações, o que geralmente exigia que eu alternasse entre vários painéis.
Somente o painel do Docker fornece informações suficientes, como estado do host, contêineres parados, contêineres que precisam de atualizações, ações de iniciar/parar/reiniciar e métricas para cada contêiner. Costumava me levar a várias guias do Portainer e dar uma rápida olhada no painel do Beszel.
A guia Alertas me disse mais do que qualquer outra coisa; do total de 241 alertas, já havia filtrado 177 como críticos e 64 como avisos, excluindo ruídos gerais. Sem que eu configurasse nada, já havia destacado os mais graves, como o Pi-hole não ser saudável e o Meilisearch e o cloudflared serem mortos pelo OOM.
Pela primeira vez, parecia algo que poderia responder às minhas perguntas cotidianas, como: “Alguma coisa precisa da minha atenção?” de um painel. No entanto, não foi perfeito.
Pulso não substituiu tudo
Um painel ainda conquistou seu lugar.
Pulse se tornou uma página inicial. O Beszel não foi excluído, nem o Portiner foi deixado de lado, apenas não foram mais a primeira aba que você abriu. Duas das minhas ferramentas ainda estavam intactas, Uptime Kuma e Scrutiny. Eu queria ver se Pulse poderia assumir o que Kuma estava fazendo. Então decidi dar uma olhada nas configurações de pulso. Me deparei com muitos recursos que ainda não tinha experimentado. Como mencionei antes, uso principalmente o Uptime Kuma para monitorar o tempo de atividade dos meus serviços disponíveis publicamente. Comecei a adicionar esses URLs no recurso de monitoramento Pulse Availability Checks. Adicionei todos os meus cinco domínios – Jellyfin, Immich, Nextcloud, ntfy e Vaultwarden.
Uma coisa que notei ao adicionar serviços: “Status HTTP inferiores a 500 são considerados acessíveis”. Optei por ignorar isso na época porque não via isso como grande coisa. Quando todos os cinco serviços foram adicionados, o painel mostrou marcas verdes para todos eles. Como nenhum dos meus serviços teve tempo de inatividade, decidi criar um. Parei propositalmente meu contêiner Vaultwarden porque era o menos usado. Esperei alguns segundos e cliquei no botão Verificar; surpreendentemente confirmou que estava online. Verifiquei o painel do contêiner dentro do Pulse; mostrou que parou aí também. Verifiquei o painel do Pangolin; estava lá embaixo também.
Depois de algumas sessões de solução de problemas, tentei ligar os pontos. Como o Vaultwarden estava por trás do SSO no Pangolin, mesmo quando o contêiner estava inativo, ele retornou o status 403. E como mencionado acima, os status HTTP abaixo da linha 500 estavam me incomodando. Como era 403 em vez de 502, o Pulse ainda o considerava online. Certa vez, ignorei o SSO do Pangolin /alive ponto final, o Pulse imediatamente o monitorou corretamente. Em seguida, conectei os alertas à minha instância ntfy usando um webhook. Isso eliminou o ciclo de detecção de problemas e envio deles por meio de minha instância ntfy. Embora o Kuma oferecesse monitoramento mais detalhado, como tempos limite e respostas preditivas, o pulso foi suficiente para minha configuração.
Depois de tudo isso, ainda não havia encontrado um substituto para um dos meus dashboards. O Pulse monitorava serviços, contêineres e servidores, mas não monitorava os dados SMART da mesma forma que o Scrutiny. O painel do Pulse revelou informações básicas do disco, como uso, armazenamento gratuito e total, mas não muito mais do que um comando de terminal de uma linha poderia revelar.
Procurando por algo para substituir o Scrutiny, me deparei com o Patrol. Isso era algo que nenhuma das ferramentas anteriores oferecia. Foi basicamente uma análise de IA dos dados dos meus servidores. Inicialmente, ignorei-o porque não queria expor meu laboratório doméstico ao LLM na nuvem. Mas indo mais fundo, vi que existe uma integração local do LLM por meio do Ollama. Eu já tinha um pequeno LLM (qwen2.5:1.5b) em meu laboratório doméstico de meu experimento anterior, então decidi imediatamente experimentar o Patrol. Embora eu estivesse um pouco cético quanto ao funcionamento desse pequeno modelo, fiquei surpreso quando fiz o teste de prontidão; disse “O modelo selecionado pode executar o Patrol nesta instalação“.
Concluiu com sucesso o seu primeiro lançamento manual, embora ainda não tivesse experimentado um incidente real para se testar. Parecia promissor, mas ainda não tinha conquistado minha confiança. Ao final dos testes, o Pulse não se tornou meu único painel de monitoramento, mas foi o que abri primeiro.
O hábito mudou. Ainda não havia pilha.
Quando decidi experimentar o Pulse, minha intenção não era substituir nenhuma das minhas pilhas de monitoramento existentes. Eu estava procurando algo para substituir minha rotina diária de abrir de dois a quatro painéis de monitoramento diferentes. Depois de alguns dias experimentando o Pulse, meu fluxo de trabalho ficou mais simples, mesmo que a pilha não fosse. No meu laboratório doméstico, ele substituiu meu hábito diário de abrir Uptime Kuma, Beszel e Portainer (container health). Restaram testes cuidadosos, já que o monitoramento SMART não era a finalidade para a qual o Pulse foi projetado. Também configurei o Patrol e ele passou no teste de prontidão e concluiu sua primeira execução de forma limpa, mas ainda não vi como isso me ajuda no monitoramento do servidor a longo prazo. O Pulse não substituiu completamente nenhuma das minhas unidades de monitoramento, mas conquistou um lugar permanente em meu laboratório doméstico e se tornou o primeiro painel que abri.
