Executando verificação de segurança...
15
briciosr
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?

Carregando publicação patrocinada...
4
jlucfarias

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)

3
briciosr
  • Autor
    Autor

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!

4
clacerda

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.

3
briciosr
  • Autor
    Autor

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:

  1. 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).

  2. 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.

  1. 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!

  2. 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!

3
dipievil

Parabéns pelo projeto! Já trabalhei um pouco com SRE mas não a ponto de ser impactado pela "lentidão" da métricas (meu foco era mais microservicos e APIs pequenas que, se começou a ficar feio a coisa derruba e sobe outra instância 🤣).

Mas surgiu uma curiosidade: chegou a pensar em usar Rust ao invés de Go? Pelo pouco que conheço sempre vi sugestões de outros devs para usar Rust quando precisa interações diretas com Kernel (e não tem Garbage Collector).

2
briciosr
  • Autor
    Autor

Muito obrigado pelo comentário e pela ótima pergunta!

Sobre a parte dos microsserviços: você tocou num ponto perfeito. O modelo 'matar a instância e subir outra' (cattle vs pets) é maravilhoso para a aplicação. Mas o problema é quando a anomalia (um vazamento de memória ou fork bomb) afeta o Nó/Servidor (Node) que está hospedando essas dezenas de microsserviços. O orquestrador demora para perceber que o nó ficou 'NotReady', e até lá, a falha em cascata já começou. O HOSA foca na sobrevivência da máquina hospedeira. Fora que quero levar o HOSA para projetos fora do SRE, como por exemplo a industria de embedded (drones, dispositivos autônomos, etc.), mas isso é papo para daqui alguns anos 😂.

Agora, sobre Go vs. Rust: essa foi uma decisão arquitetural muito debatida!
O código do HOSA é dividido em duas partes. A interação direta com o Kernel não é em Go, ela é feita em C (eBPF bytecode), que é injetado nos tracepoints/kprobes. O Go atua apenas no Userspace recebendo os eventos via Ring Buffer e fazendo o cálculo matemático pesado (Matrizes de Covariância, Mahalanobis, etc).

Por que não Rust no Userspace? Pela velocidade de iteração do modelo matemático. O Go me entregou uma agilidade absurda. E sobre o problema do Garbage Collector (GC): nós otimizamos o 'hot path' do HOSA usando sync.Pool e pré-alocação de memória. Nos benchmarks atuais, o HOSA faz o cálculo da anomalia em ~235 microssegundos com zero alocações de memória (0 allocs/op). Como não geramos lixo no caminho crítico, o GC do Go mal precisa trabalhar.

Mas você não está errado! No meu Whitepaper eu até cito que, se em testes futuros sob carga massiva o GC se provar um vilão determinístico, a reescrita do userspace para Rust (ou C via CGo) é o 'Plano B' oficial. 🤣

Valeu demais pelo feedback!

2
linuxteclab

Muito bacana o projeto. Sendo mais superficial, essa parte de observabilidade me parece algo com muita margem para progresso.

Eu estava pensando sobre isso na última semana. Trabalho na Unicamp (FT, Campus 1, Limeira), sou analista de suporte computacional e estamos para receber um HPC (8 nós) para pesquisa.

Estive dando uma olhada e também vi que faltam ferramentas para analisar melhor o cenário, identificar onde está o gargalo e ter um monitoramento mais eficiente.

Até cheguei a pensar que é um bom tema para mestrado, talvez usando eBPF, mas ainda não me aprofundei nisso.

Depois vou ler melhor seu projeto, parabéns.

Caso venha para o campus de Limeira alguma hora, fique à vontade para tomar um café por aqui.

1
briciosr
  • Autor
    Autor

Fala, vizinho de universidade! Muito obrigado pelas palavras.

Cara, o cenário de HPC que você descreveu é exatamente um dos 'chefões finais' que eu imagino para o HOSA. Em clusters de alta performance, você não pode se dar ao luxo de perder 5% de CPU ou centenas de MBs de RAM rodando agentes tradicionais de observabilidade em cada nó. Nos testes de estresse que fiz com o HOSA, ele conseguiu manter a resiliência consumindo cerca de 8MB de RAM e menos de 0.1% de CPU, justamente por delegar a coleta pesada para o eBPF no Kernel.

Sobre ser um tema de mestrado: vá em frente! O eBPF está revolucionando a observabilidade e a segurança. Tem muito campo inexplorado, especialmente na interseção entre estatística/IA e eBPF. Se precisar trocar uma ideia sobre o tema ou até mesmo usar parte do HOSA, me avisa.

E o convite para o café é uma honra! Estou no MSc do IMECC na Cidade Universitária mas sou da cidade de Salto, então Limeira é praticamente um pulo kkk. Qualquer dia desses eu apareço no Campus 1 pra gente falar de eBPF e HPC. Um abraço!