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!