Akvorado transforma registros de fluxo amostrados em memória operacional da rede

Resumo

• Akvorado é um projeto ativo de código aberto para análise de fluxos, iniciado por Vincent Bernat, apoiado no ambiente operacional da Free e desenvolvido por uma comunidade pública de colaboradores, não por uma empresa independente.
• A arquitetura 2.x separa a recepção UDP, o transporte via Kafka, o enriquecimento e o armazenamento no ClickHouse, permitindo escalar cada etapa de forma independente, sem corrigir perdas anteriores à ingestão nem fontes de baixa qualidade.
• O valor da plataforma aparece quando ela transforma endereços, índices de interfaces e contadores em contexto para peering, capacidade e investigação de incidentes, mas os resultados continuam condicionados por metadados, classificadores e tempo.

Uma versão de manutenção revela uma reformulação mais ampla

Em 14 de julho de 2026, os responsáveis pelo Akvorado lançaram a versão 2.4.1. O lançamento em si era um sinal rotineiro de manutenção contínua. O fato mais importante estava por trás dele: a geração atual já não exige que um único coletor fortemente acoplado receba toda exportação de fluxo, faça sua decodificação, enriqueça os dados e os envie diretamente ao armazenamento analítico. O Akvorado 2.0 dividiu esse percurso em unidades operacionais independentes; o inlet recebe os pacotes, o Apache Kafka transporta uma representação compacta, os processos outlet acrescentam contexto e o ClickHouse preserva o resultado para pesquisa e agregação.

Essa arquitetura oferece uma resposta prática a um problema conhecido pelos operadores. Uma rede de grande porte pode produzir muito mais evidências sobre o tráfego do que os engenheiros conseguem examinar pacote a pacote. Roteadores e switches podem resumir o que observam em registros NetFlow, IP Flow Information Export, ou IPFIX, e sFlow. Essas exportações preservam informações suficientes para responder a muitas perguntas sobre volume, direção, interfaces e partes conectadas, sem reter todo o conteúdo das aplicações.

O Akvorado reúne essas evidências, associa significado de rede a elas e disponibiliza seu histórico por meio de uma interface web e de uma linguagem de filtragem.

A aparente simplicidade do diagrama esconde uma cadeia de decisões. O dispositivo exportador escolhe quais pacotes ou fluxos serão representados. A amostragem pode excluir conexões curtas. Pacotes UDP podem se perder antes de serem registrados pelo coletor. Os modelos podem mudar, ou identificadores de interfaces podem ser reutilizados. Um feed de roteamento talvez descreva uma rota que mudou depois da passagem do tráfego. Um banco de dados de sistemas autônomos ou geolocalização pode classificar um endereço incorretamente.

E uma regra escrita por uma pessoa pode chamar o tráfego de cliente, peer ou trânsito, embora essa característica nunca tenha existido dentro do pacote.

A importância do Akvorado está em expor grande parte dessa cadeia em código aberto, em vez de apresentar o gráfico como um resultado misterioso de uma solução fechada. O projeto dá aos operadores controle sobre coleta, retenção, enriquecimento, consulta e acesso. Mas também os torna responsáveis pelos pontos fracos de cada componente escolhido. Por isso, a pergunta central é operacional, não promocional: até que ponto um sistema de fluxos auto-hospedado consegue transformar exportações parciais em uma memória operacional confiável, sem que um painel bem-acabado ultrapasse o que as evidências demonstram?

A resposta depende da tarefa. No planejamento de capacidade, uma tendência baseada em amostragem pode ser útil mesmo sem constituir uma contagem exata de pacotes. No peering, a direção geral do tráfego e o contexto do sistema autônomo podem revelar para onde a demanda está se deslocando. Em um incidente, um registro histórico pode restringir o período, a interface e a contraparte relevantes. Nenhum desses usos exige conhecimento completo no nível dos pacotes, mas todos exigem que o operador saiba o que o registro representa, o que ele omite e como o enriquecimento posterior alterou seu significado.

Os registros de fluxo surgiram porque preservar todos os pacotes custa caro demais

Uma captura completa de pacotes pode preservar cabeçalhos, ordenação e, às vezes, conteúdo, com detalhes suficientes para uma reconstrução forense minuciosa. Mas também cria grandes encargos de armazenamento, controle de acesso e privacidade em links movimentados. As medições de fluxo aceitam uma troca diferente. O exportador agrega o tráfego ou extrai amostras dele e, em seguida, exporta registros com campos selecionados, como endereços de origem e destino, portas, protocolo, contadores, marcas de tempo e interfaces de entrada ou saída.

O resultado é menor, mais fácil de reter e mais adequado à agregação de longo prazo, mas já não constitui uma reprodução literal dos pacotes que atravessaram a rede.

NetFlow e IPFIX normalmente descrevem conversações por meio de registros de fluxo criados quando um item do cache expira ou quando o fluxo termina. O IPFIX estabelece uma estrutura formal baseada em exportadores, coletores, modelos e registros de dados. O coletor precisa do modelo para interpretar os valores seguintes; a posição de um campo, isoladamente, não tem significado fixo. Elementos específicos de cada fabricante e diferentes políticas de cache podem levar dois dispositivos a descrever tráfego semelhante de formas distintas.

Por isso, os decodificadores do Akvorado ficam na fronteira entre uma família de padrões e a realidade de sua implementação nos equipamentos.

O sFlow normalmente aborda o problema por meio de amostras de pacotes e contadores. O dispositivo seleciona pacotes em uma taxa configurada, exporta informações da amostra e também pode informar estatísticas das interfaces. Em volumes suficientemente grandes, as amostras permitem observar padrões gerais sem que o equipamento ou o coletor trate cada pacote como um evento separado. O custo aparece nas margens: um fluxo curto pode nunca ser selecionado, uma rajada repentina pode ficar sub-representada e todo valor estimado precisa ser interpretado com sua taxa de amostragem e seu denominador.

Essa distinção é importante porque a palavra “fluxo” não representa um único tipo homogêneo de evidência. Um cabeçalho de pacote amostrado, um registro agregado de conversação e um contador de interface respondem a perguntas diferentes. Eles podem se complementar, mas não devem ser fundidos em uma única alegação de precisão absoluta. O Akvorado pode armazenar e exibir os campos que recebe; não pode obrigar o exportador a revelar pacotes que não foram selecionados nem campos que nunca foram enviados.

