Portfólio

Trabalho de conclusão da Especialização em Computação Científica para a Indústria, no IFSC — câmpus Florianópolis. Orientação de Delcino Picinin Junior (doutor em Engenharia de Automação e Sistemas pela UFSC) e Amilton Justino (diretor de Segurança Cibernética e pentester).

A pesquisa usa dados reais de produção cedidos por uma empresa parceira, que mantém um ambiente Zabbix maduro e com histórico consistente — exatamente o tipo de fonte que um estudo assim exige.

O problema

Este é um problema que atinge qualquer organização que opere servidores — pequenas empresas, grandes companhias, universidades e governos. Não é particularidade de ambiente nenhum.

Servidores rodam cargas pesadas até esgotar um recurso crítico — quase sempre memória. O kernel do Linux começa a matar processos para se manter vivo, a máquina trava e horas de processamento se perdem.

O monitoramento tradicional é reativo: avisa depois que o limite foi ultrapassado, quando o prejuízo já aconteceu. E os alertas por e-mail acabam ignorados, simplesmente pelo volume.

A pergunta de pesquisa

É possível usar aprendizado de máquina sobre a telemetria que o Zabbix já coleta para estimar — com 1, 6 e 12 horas de antecedência — a probabilidade de um servidor travar?

A abordagem

O agente consome a telemetria existente sem instalar nada nos servidores monitorados, e dispara alertas em canais que as pessoas de fato leem (Google Chat, Telegram, WhatsApp), no formato: “acesse este servidor agora: 90% de probabilidade de travamento nos próximos 45 minutos”.

O diferencial metodológico está no gabarito. Em vez de apenas apontar anomalias genéricas, o projeto usa o histórico de eventos do próprio Zabbix — os registros de “agente indisponível” e “host fora do ar” — para marcar quando as máquinas realmente falharam. Isso permite treinar os modelos sobre os períodos que antecederam falhas reais.

Decisões técnicas

• Coleta: API JSON-RPC do Zabbix 7.0, com limitação de taxa e retomada por checkpoint, para não sobrecarregar um servidor de produção.
• Armazenamento: Apache Parquet consultado com DuckDB. A escolha está registrada num documento de decisão arquitetural, com números medidos: 12x menos espaço que CSV e consultas em milissegundos.
• Modelos: detecção de anomalias com scikit-learn — Isolation Forest, Local Outlier Factor e One-Class SVM.
• Segurança: token de API com permissão exclusiva de leitura, segredos em variáveis de ambiente, e gitleaks no pre-commit bloqueando qualquer commit que contenha credenciais.
• Infraestrutura: Debian 13 em contêiner LXC sobre Proxmox VE, com acesso remoto por túnel WireGuard.

Estado atual

Infraestrutura, ambiente e documentação concluídos. Acesso à API validado e levantamento exploratório finalizado, com os alvos do estudo já definidos. As próximas etapas são a extração histórica, a engenharia de atributos e o treino dos modelos.

Por que será aberto

O projeto será liberado como open source ao final. Como o Zabbix é gratuito e amplamente adotado, quem mais ganha são justamente os que têm menos recursos — pequenas empresas e órgãos públicos —, que passam a poder adotar manutenção preditiva sem custo de licença. Por isso toda a stack foi escolhida com licenças permissivas, sem dependência de software proprietário.

Site estático: o servidor não executa código nem consulta banco de dados, apenas entrega arquivos já prontos. Isso significa uma superfície de ataque bem menor que a de um CMS tradicional — não há painel de login exposto, nem entrada de usuário sendo processada no servidor.

Todo o conteúdo são arquivos Markdown dentro do repositório, o que torna o backup trivial e a migração futura para outra ferramenta quase indolor.