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