A retenção prolongada é o principal atrativo operacional. Um contador de interface pode mostrar que um link transportou mais tráfego em determinado momento, mas normalmente não identifica as redes ou os serviços envolvidos. Uma captura de pacotes talvez responda a isso em detalhes, mas muitos operadores não conseguem mantê-la por semanas ou meses em todos os links de alta capacidade. Os registros de fluxo ocupam o meio-termo. Eles preservam dimensões suficientes para permitir a investigação posterior de um evento, desde que as políticas de amostragem e exportação continuem conhecidas.

Por ocupar esse meio-termo, a análise de fluxos pertence à camada de infraestrutura, não a um ornamento lateral do painel. O coletor faz parte de um sistema que produz evidências. Seus resultados podem orientar compras, mudanças de peering, engenharia de tráfego e investigações. Decisões com essas consequências precisam de um percurso documentado entre a configuração do dispositivo e o resultado da consulta.

O exportador determina o que o Akvorado pode saber

A primeira dependência do Akvorado está fora de seu repositório. Roteadores e switches determinam se a exportação de fluxos está habilitada, quais interfaces participam, como os registros são definidos, quando os itens do cache expiram, qual é a taxa de amostragem e quais campos aparecem. Caminhos de encaminhamento em hardware podem expor diferentes níveis de detalhe. Um operador pode implantar um coletor sem falhas e, ainda assim, receber um relato parcial porque os equipamentos de origem foram configurados de maneira inconsistente ou não conseguiram exportar a evidência necessária.

O tratamento dos modelos é um ponto frágil. O IPFIX e várias versões do NetFlow usam modelos para que o exportador defina a estrutura dos registros seguintes. Se o coletor perder um modelo, receber os dados antes da definição correspondente ou encontrar um campo específico de empresa que tenha mudado, talvez não consiga decodificar o registro corretamente. Em alguns casos, pode solicitar ou aguardar um novo modelo, mas as medições perdidas durante o intervalo não retornam automaticamente. A prática segura é tratar o estado dos modelos como uma dependência monitorada, não como um canal de protocolo invisível.

As informações de sequência podem revelar algumas lacunas. Um exportador pode numerar pacotes ou registros, permitindo que o coletor perceba uma reinicialização ou interrupção. Isso é um sinal de diagnóstico, não uma forma de recuperação. O número ausente demonstra que existe uma falha na evidência, mas não reconstrói o tráfego perdido. A reinicialização do exportador, uma perda no caminho, um socket saturado ou o agendamento do host podem produzir sintomas semelhantes; portanto, o contador de perdas inicia a investigação, mas não determina a causa.

A amostragem acrescenta outro tipo de incerteza. Uma amostra a cada milhares de pacotes pode bastar para estimar um fluxo grande e persistente em algumas tarefas de planejamento, mas oferece pouca confiança sobre uma conexão rara. O erro não é uma porcentagem fixa aplicável a todas as situações; ele depende da distribuição dos fluxos, do método de amostragem, da janela de tempo e da própria pergunta. Um gráfico da tendência agregada de trânsito e uma conclusão de segurança sobre uma única conexão curta exigem padrões de evidência diferentes.

A calibração mantém essa ambiguidade visível. As equipes podem comparar o total estimado de bytes dos registros de fluxo com os contadores de interface do mesmo período. Uma diferença persistente pode indicar pressupostos de amostragem, cobertura de exportação, perda de pacotes ou erro de classificação. As duas fontes medem por mecanismos distintos, portanto não se espera correspondência perfeita; a comparação revela se o sistema de fluxos está estável o suficiente para sua finalidade.

Aqui começa o primeiro limite da autoridade do Akvorado. O projeto só pode decodificar, enriquecer e consultar o que realmente chegou. Ele não controla o instrumento de medição no ponto de observação. Se o operador tratar a configuração dos exportadores como um problema de outra equipe, toda análise posterior será construída sobre um denominador desconhecido.

Vincent Bernat projetou o sistema a partir de perguntas reais dos operadores

O Akvorado surgiu por volta de 2019 a partir de necessidades reais de análise de fluxos. Artigos públicos e o histórico do código identificam o engenheiro de redes Vincent Bernat como principal iniciador e mantenedor geral mais visível do projeto. O software também está profundamente ligado ao ambiente operacional da operadora francesa Free, que forneceu contexto de produção e apoio importantes. No entanto, as evidências não sustentam a descrição do Akvorado como um produto comercial pertencente à Free, uma empresa independente ou um serviço administrado pela Free para todos os usuários.

Essa distinção ajuda a explicar a natureza do projeto. Seus materiais públicos se concentram em problemas conhecidos pelos operadores: receber vários formatos de fluxo, traduzir índices de interfaces, acrescentar contexto de sistemas autônomos e roteamento, distinguir peering de trânsito, reter grandes volumes de dados e permitir que engenheiros façam perguntas específicas. A interface é útil porque se apoia no próprio modelo de dados do operador, não porque apresenta uma coleção genérica de gráficos coloridos.

A cronologia inicial é menos completa do que a arquitetura atual. O histórico do repositório indica desenvolvimento contínuo no início da década de 2020, com amadurecimento da coleta, da classificação e da exploração pela web antes da reformulação 2.0. Em 2023, Vincent Bernat explicou publicamente a linguagem de filtragem semelhante a SQL e o uso de Protocol Buffers dinâmicos, e os lançamentos continuaram em 2024. Não há uma contagem pública da primeira implantação em produção, da data exata de início ou do crescimento dos usuários. O artigo deve preservar essas lacunas em vez de inventar um mito de fundação.

O papel mais importante da Free é fornecer um ambiente operacional. Uma operadora com alto volume de tráfego expõe problemas que demonstrações de laboratório não revelam: rajadas de exportação UDP, números enormes de interfaces, grande diversidade de endereços, roteamento em mudança constante e a necessidade de relacionar volume de tráfego a relações comerciais. Esse contexto influencia as prioridades de projeto, mas não demonstra que todos os recursos sejam implementados da mesma maneira dentro da Free, que ela financie todos os colaboradores ou que controle o futuro do projeto.

