Concedi acesso LLM local aos meus contêineres Docker e ele substituiu meus scripts de monitoramento

Todo técnico de laboratório doméstico segue um padrão semelhante. Você começa com alguns contêineres, depois adiciona monitoramento e depois adiciona mais monitoramento. Eventualmente, você começa a escrever scripts para verificar as coisas automaticamente. Fiz o mesmo e fui além, adicionando LLMs de computação em nuvem como Claude para analisar e relatar. Mas sempre que, depois de alguns dias, o custo, as compensações de privacidade e a dependência externa não se adequavam à minha abordagem auto-hospedada, eu os removia e voltava aos painéis básicos de monitoramento para procurar tudo. Status do serviço – Uptime Kuma, Status do contêiner – Portain, Monitoramento de recursos – Beszel.

O verdadeiro problema nunca foi a visibilidade; eram as melhores ferramentas em suas respectivas categorias e forneciam muitos dados. A camada que faltava era a interpretação. Não foi difícil para mim coletar os dados. Eu me afoguei nele. Os painéis me mostraram tudo. Nenhum deles me disse o que isso significava. Já havia cancelado minha assinatura do Claude Pro e substituído pelo Gemma 4. Ele já estava funcionando no meu computador. Foi então que decidi apontar os dados do meu laboratório doméstico para o LLM local. E então, em vez de criar outro script de monitoramento, comecei a fazer perguntas. A maioria deles tornou-se desnecessária.

Usei Gemma 4 e Qwen 3.5 para as mesmas tarefas locais e um estava quilômetros à frente

Colocá-los uns contra os outros para descobrir o que funciona melhor para meu fluxo de trabalho

Eu tinha os dados. Eu simplesmente não tinha respostas.

Visibilidade nunca foi um problema

Uptime Kuma me contou se meus serviços públicos estavam fora do ar. Bezel monitorou a integridade do meu servidor, se a carga estava acima do normal e se a RAM estava baixa. E o Portiner me mostrou o estado do contêiner, inclusive dos três que estavam parados. Eu já sabia de tudo isso porque visitava de vez em quando os painéis informativos. Todas essas são ótimas ferramentas; é por isso que os escolhi primeiro. Nenhuma dessas ferramentas me disse se os três contêineres suspensos são importantes, ou se a pressão da RAM foi adicionada, ou o que você deveria fazer.

Eu tinha toda essa visibilidade, mas ainda tinha que interpretar tudo sozinho. Três contêineres parados não significavam automaticamente um problema crítico, e o alto uso de RAM não estava relacionado a um problema existente, mas eu não sabia disso à primeira vista. O painel apenas me informou o status, não se isso importava e o que realmente aconteceu. Eu já havia experimentado fornecer acesso LLM ao meu servidor via MCP ou API, mas tudo dependia da nuvem e não consegui seguir minha filosofia sempre que possível.

Passei muito tempo com LLMs locais e o Gemma 4 já estava trabalhando no meu RTX 4070 Ti. Foi rápido, local e não levou a lugar nenhum. Então pensei que poderia usar o mesmo LLM local e expor as informações do meu servidor a ele para obter a camada de interpretação da qual estava falando. Expus os dados do meu servidor ao Gemma 4 – estado do contêiner e logs via API Portainera, métricas de host via Beszel. Finalmente consegui obter uma resposta para essas perguntas. Não são questões técnicas, mas simples questões humanas. A pressão da RAM está conectada a contêineres suspensos? Quais contêineres parados são críticos e quais podem ser ignorados com segurança? Há algo neste servidor neste momento que mereça minha atenção?

Pela primeira vez, verificar a saúde do homelab foi como obter uma resposta em vez de procurar uma resposta.

Ele leu os logs que eu estava ignorando

Os registros finalmente foram úteis

Você deve estar se perguntando como o Native 8B se encaixa em um laboratório doméstico executando hardware antigo. O 8B requer VRAM significativo, mais do que um novo servidor Dell jamais terá. E mesmo que o servidor tivesse esses recursos, hospedar um modelo local desse tamanho não faria sentido porque estaria saturando um servidor com 24 contêineres já em execução. Sim, você está certo sobre essa parte. Mas essa foi a parte boa; Nunca toquei em nada no meu laboratório doméstico. Toda a computação foi feita no meu PC para jogos que tinha um RTX 4070 Ti. Meu computador ficava ligado quase o tempo todo (sim, eu pago muito na conta de luz), então ter um modelo local no meu computador foi a escolha certa para mim.

