2 min de leitura ·

Pitch: Criei um "Sistema Nervoso Autônomo" para o Kernel Linux usando eBPF, Go e Distância de Mahalanobis

Fala, pessoal!

Trabalho como SWE e agora migrando para SRE e sempre me incomodou uma falha estrutural na forma como monitoramos sistemas: a observabilidade atual é estruturalmente lenta.

Entre o momento em que um nó começa a degradar (um vazamento de memória, um processo "runaway" ou um ataque de negação de serviço interno) e o momento em que o Prometheus percebe, o Alertmanager processa e um humano ou orquestrador toma uma ação, o nó já morreu. Chamo isso de "Intervalo Letal".

Para resolver isso, decidi aplicar o que estou estudando no meu mestrado em Matemática na Unicamp e desenvolvi o HOSA (Homeostasis Operating System Agent).

O Conceito: Resiliência Endógena
Em vez de esperar uma decisão externa, o nó precisa ter um "reflexo medular". O HOSA roda dentro do Kernel via eBPF (usando tracepoints e kprobes) e coleta métricas multivariáveis em tempo real.

A Matemática por trás
Não uso apenas limiares simples (ex: CPU > 80%). O HOSA utiliza a Distância de Mahalanobis para entender a correlação entre as métricas.

Se a CPU sobe, mas o Context Switch e o I/O Wait continuam normais, talvez seja apenas um processamento pesado esperado.

Se a CPU sobe junto com uma anomalia na matriz de covariância de rede e memória, o HOSA detecta a anomalia estatística em milissegundos.

Para manter a performance sem fritar o processador, implementei uma versão online do Algoritmo de Welford para atualização incremental da média e variância, rodando em Go no userspace, enquanto o C no Kernel garante a coleta de baixa latência.

O Desafio do Go + eBPF
Um dos maiores desafios foi lidar com a pressão do Garbage Collector (GC) do Go ao processar matrizes de covariância em submilissegundos. Estou explorando otimizações de alocação para garantir que o agente não se torne o próprio gargalo do sistema.

Open Source
O projeto está em fase alpha e o código é aberto. Queria o feedback de vocês sobre a viabilidade de agentes autônomos complementarem (ou substituírem) o modelo reativo de SRE que usamos hoje.

Repositório: https://github.com/bricio-sr/hosa
Projeto: https://hosaproject.org

O que vocês acham dessa abordagem de "imunidade computacional"? Alguém aqui já teve problemas onde o monitoramento tradicional foi lento demais para evitar um desastre?

clacerda

19 horas atrás

Gostei bastante da direção.

Mas ainda não entendi a mecânica concreta da coisa. A discussão de Mahalanobis está boa para um mestrado de matemática, mas como ferramenta eu li o whitepaper e ainda não sei o é exatamente é o vetor de estado e sobre qual baseline ele é comparado. se entendi direito, o HOSA observa o nó inteiro, mas atua em cgroups. Não ficou claro o mapa entre anomalia global e alvo local.

Também senti falta de DTrace no related work. Observabilidade dinâmica programável em produção nasceu ali. Em Linux isso inclusive converge com eBPF.

E talvez o passo seguinte mais interessante seja justamente o que o projeto ainda so aspira, não só detectar e conter, mas usar o regime observado para especializar o kernel em tepo de execução.

No mais, parabéns pelo trabalho e torço para que você consiga transformar essa pesquisa de mestrado em infraestrutura de verdade. É mais ou menos assim que toda deep tech nasce. se fosse numa univerdade da Califórnia e não no interior de paulista eu apostaria que ia ter gente do yc e cia olhando com carinho para isso.

Mas, isso não muda o principal, é muito questão de mentalidade também.. se a veia empreendedora bater, eu iria atrás de todo o fomento que a Unicamp e a FAPESP puderem oferecer. Pelo menos na América do Sul, vc esta no melhor lugar possível.

briciosr

Autor

7 horas atrás

Muito obrigado pelo feedback e pelo tempo dedicado a ler o whitepaper! Seus pontos são cirúrgicos e tocam exatamente nos desafios de engenharia que estou resolvendo agora no HOSA.