O repositório público oferece aos operadores externos outro caminho para a confiança. Eles podem examinar o código, os relatos de problemas, as notas de versão e a documentação de configuração, executar o sistema em seu próprio ambiente, manter metadados sensíveis sob seu controle e modificar o software nos termos da GNU Affero General Public License version 3. A transparência, porém, não substitui o suporte. A organização ainda precisa de pessoas que compreendam os exportadores, o Kafka, o ClickHouse, os dados de roteamento e as consequências das atualizações.

Assim, a origem do Akvorado cria a tensão central, mas não a elimina. Um software orientado pelas necessidades dos operadores pode representar as perguntas corretas com mais precisão do que um produto analítico genérico. Mas também pode carregar os riscos de concentração em uma pequena comunidade de mantenedores e os pressupostos operacionais dos ambientes que o moldaram.

A versão 2.0 separou a recepção da interpretação

É fácil compreender o apelo de um único coletor integrado. Um processo, ou um sistema interligado, recebe, decodifica e enriquece os registros antes de gravá-los no armazenamento. A implantação é mais fácil de explicar e há menos partes móveis. A fragilidade aparece quando a entrada e a análise deixam de avançar na mesma velocidade. Uma rajada de pacotes UDP não espera a conclusão de uma mesclagem travada no banco de dados nem a recuperação de uma consulta externa de metadados. Se o caminho de recepção ficar bloqueado, a evidência mais antiga pode se perder na entrada, justamente onde é mais difícil substituí-la.

O Akvorado 2.0 separou essas responsabilidades. O inlet se concentra em receber pacotes de fluxo e publicar no Kafka uma representação codificada e compacta. Os processos outlet consomem os dados, decodificam os registros, acrescentam metadados, aplicam classificadores e inserem lotes no ClickHouse. A capacidade de recepção, a capacidade de enriquecimento e o ritmo do banco de dados podem então ser ampliados como problemas relacionados, mas independentes.

A separação muda o comportamento diante das falhas. Uma lentidão temporária no ClickHouse já não precisa interromper imediatamente o listener UDP; o Kafka pode manter um acúmulo dentro dos limites de retenção e armazenamento disponíveis. Mais processos outlet podem ser adicionados quando o enriquecimento fica atrasado. As partições distribuem o trabalho, enquanto o inlet permanece pequeno o bastante para se concentrar nos sockets e no estado dos exportadores.

O projeto também oferece uma linguagem operacional mais clara. Os engenheiros podem perguntar separadamente se os pacotes chegaram ao inlet, se foram publicados, se os consumidores acompanharam o ritmo, se o enriquecimento funcionou e se o ClickHouse aceitou o lote. Um serviço monolítico pode esconder todas essas etapas atrás de um único indicador de integridade. Componentes separados tornam as transferências visíveis, desde que a implantação colete e preserve as métricas necessárias.

Mais componentes também significam mais formas de falhar. Os nós do Kafka precisam de capacidade, opções de replicação, política de retenção e manutenção. O atraso dos consumidores pode crescer silenciosamente. As partições afetam a distribuição e a ordenação. Os resultados dos processos outlet podem divergir se o modelo de dados ou a configuração de enriquecimento for diferente. O ClickHouse pode continuar respondendo a consultas antigas enquanto dados recentes aguardam em outro ponto. A arquitetura 2.0 aumenta o controle ao expor a cadeia de processamento, mas não a torna autogerenciável.

A migração é outro limite. Uma reformulação que altera a representação das mensagens, as funções dos serviços e o comportamento do armazenamento cria trabalho de compatibilidade e operação para os usuários existentes. O histórico de lançamentos mostra manutenção ativa até a versão 2.4.1, mas não oferece uma contagem independente de quantos migraram de versões anteriores, quanto tempo a migração levou ou quais tipos de falha ocorreram nas maiores escalas.

A melhor forma de compreender a mudança da versão 2.0 é como uma distribuição de responsabilidades. O inlet protege o momento da chegada. O Kafka absorve diferenças de ritmo depois da publicação. O outlet transforma os registros originais no modelo de dados esperado pelo Akvorado. O ClickHouse preserva o histórico analítico. Cada etapa pode ser aprimorada e testada separadamente, e cada uma deixa um tipo específico de lacuna quando falha.

O Kafka absorve atrasos de processamento depois da chegada dos dados

O Kafka é a articulação da arquitetura atual do Akvorado porque transforma um caminho de recepção sensível a rajadas em um fluxo que os processos posteriores podem tratar em outro ritmo. As mensagens são colocadas em tópicos e partições, preservadas por um período configurado e depois consumidas pelos processos outlet. Esse armazenamento intermediário evita que o enriquecimento lento ou o armazenamento oneroso retornem diretamente ao socket voltado para o exportador.

O limite temporal é preciso. O Kafka só pode proteger os dados depois que o inlet os recebe e publica. Um pacote descartado na rede, omitido pelo exportador, perdido em um buffer de socket cheio ou rejeitado antes da publicação nunca entra no fluxo mantido temporariamente pelo Kafka. Descrever todo o caminho como “sem perdas” apenas pela presença do Kafka apaga seu ponto mais fraco.

Mesmo depois da publicação, a durabilidade continua dependente das escolhas. Replicação entre os nós, confirmações de gravação, capacidade de disco, retenção e recuperação determinam quanta proteção a fila oferece. Uma retenção curta pode transformar uma interrupção prolongada do ClickHouse em perda de dados. Um particionamento que concentre os exportadores mais pesados pode criar atrasos desequilibrados. A falha de um nó durante um período de replicação insuficiente também pode apagar registros que o inlet já havia aceitado.

A ordenação também exige cautela. O Kafka garante a ordem dentro de cada partição, não uma ordem global entre todas as partições do agrupamento. A análise de fluxos costuma depender mais de marcas de tempo limitadas e janelas de agregação do que de uma única ordem total, mas o estado dos modelos, a sequência dos exportadores e as atualizações de enriquecimento ainda podem depender da relação entre os registros. O operador precisa conhecer os pressupostos do outlet sobre ordenação e os efeitos de reinicializações ou redistribuições.

O atraso dos consumidores é o sinal operacional mais importante porque traduz a arquitetura em tempo. Uma fila com dez milhões de registros significa pouco sem as taxas de chegada e processamento. Já um atraso medido em segundos ou minutos mostra o quanto a visão analítica está defasada em relação à rede. Quando uma equipe de capacidade ou incidentes acredita estar observando tráfego atual, esse atraso passa a fazer parte da evidência e precisa aparecer no próprio modelo de integridade do serviço.