Depois disso foi um processo simples. Gemma 4 é executado localmente usando Ollama no meu computador. Um pequeno script proxy conectou o navegador à API Portainer e aos endpoints Beszel. Por que escolhi um script de proxy? O Portainer aplica estritamente as políticas CORS e eu não queria mexer nas configurações do Docker do Portainer. E então uma página HTML simples para ver tudo. Portaines forneceu estado e logs do contêiner; Beszel forneceu estatísticas de host. Tudo permaneceu na minha rede local – sem nuvem, sem chave de API externa. Configurei o script para buscar logs dos contêineres interrompidos na primeira execução e somente sob demanda por meio da interface de bate-papo integrada.

Todos os contêineres produziam toras, mas a maioria delas permanecia sem serem colhidas porque eu só as abri depois que alguma coisa já havia quebrado. Ninguém quer ler revistas sobre recipientes que funcionam bem. Este é um fluxo de trabalho humano normal. E quando se tratava de contêineres suspensos, muitas vezes me via percorrendo centenas de linhas em busca de um único tópico útil. Por exemplo, todos os meus serviços públicos como Jellyfin, Immich e Vaultwarden estavam funcionando bem, mas quando pedi para verificar os logs do Uptime Kuma, revelou que o Vaultwarden ocasionalmente expirava externamente e o Nextcloud estava recebendo erros 503 intermitentes. Nenhum dos problemas foi crítico o suficiente para acionar um alerta, e é por isso que nunca procurei por isso.

O que não surpreendeu foi que a modelo sabia ler revistas. Muitas ferramentas poderiam fazer isso. Mas agora os logs tornaram-se úteis novamente. Eles deixaram de ser algo que eu evitava até que o desastre acontecesse.

Então parei de abri-lo completamente

A automação é a cereja do bolo

Ok, estava tudo bem; continha dados; tinha inteligência; tinha uma interface de chat e obter respostas era mais rápido do que abrir vários painéis. Mas eu ainda tinha que me lembrar de abri-lo. Ainda era uma etapa manual, talvez mais inteligente, mas ainda era outra tarefa no meu fluxo de trabalho diário. Depois veio o script sem cabeça, o Windows Task Scheduler e o ntfy.

Um script Python sem cabeça eliminou o atrito ao abrir o painel todas as vezes. O script tratou de tudo o que foi feito em cada execução – consultando o Portainer, obtendo estatísticas do Beszel, obtendo os logs do contêiner interrompido, enviando um prompt para Gemma e enviando o resultado via ntfy. O Agendador de Tarefas do Windows me ajudou a automatizar todo esse processo sem esforço. Funcionou durante o login e depois a cada duas horas enquanto eu estava logado.

Os resumos chegaram automaticamente no meu telefone. Quando algo merecia minha atenção, era destacado. Não abro mais todos os painéis para ver se algo está errado ou precisa da minha atenção; o resumo agora veio até mim. Depois de um tempo, percebi que não abria o Portainer com tanta frequência; Beszel e Uptime Kuma ficaram em segundo plano. Todas as três ferramentas fizeram seu trabalho da maneira que fizeram melhor, e o Local LLM se tornou o primeiro lugar que procurei.

Os scripts de monitoramento que escrevi resolveram o problema de interpretação. Depois que o LLM conseguiu entender os dados, a maioria desses scripts não fazia mais sentido.

Executei LLMs locais usando o iGPU mais barato da Intel e os resultados foram surpreendentemente decentes

Não é como uma GPU dedicada, mas você pode executar alguns LLMs leves com o N100.

Os dados sempre estiveram lá. Agora está falando.

Ainda uso Uptime Kuma, Beszel e Portainer. Isso não muda. Esse nunca foi o ponto. Monitorar dados nunca foi um problema. Eu tinha mais dados do que poderia manipular manualmente. O LLM local substituiu o esforço entre ver e compreender os dados. O LLM tornou-se uma camada interpretativa sobre ferramentas que já faziam bem o seu trabalho. Os scripts que escrevi tentaram transformar os dados brutos em respostas, mas o LLM nativo fez o trabalho melhor. Avançando para hoje; em vez de escrever outro roteiro, estou apenas fazendo uma pergunta. E melhor ainda, não preciso perguntar; a resposta chega ao meu telefone.

Link da fonte