Para não deixar suas dúvidas no ar, vou detalhar a mecânica:

O Vetor de Estado e a Baseline
A baseline não é um limiar estático, ela é "viva". O vetor de estado no instante t, digamos x_t, é composto por métricas coletadas via eBPF em alta frequência (ex: run queue length da CPU, page faults por milissegundo, latência de block I/O).A baseline é representada pelo vetor de médias e pela matriz de covariância epsilon. O segredo é que uso uma versão online do Algoritmo de Welford para atualizar o vetor e o epsilon a cada ciclo, sem precisar reter o histórico inteiro na memória. A anomalia é detectada quando a Distância de Mahalanobis ultrapassa um limite de desvios-padrão dessa baseline dinâmica. O nó "aprende" o próprio ritmo (habituação).
O Salto de Global para Local (A grande charada)
Você tocou no ponto mais crítico. Como atuar em um cgroup se a anomalia D_M(x) foi detectada olhando o nó todo?

A arquitetura resolve isso em duas etapas:

Detecção (Global): O modelo multivariável grita "o sistema como um todo entrou em colapso".
Isolamento (Local): No exato milissegundo em que o alarme global soa, o agente consulta os mapas eBPF que mantêm contadores paralelos por cgroup/PID. Ele procura qual componente local gerou a maior variação na dimensão que causou o pico na matriz de covariância. É como se o reflexo medular soubesse exatamente qual músculo tensionar com base no nervo que enviou a dor.

A Falta do DTrace no Whitepaper
Minha culpa total. Você tem absoluta razão. O DTrace no Solaris foi o pai da observabilidade dinâmica e a inspiração primária do Brendan Gregg antes de ele migrar esses conceitos para o eBPF no Linux. Vou adicionar um parágrafo de reverência histórica ao DTrace no Related Work na versão 2.2 do whitepaper. Obrigado por apontar isso!
Especialização do Kernel em Tempo de Execução
Isso é brilhante e é o "Nível 6" dos sonhos do projeto. Usar o estado observado não apenas para conter processos (cgroups v2/signals), mas para tunar parâmetros do Kernel dinamicamente (sysctl, tcp windows, swappiness) de acordo com a carga.

Agradeço muito pelas palavras sobre o potencial de "Deep Tech" e sobre o fomento via FAPESP/Unicamp. É fácil a gente se fechar no interior de SP e achar que o projeto não tem escala global. Comentários como o seu me dão a energia necessária para transformar essa pesquisa em uma infraestrutura real e comercialmente viável.

Se quiser acompanhar as próximas PRs ou dar pitacos no código (principalmente na ponte eBPF/Go), será uma honra ter você lá no GitHub!

jlucfarias

24 horas atrás

Caramba, que projeto interessante. Essa ideia de Computer immunology, como o nome da uma das referências, é algo muito bacana, nunca tinha parado pra pensar na necessidade disso. Como não posso auxiliar com nada para esse projeto, vou só dar uma dica para o readme: use mermaid, ao invés de texto direto (é melhor de visualizar os gráficos que você tentou elaborar)

briciosr

Autor

7 horas atrás

Muito obrigado pelo comentário e por ter lido as referências!

É exatamente isso. O conceito de "Imunologia Computacional" muda totalmente a forma como a gente enxerga a infraestrutura. A gente para de tratar o servidor como uma máquina passiva que só espera comandos e passa a dar um "instinto de sobrevivência" pra ele. Quando essa chave virou na minha cabeça, o projeto nasceu.

E cara, sensacional a sua dica do Mermaid! Você tem toda a razão. Como o projeto está em Alpha e eu estava focado em escrever o Whitepaper, o README acabou virando um "blocão" de texto com uns diagramas em ASCII bem rústicos kkkk. Já vou pegar a sua sugestão agora mesmo e subir um commit com o diagrama em Mermaid para facilitar a visualização da arquitetura.

E não diga que não pode auxiliar! Só de você ler, engajar, validar a ideia da imunologia e me dar essa dica de usabilidade do repositório, você já ajudou absurdamente a lapidar o projeto.

Valeu mesmo pela força!