O Kafka também altera as habilidades necessárias para operar o Akvorado. Uma pequena equipe de redes que antes administrava um coletor e um banco de dados passa a gerenciar um sistema distribuído de mensagens. A capacidade e a flexibilidade podem justificar esse encargo adicional, mas ele continua sendo um custo assumido pelo operador, não uma característica gratuita do software aberto.

A afirmação correta é restrita e útil: o Kafka reduz o acoplamento entre a recepção e o trabalho posterior e oferece espaço para atravessar um desequilíbrio temporário. Ele não recupera registros perdidos antes do inlet, não garante a durabilidade de toda implantação e não elimina a necessidade de monitorar a fila como infraestrutura de produção.

O ClickHouse torna consultável o histórico prolongado do tráfego

As medições de fluxo se adaptam bem a um banco de dados colunar porque muitas perguntas examinam poucos campos em um número enorme de linhas. Um engenheiro de peering pode agregar bytes por sistema autônomo de destino e período. Um planejador de capacidade pode comparar interfaces ou locais ao longo de semanas. Um profissional que responde a incidentes pode filtrar um pequeno conjunto de endereços e portas em um intervalo curto. O armazenamento colunar lê as colunas relevantes, compacta valores repetidos e agrega resultados sem reconstruir cada registro completo em toda consulta.

O Akvorado insere dados no ClickHouse em lotes e os organiza para tarefas analíticas delimitadas no tempo. Campos derivados ou previamente calculados podem facilitar a consulta de dimensões comuns. O banco de dados oferece a persistência que transforma exportações passageiras em memória; um engenheiro pode retornar a uma mudança de tráfego depois que os contadores dos equipamentos já ultrapassaram aquele momento e o estado original do roteamento mudou.

Essa memória tem um custo material. Endereços, portas, metadados e rótulos de alta cardinalidade ocupam espaço e afetam a compactação. Partições, chaves de ordenação e comportamento das mesclagens determinam o tempo das consultas e a estabilidade da entrada. As políticas de retenção também decidem se o sistema preserva dias, meses ou períodos ainda maiores. Uma implantação que mantenha indefinidamente todas as dimensões disponíveis pode esgotar os discos ou gastar mais com armazenamento do que as perguntas justificam.

O trabalho em segundo plano do ClickHouse importa porque dados novos e consultas históricas disputam o mesmo sistema. Mesclagem, compactação e replicação podem consumir capacidade de entrada e saída enquanto os processos outlet gravam novos lotes. O banco de dados pode permanecer tecnicamente disponível, mas operacionalmente atrasado. A pressão sobre os discos pode aparecer primeiro como mesclagens mais lentas, depois como atraso na inserção e, por fim, como ausência de evidências recentes para o usuário.

O desenho das consultas pode criar uma ilusão semelhante. Um gráfico rápido talvez dependa de campos previamente calculados ou derivados cuja semântica difere do registro original. Uma consulta ampla sobre uma dimensão de alta cardinalidade pode exigir uma leitura onerosa. O operador precisa de limites, monitoramento das consultas e uma distinção clara entre dados com precisão integral e qualquer agregação ou retenção aplicada na implantação.

A linguagem de filtragem semelhante a SQL ajuda os usuários a evitar a sintaxe direta do banco de dados, mas não elimina seu modelo. Os campos precisam existir, manter significado estável e estar organizados ou indexados de acordo com a tarefa. A evolução do modelo de dados pode acrescentar dimensões e, ao mesmo tempo, criar trabalho de migração e compatibilidade. Os Protocol Buffers dinâmicos tornam mais flexível a representação durante o transporte; na outra ponta, porém, o ClickHouse precisa de uma estrutura analítica coerente.

Por isso, o ClickHouse é mais do que uma dependência escondida sob a interface web. Ele faz parte do compromisso operacional do produto. A integridade do armazenamento, o desempenho das mesclagens, o tempo das consultas e a política de retenção determinam se o Akvorado conseguirá responder à pergunta do operador quando ela se tornar importante.

O enriquecimento transforma índices de interfaces em um mapa do negócio

Um registro original pode dizer que o tráfego entrou pela interface 287 e saiu pela 914. Esses números têm significado para o dispositivo exportador, mas não informam ao engenheiro se o caminho passou por uma porta de cliente, uma interconexão privada, uma operadora de trânsito, um link de backbone ou uma interface de manutenção. O Akvorado enriquece os registros para que a consulta seja formulada na linguagem da rede, não na linguagem do exportador.

A consulta por Simple Network Management Protocol, ou SNMP, é uma fonte desse contexto. O Akvorado pode armazenar temporariamente nomes, descrições, velocidades e endereços das interfaces, convertendo índices numéricos em links compreensíveis. Isso torna o gráfico adequado à revisão de capacidade ou à investigação de incidentes. Mas também cria um problema temporal: o índice pode ser reutilizado, a descrição pode mudar e a consulta pode falhar. Um registro criado na segunda-feira talvez seja exibido com metadados coletados posteriormente, caso a aplicação não preserve com cuidado a relação histórica.

Bancos de dados de endereços e sistemas autônomos acrescentam outra camada. Eles podem associar um prefixo IP a uma organização, um sistema autônomo ou uma localização, permitindo que a equipe de peering agregue o tráfego por rede e geografia. São referências úteis, não registros completos de propriedade. A origem dos prefixos muda, organizações se fundem, o anycast complica a localização e bancos de dados comerciais usam métodos que podem divergir. O rótulo deve preservar procedência suficiente para que o analista possa contestá-lo.

O contexto do Border Gateway Protocol liga o tráfego ao plano de controle. A arquitetura atual do Akvorado oferece suporte a informações de roteamento, inclusive dados fornecidos por BGP Monitoring Protocol, ou BMP. Informações sobre prefixo, peer e próximo salto ajudam a explicar o caminho observado e a relação que talvez tenha transportado o tráfego. A limitação mais forte é temporal: uma fotografia de roteamento coletada depois do fluxo pode não descrever a rota escolhida quando os pacotes passaram.

O enriquecimento, portanto, cria valor e novos tipos de evidência. Os dados dos equipamentos descrevem interfaces locais. Os dados de roteamento descrevem o estado do plano de controle. Bancos de dados de IP e ASN oferecem associações externas. Dados geográficos estimam a localização. Nenhum deles deve ser tratado como uma propriedade original do pacote. O Akvorado os combina para que o operador faça perguntas melhores, mas o resultado herda a temporalidade e o modelo de erro de cada fonte.

Essa distinção se torna especialmente importante quando a organização usa os mesmos dados em atividades técnicas e comerciais. Uma descrição antiga de interface pode ser apenas um incômodo durante um diagnóstico. Mas o mesmo erro pode colocar o tráfego na categoria errada de cliente ou trânsito, afetando acertos financeiros, investimentos ou vendas. Com o enriquecimento, o coletor se transforma em um sistema operacional, e uma falha inocente nos metadados pode virar um fato institucional.

Com a classificação, registros técnicos se tornam evidências comerciais

As redes não inserem em cada pacote um bit indicando “peer”, “cliente” ou “trânsito”. Essas categorias vêm de contratos, relações de roteamento, desenho das interfaces e políticas do operador. Os classificadores do Akvorado podem combinar interfaces, sistemas autônomos, prefixos, comunidades BGP e outros dados para atribuir ao tráfego rótulos compreensíveis em termos comerciais.

O valor aparece imediatamente. Um gráfico do uso total pode mostrar que um link está ficando cheio, mas não revela se o crescimento vem de clientes pagantes, peers sem liquidação financeira, trânsito ascendente ou tráfego dentro do backbone. A classificação permite separar esses fluxos e perguntar qual relação está impulsionando a mudança. Equipes de peering podem procurar candidatos cujo volume cresceu, e planejadores de capacidade podem decidir se uma nova porta, rota ou conexão se justifica.

O classificador também é um documento de política escrito em código. Uma regra que associa uma interface à categoria “cliente” registra um pressuposto sobre a organização da rede. Uma lista de prefixos pode representar uma fronteira comercial. Uma comunidade BGP pode funcionar como categoria contratual. Quando as entradas mudam e as regras não, o painel pode continuar parecendo preciso enquanto seu significado se desvia.

A revisão deve ser proporcional à consequência. Classificadores usados em explorações internas podem ser testados informalmente. Os que sustentam orçamentos de capacidade, negociações com parceiros ou análises próximas do faturamento precisam de controle de mudanças, revisão por pares e calibração com dados independentes. Uma pequena alteração pode reclassificar meses de histórico ou mudar a economia aparente de uma rota.

A consistência histórica é outro problema. Se o classificador mudar hoje, os registros antigos mantêm o rótulo válido quando foram coletados ou são reinterpretados segundo a política nova? As duas abordagens são úteis. A primeira preserva o que a organização acreditava naquele momento; a segunda permite relatórios comparáveis sob a definição atual. O sistema e o analista precisam saber qual delas o gráfico representa.

O Akvorado torna essas decisões visíveis o suficiente para serem administradas porque as regras e os dados permanecem sob controle do operador. Mas ele não escolhe a ontologia comercial correta para a rede. A revisão mais importante do painel pode ocorrer fora da interface, quando as equipes de engenharia, peering e finanças concordam sobre o significado das categorias.

Uma linguagem semelhante a SQL reduz a distância entre os dados e o operador

Um banco de dados de fluxos só é útil se os engenheiros conseguirem formular perguntas com rapidez suficiente para influenciar a operação. O SQL direto oferece muito poder, mas expõe detalhes do armazenamento e pode produzir consultas perigosas ou caras. A linguagem do Akvorado semelhante a SQL fornece condições, grupos e operadores conhecidos e os associa ao modelo de consultas do projeto.

A linguagem é importante porque as perguntas operacionais são iterativas. Um engenheiro pode começar por uma única interface e depois restringir a busca por sistema autônomo, família de endereços, protocolo, porta ou direção. Um analista de peering pode comparar uma rede antes e depois de uma mudança de roteamento. Um profissional de resposta a incidentes pode passar de um aumento agregado para uma lista curta de partes envolvidas. Quando a interface de consulta mantém essas etapas próximas da linguagem do domínio, o tempo entre a suspeita e a evidência diminui.

A abstração tem um limite. Um campo só pode ser consultado se estiver presente no modelo de dados e preenchido corretamente. Um nome alternativo conveniente pode ocultar se o valor veio do exportador ou de uma base de enriquecimento. A participação em um grupo pode ser rápida ou onerosa, conforme a implementação. A linguagem protege o usuário de parte da complexidade do banco de dados, mas não torna preciso um campo mal definido.

A evolução do modelo de dados foi um dos motivos para Vincent Bernat documentar, em 2023, o uso de Protocol Buffers dinâmicos. Os formatos de fluxo e os enriquecimentos mudam, e uma definição fixa compilada pode obrigar todos os produtores e consumidores a mudar juntos. A representação dinâmica permite transportar novos campos com mais flexibilidade, mantendo compactas as mensagens do inlet. Ainda assim, regras de compatibilidade, números de campos e significados exigem disciplina, sobretudo quando consumidores antigos ou registros armazenados continuam em uso.

A interface web completa o percurso ao transformar filtros em tabelas e gráficos. A visualização é útil porque as pessoas percebem mudanças, periodicidade e valores anômalos mais rapidamente do que ao ler linhas originais. Mas ela também pode criar confiança indevida. Uma linha suave pode se basear em tráfego amostrado, uma fila atrasada e um classificador atualizado. O desenho deve expor a janela de tempo, a agregação e os limites relevantes das evidências, em vez de escondê-los atrás da apresentação.

Uma boa camada de consultas cumpre duas funções. Ela torna acessíveis dados complexos e preserva partes suficientes do modelo para que o operador possa revisar a resposta. A implementação aberta do Akvorado dá às equipes a oportunidade de examinar esse percurso. Fazer isso de fato é uma questão de cultura operacional, não de licença do software.

A classificação dá significado comercial ao volume de tráfego

A análise de fluxos justifica seu lugar na rede quando muda uma decisão. O planejamento de capacidade é um dos exemplos mais claros. Contadores de interfaces podem mostrar a utilização, mas o histórico de fluxos pode distribuir a demanda por rede de destino, região, protocolo, categoria de cliente ou outras dimensões. Esses detalhes podem ajudar o operador a decidir entre ampliar um link existente, adicionar uma sessão de peering, deslocar tráfego ou investigar uma mudança repentina.

A decisão continua condicionada pela cadeia de evidências. Um conjunto de dados amostrado pode representar bem um fluxo grande e contínuo e, ao mesmo tempo, deixar escapar muitos fluxos curtos. Um conjunto incompleto de exportadores pode fazer parte da rede parecer mais tranquila do que realmente é. Um classificador pode atribuir a relação errada. Uma mudança posterior no roteamento pode confundir a interpretação se o estado relevante do plano de controle não tiver sido preservado. O valor dos dados para o planejamento vem de medições consistentes ao longo do tempo, não de tratar um único número como verdade apropriada para faturamento.

A análise de peering demonstra a diferença entre alcance técnico e significado comercial. Um sistema autônomo que aparece com frequência nos dados de destino pode ser candidato a uma conexão direta, mas o volume de tráfego isoladamente não comprova benefício mútuo nem determina local, disponibilidade de porta, política ou termos contratuais. O Akvorado pode revelar um padrão que merece análise. A decisão de peering continua nas mãos de operadores que compreendem caminhos de roteamento, custo, resiliência e disposição da contraparte.

As previsões de capacidade têm limite semelhante. O crescimento histórico pode orientar o investimento, mas lançamentos de aplicações, perda de clientes, mudanças de cache e eventos de roteamento podem alterar o padrão. Uma janela longa de retenção ajuda as equipes a observar sazonalidade e mudanças estruturais. Ela não transforma o futuro em uma continuação inevitável do passado. O uso dos dados é mais responsável quando define cenários e limiares, em vez de uma única previsão determinista.

O histórico de fluxos também pode testar se uma intervenção funcionou. Depois de uma mudança na política de roteamento, os engenheiros podem comparar a distribuição do tráfego antes e depois do evento. Se o tráfego em um link de trânsito cair e o de um peer aumentar, o resultado será compatível com a mudança pretendida. Registros BGP e contadores de interfaces podem reforçar essa interpretação. Nenhum desses sinais, isoladamente, prova que todos os pacotes seguiram a rota desejada ou que a experiência do usuário melhorou.

É tão fácil exagerar o valor do Akvorado quanto subestimá-lo. Ele não automatiza a decisão comercial. Em vez disso, oferece à rede um registro duradouro e consultável das observações que podem fundamentar o debate sobre a decisão. Em organizações nas quais o conhecimento sobre peering e capacidade continua distribuído entre planilhas, scripts temporários e a memória das pessoas, esse registro compartilhado pode se tornar uma infraestrutura por si só.

O histórico de fluxos restringe o escopo de um incidente sem comprovar sua causa

O primeiro benefício operacional dos dados de fluxo preservados durante um incidente é o tempo. Os engenheiros podem perguntar quando o padrão de tráfego mudou, quais interfaces participaram, quais pontos de extremidade ou sistemas autônomos dominaram e se o evento ainda estava em andamento. Essas perguntas podem reduzir um relato genérico de interrupção ou congestionamento a um conjunto menor de sistemas e relações.

As evidências ficam mais fortes quando são combinadas. Contadores de interfaces podem confirmar o tamanho da mudança em um link. Registros BGP ou BMP podem mostrar um evento no plano de controle. Os registros do equipamento talvez revelem uma reinicialização ou atualização de política. Uma captura de pacotes pode oferecer detalhes durante um período curto. O monitoramento dos pontos de extremidade pode indicar se a aplicação falhou. O histórico de fluxos no Akvorado conecta essas fontes por tempo e identidade de rede, mas não as substitui.

Um grande aumento de tráfego não significa automaticamente que ocorreu um ataque. Ele pode ser um lançamento popular, um backup, uma falha de cache, uma mudança de roteamento ou um erro de medição. Os metadados de fluxo podem mostrar origens, destinos, portas e volume, mas normalmente não incluem o conteúdo da aplicação nem o estado do ponto de extremidade. Equipes de segurança podem usá-los para identificar candidatos a bloqueio ou investigação mais profunda. Atribuição e intenção exigem evidências adicionais.

Um gráfico tranquilo também pode enganar. Se um exportador parar, o desaparecimento dos registros pode parecer uma recuperação. Se o atraso do Kafka aumentar, a interface pode mostrar um estado antigo. Se um classificador mudar, o tráfego pode se deslocar entre categorias sem ter mudado no link. Os procedimentos de incidentes precisam incluir verificações explícitas da atualidade dos dados, integridade dos exportadores, lacunas de sequência e atraso da cadeia de processamento antes que o tráfego seja interpretado.

A retenção oferece uma vantagem depois que a pressão imediata termina. As equipes podem reconstruir os minutos anteriores ao alerta, comparar o evento com referências anteriores e testar explicações concorrentes. Isso se torna mais valioso quando o estado original do equipamento já foi substituído. Uma análise posterior ao incidente também pode revelar fragilidades no próprio sistema de evidências: interfaces ausentes, descrições SNMP antigas, amostragem insuficiente ou uma janela de retenção que terminou cedo demais.

A formulação precisa do papel do Akvorado nos incidentes é que ele “apoia a investigação”. Ele pode tornar uma falha compreensível e reduzir o campo de busca. O gráfico, porém, continua sendo uma observação que passou por exportadores e metadados, não um julgamento causal.

Um caso orientado primeiro a IPv6 mostra a portabilidade e os limites de um único exemplo

Em 9 de abril de 2026, o blog da APNIC publicou um artigo operacional sobre a configuração do Akvorado para uma rede orientada primeiro a IPv6. O caso é útil porque vem de fora da narrativa central do projeto e coloca o software em um contexto específico de implantação. Ele mostra que o sistema pode ser adaptado a um ambiente no qual o IPv6 é central, não um acréscimo posterior.

O peso de um único caso continua limitado. Ele não demonstra quantas instalações ativas do Akvorado existem, sua participação de mercado, o comportamento do IPv6 em todos os ambientes ou sua adequação a todos os operadores. Os equipamentos, exportadores, perfis de tráfego, experiência da equipe e objetivos de retenção dessa implantação podem diferir dos de uma grande operadora, empresa ou rede de conteúdo. O estudo de caso é evidência de uso, não uma estatística abrangente.

Sua importância mais ampla está na portabilidade. O Akvorado é distribuído como software aberto, não como um serviço administrado a partir de um único centro. Uma equipe externa pode instalá-lo, conectar seus exportadores, definir seus classificadores e reter seus próprios dados. Essa capacidade separa o projeto da condição de simples ferramenta interna da Free e dá ao repositório uma vida além do ambiente que ajudou a moldá-lo.

A portabilidade também testa a documentação. O projeto é mais fácil de adotar quando o operador compreende as funções de inlet, Kafka, outlet e ClickHouse sem orientação privada. Materiais públicos de instalação e um ambiente de demonstração reduzem a barreira inicial. Mas eles não conseguem antecipar todos os modelos específicos de fabricantes, problemas de escala ou políticas de segurança. Estudos de caso externos revelam onde o modelo documentado se sustenta quando aplicado a outra rede.

Outros relatos independentes de implantação fortaleceriam substancialmente a base de evidências. Relatórios úteis deveriam informar tipos de exportadores, taxas de amostragem, volumes de registros, períodos de retenção, custos de infraestrutura, medições de perda, experiência de migração e a relação entre estimativas de fluxo e contadores de interfaces. Também deveriam descrever as falhas, porque capturas de tela bem-sucedidas dizem pouco sobre o comportamento do sistema sob pressão.

Portanto, o registro público de adoção do Akvorado é confiável, mas incompleto. A atividade do repositório, os lançamentos e o caso publicado pela APNIC mostram um projeto ativo e usado fora do alcance de um único mantenedor. Eles não sustentam um número exato de instalações nem a afirmação de que o sistema se tornou a escolha padrão para análise de fluxos.

A auto-hospedagem mantém metadados sensíveis por perto

Os registros de fluxo normalmente omitem o conteúdo das aplicações, mas podem revelar muito sobre as relações. Endereços, portas, tempo, volumes e interfaces podem mostrar quais sistemas se comunicaram, com que frequência e por qual parte da rede. A retenção prolongada transforma essas observações em um histórico comportamental. Para uma operadora, empresa ou órgão público, o conjunto de dados pode ser operacionalmente valioso e sensível ao mesmo tempo.

O modelo auto-hospedado do Akvorado permite que a organização mantenha a coleta, o Kafka, o ClickHouse e a interface web dentro de uma infraestrutura sob seu controle. O operador pode definir onde os dados ficam, por quanto tempo são preservados, quem tem o direito de consultá-los e quais serviços de enriquecimento são usados. Essa é uma vantagem importante para equipes que não podem enviar medições detalhadas de rede a um serviço externo.

O controle local não é mais forte do que a prática local. A interface web, as APIs, as credenciais do banco de dados, o acesso ao Kafka e os hosts subjacentes passam a fazer parte do limite de segurança. Uma função analítica muito ampla pode revelar relações além da necessidade do usuário. Backups e réplicas podem manter dados depois do fim do período nominal de retenção. A exportação de resultados das consultas também pode levar informações sensíveis a sistemas menos controlados.

A retenção precisa de uma finalidade. O planejamento de capacidade pode funcionar com um histórico agregado, enquanto a resposta a incidentes talvez exija registros mais detalhados durante um período menor. Uma política única e sem prazo definido aumenta ao mesmo tempo o potencial de investigação e o impacto de uma violação. Níveis de acesso, agregação, exclusão e registros de auditoria devem acompanhar as perguntas que a organização decidiu que tem o direito de fazer e está preparada para responder.

O enriquecimento pode elevar o risco à privacidade tanto quanto aumenta o valor operacional. Associar um endereço a uma organização ou localização torna o registro mais fácil de compreender e de usar indevidamente. Uma associação imprecisa também pode direcionar suspeitas à parte errada. Os analistas devem conseguir identificar quais campos vieram do exportador, quais vieram de metadados internos e quais vieram de bancos de dados externos.

A licença AGPLv3 dá aos usuários acesso ao código nos termos previstos, mas não define a governança de dados da organização. A auto-hospedagem retira um único fornecedor da cadeia de custódia. Ela não elimina a necessidade de privilégio mínimo, manutenção segura, limites de retenção e uma prestação de contas clara sobre quem pode transformar metadados de tráfego em decisões.

A licença aberta deixa o custo de operação do sistema com os operadores

O Akvorado não exige uma taxa tradicional de licença de software quando usado segundo os termos da AGPLv3. Isso pode tornar a plataforma atraente para operadores que desejam controlar custos, dados e personalização. Mas não significa que a operação seja gratuita. Uma implantação de produção consome servidores ou máquinas virtuais, armazenamento, capacidade de rede, tempo da equipe e plantões de resposta.

Kafka e ClickHouse são sistemas de grande porte por si só. A capacidade precisa ser planejada, as atualizações precisam ser testadas e as falhas precisam ser corrigidas. A cobertura dos exportadores exige manutenção contínua à medida que os equipamentos de rede e seus firmwares mudam. Credenciais SNMP e metadados precisam ser protegidos. Os classificadores exigem revisão. Atualizações de segurança também precisam ser aplicadas. O maior custo pode ser o tempo de engenharia necessário para manter as evidências confiáveis.

Plataformas comerciais como a Kentik distribuem esses custos de outra maneira. Um serviço gerenciado pode reunir hospedagem, suporte, integrações e uma oferta mais ampla em um único contrato. O ElastiFlow e outros sistemas abertos ou comerciais oferecem opções diferentes de armazenamento, licenciamento e suporte. pmacct, ntopng, FastNetMon, ferramentas gerais de monitoramento e sistemas de pacotes resolvem partes adjacentes do problema. A comparação deve se basear no modelo operacional e nos requisitos de evidência, não na contagem de recursos do painel.

O operador que se auto-hospeda preserva mais controle sobre os registros originais, o modelo de dados, o período de retenção e a lógica das consultas. Mas também assume o risco da saída de um especialista, da mudança de uma dependência ou da falha de uma atualização. O cliente de um serviço gerenciado transfere parte da responsabilidade de infraestrutura e suporte a um fornecedor, em troca de aceitar dependências contratuais, localização dos dados, preços e roteiro do produto. Nenhum modelo elimina a dependência de um fornecedor ou sistema; apenas a coloca em outro ponto.

Por isso, a ausência de uma empresa de suporte comercial certificada para todo o projeto é relevante no caso do Akvorado. Consultorias podem ajudar em implantações individuais, mas as evidências analisadas não demonstram a existência de um único fornecedor que garanta migração, resposta de segurança ou níveis de serviço para o projeto inteiro. Uma organização que adote o sistema precisa decidir se consegue operá-lo de forma independente, contratar conhecimento especializado ou contribuir o suficiente com o projeto principal para reduzir seu risco de suporte.

O custo total também depende do valor do histórico preservado. Uma rede menor, com volume moderado de fluxos, pode considerar o sistema econômico em uma infraestrutura comum. Uma grande operadora que preserve registros detalhados e de alta cardinalidade pode enfrentar custos elevados de armazenamento e banco de dados. O denominador útil não é o custo por servidor, mas o custo de produzir evidências confiáveis o bastante para mudar uma decisão operacional.

Esse limite econômico é fácil de ignorar porque projetos abertos não publicam receita ou avaliação de mercado. A sustentabilidade do Akvorado depende do trabalho dos mantenedores, do apoio operacional da Free, das contribuições externas e da disposição de cada usuário para operar as dependências. O projeto pode gerar muito valor posteriormente sem ter um balanço financeiro que o mensure.

Um projeto liderado por mantenedores pode ser transparente e concentrado ao mesmo tempo

Vincent Bernat é o principal iniciador e mantenedor geral publicamente associado ao Akvorado. O repositório registra contribuições de outras pessoas, e lançamentos, relatos de problemas e solicitações de integração tornam o desenvolvimento visível. Nos materiais analisados, não foi identificada uma organização separada, um conselho eleito, uma entidade formal de membros ou um acordo completo de financiamento.

A governança centrada no repositório tem vantagens reais. As decisões deixam um rastro público. Os usuários podem propor mudanças, examinar discussões e criar uma derivação do código caso discordem do rumo adotado. A licença e a disponibilidade do código oferecem uma saída técnica que um serviço fechado não proporciona. O projeto também pode reagir rapidamente quando os mantenedores compartilham um modelo operacional claro.

Mas a mesma estrutura concentra o poder prático. Os mantenedores decidem quais mudanças entram nos lançamentos oficiais, como a compatibilidade é tratada e quais erros recebem prioridade. O conhecimento sobre o inlet, o modelo dinâmico de dados, os classificadores e os caminhos de migração pode ficar concentrado em poucas pessoas. Criar uma derivação é juridicamente possível, mas operacionalmente caro quando o grupo separado não possui esse conhecimento.

O apoio da Free reduz parte do risco de continuidade ao manter o projeto ligado a um ambiente de produção. Também cria dependência de prioridades que não são inteiramente documentadas em público. Se as necessidades da empresa mudarem, os mantenedores assumirem outras funções ou o apoio diminuir, os usuários externos precisarão saber se a comunidade mais ampla de colaboradores consegue manter lançamentos, correções de segurança e atualizações das dependências.

Os projetos dos quais o Akvorado depende acrescentam outra camada de controle distribuído. Kafka e ClickHouse definem seus próprios roteiros. Fabricantes de equipamentos alteram o comportamento das exportações. Organismos de padronização desenvolvem os trabalhos relacionados a IPFIX e BMP. Bancos de dados externos mudam estruturas e licenças. O Akvorado pode se adaptar, fixar versões ou substituir componentes, mas não tem poder de veto sobre essas decisões.

Uma governança madura não exige que o Akvorado se transforme em uma grande instituição. Exige que a continuidade seja compreensível. Uma política documentada de lançamentos, um grupo mais amplo de mantenedores, um processo de segurança, compromissos de compatibilidade e um plano de sucessão informariam aos operadores o que acontece quando as atuais relações informais ficam sob pressão. Esses elementos não estavam claros como uma estrutura pública completa ao fim da pesquisa.

Assim, a abertura do projeto precisa ser descrita com precisão. O código e grande parte do percurso das decisões são públicos. O financiamento, a distribuição do tempo e a sucessão são menos claros. A transparência reduz a dependência da confiança, mas não elimina a dependência das pessoas.

O melhor painel é aquele que revela seu denominador

A contribuição do Akvorado não está em afirmar que enxerga toda a rede. Ela está em preservar observações selecionadas e permitir sua análise muito depois de os equipamentos que as produziram terem mudado. O projeto conecta exportações de roteadores, enfileiramento, enriquecimento, armazenamento e consulta em uma forma que os operadores podem examinar e executar por conta própria.

Seus usos mais fortes aceitam a incerteza em vez de escondê-la. Equipes de capacidade podem acompanhar tendências persistentes e calibrar os totais de fluxo com os contadores. Equipes de peering podem descobrir relações de tráfego e revisar as regras de classificação. Profissionais de resposta a incidentes podem restringir tempo e escopo enquanto buscam evidências em roteamento, registros, pacotes e pontos de extremidade. Equipes de privacidade podem manter os dados localmente e restringir quem os lê e por quanto tempo permanecem armazenados.

O principal padrão de falha é epistemológico antes de ser técnico: um gráfico limpo pode fazer um denominador desconhecido parecer preciso. Exportadores ausentes, amostragem de pacotes, perda de UDP, consumidores atrasados, dados antigos de interfaces e rótulos aplicados posteriormente podem produzir uma linha convincente. O sistema se torna mais seguro quando essas condições são medidas ao lado do tráfego, em vez de serem tratadas como detalhes de implementação.

Esse também é o teste mais útil para a próxima fase do Akvorado. A frequência dos lançamentos posteriores à versão 2.4.1 mostrará se a arquitetura 2.x continua sustentável. Implantações independentes podem revelar o custo da migração, a perda de dados, o desempenho das consultas e o encargo operacional total. Um tratamento temporal melhor do roteamento e dos metadados pode aprimorar a análise histórica. Um processo mais amplo de segurança e governança também pode reduzir os riscos de continuidade.

O sucesso não exige que o Akvorado substitua todas as plataformas gerenciadas nem se torne um padrão mundial. Exige que ele continue competente na tarefa mais restrita que escolheu: transformar exportações incompletas de fluxo em uma memória operacional honesta e duradoura. A evidência decisiva será saber se os operadores conseguem rastrear uma linha na tela até os equipamentos, a amostragem, as filas, os metadados e as regras que a produziram.