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

Resumo

• O 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 aberta de colaboradores, não por uma empresa independente.
• A arquitetura 2.x separa a recepção UDP, o transporte pelo Kafka, o enriquecimento e o armazenamento no ClickHouse, permitindo dimensionar cada etapa de forma independente, sem corrigir perdas anteriores à ingestão nem a baixa qualidade da origem.
• 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 dependentes dos metadados, classificadores e tempos.

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

Em 14 de julho de 2026, os mantenedores do Akvorado lançaram a versão 2.4.1. A versão em si era um sinal rotineiro de continuidade da manutenção. O fato mais importante estava por trás dela: a geração atual já não exige que um único coletor fortemente acoplado receba cada exportação de fluxo, faça a decodificação e o enriquecimento e, então, a envie diretamente ao repositório analítico.

O Akvorado 2.0 dividiu esse percurso em unidades operacionais independentes; o inlet recebe os pacotes de dados, 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 dos operadores. Uma rede de grande porte pode produzir evidências sobre o tráfego em volume muito maior do que os engenheiros conseguem examinar pacote por pacote. Roteadores e comutadores 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 toda a carga útil das aplicações.

O Akvorado reúne essas evidências, associa a elas um significado de rede 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 os pacotes ou fluxos que serão representados. A amostragem pode excluir conexões curtas. Pacotes UDP podem se perder antes que o coletor os registre. Os modelos podem mudar, e identificadores de interfaces podem ser reutilizados. Uma fonte de roteamento talvez descreva um caminho que mudou depois da passagem do tráfego. Um banco de dados de sistemas autônomos ou de geolocalização pode classificar incorretamente um endereço.

Uma regra escrita por uma pessoa pode rotular o tráfego como cliente, par ou trânsito, embora esse atributo jamais tenha existido dentro do pacote.

A importância do Akvorado está em expor boa parte dessa cadeia em código aberto, em vez de apresentar o gráfico como o resultado opaco de um equipamento fechado. O projeto dá aos operadores controle sobre coleta, retenção, enriquecimento, consultas e acesso. Ao mesmo tempo, atribui a eles a responsabilidade pelas fragilidades de cada componente escolhido. A pergunta central, portanto, é prática, 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 afirme mais do 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á migrando. Em um incidente, um registro histórico pode restringir o período, a interface e a contraparte. 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 existem porque armazenar todos os pacotes é caro demais

Uma captura integral de pacotes pode preservar cabeçalhos, ordem e, às vezes, a carga útil com detalhe suficiente para uma reconstrução forense minuciosa. Ela também cria grandes encargos de armazenamento, controle de acesso e privacidade em enlaces movimentados. As medições de fluxo aceitam uma relação de compromisso diferente. O exportador agrega o tráfego ou faz sua amostragem e, depois, envia registros com campos selecionados, como endereços de origem e destino, portas, protocolo, contadores, carimbos de data e hora 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 conversas por meio de registros de fluxo criados quando uma entrada 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 posteriores; a posição do campo, isoladamente, não possui significado fixo. Elementos específicos de fornecedores e políticas distintas de cache podem levar dois dispositivos a descrever tráfego semelhante de maneiras não idênticas.

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 geralmente aborda a questão por meio da amostragem de pacotes e contadores. O dispositivo seleciona pacotes em uma taxa configurada, exporta informações da amostra e 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 independente. O custo aparece nos extremos: um fluxo curto pode nunca ser selecionado, uma rajada repentina pode ficar sub-representada e cada valor estimado precisa ser lido à luz da taxa e do denominador da amostra.

Essa distinção é importante porque a palavra «fluxo» não descreve um único tipo homogêneo de evidência. Um cabeçalho de pacote amostrado, um registro agregado de conversa e um contador de interface respondem a perguntas diferentes. Eles podem se reforçar, mas não devem ser fundidos em uma única afirmaçã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 enlace transportou mais tráfego em determinado momento, mas normalmente não identifica as redes ou os serviços envolvidos. Uma captura de pacotes pode responder a isso em detalhes, porém muitos operadores não conseguem preservá-la por semanas ou meses em todos os enlaces de alta capacidade. Os registros de fluxo ocupam a posição intermediária. Eles mantêm dimensões suficientes para permitir o retorno posterior a um evento, desde que as políticas de amostragem e exportação continuem conhecidas.

Por ocupar essa posição intermediária, a análise de fluxos pertence à camada de infraestrutura, e não a uma decoração 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 caminho documentado entre a configuração do dispositivo e o resultado da consulta.

O exportador define o que o Akvorado pode saber

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

O tratamento de 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 posteriores. Se o coletor perder um modelo, receber os dados antes da definição associada ou encontrar um campo específico de fornecedor que mudou, talvez não consiga decodificar corretamente o registro. Em alguns casos, pode solicitar ou aguardar um novo modelo, mas as medições perdidas durante a lacuna 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 comprova uma falha na evidência, mas não reconstrói o tráfego perdido. Uma reinicialização do exportador, uma perda no caminho, um soquete cheio ou o agendamento do host podem produzir sintomas semelhantes; por isso, um contador de perdas inicia a investigação, mas não identifica a causa.

A amostragem acrescenta outro tipo de incerteza. Uma amostra a cada milhares de pacotes pode ser suficiente para estimar um fluxo grande e contínuo em alguns trabalhos de planejamento, mas oferece pouca confiança sobre uma conexão rara. O erro não é uma porcentagem fixa válida em todas as situações; ele depende da distribuição dos fluxos, do método de amostragem, da janela temporal e da própria pergunta. Um gráfico da tendência agregada de trânsito e uma avaliaçã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 os totais estimados de bytes dos registros de fluxo com os contadores das interfaces no mesmo período. Uma diferença persistente pode apontar para pressupostos de amostragem, cobertura da exportação, perda de pacotes ou erro de classificação. As duas fontes medem por mecanismos distintos, portanto não se espera uma correspondência perfeita; a comparação revela se o sistema de fluxos é estável o bastante para sua finalidade.

Aqui começa o primeiro limite da autoridade do Akvorado. O projeto só consegue decodificar, enriquecer e consultar aquilo 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, todas as análises posteriores serão construídas sobre um denominador desconhecido.

Vincent Bernat concebeu o projeto 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 o principal idealizador e o mantenedor geral mais proeminente do projeto. O software também possui um vínculo profundo com o ambiente operacional da operadora francesa Free, que ofereceu contexto de produção e apoio importantes. As evidências, porém, não sustentam a descrição do Akvorado como um produto comercial pertencente à Free, uma empresa independente ou um serviço operado pela Free para todos os usuários.

Essa separação ajuda a compreender a natureza do projeto. Seus materiais públicos se concentram em problemas conhecidos dos operadores: receber vários formatos de fluxo, interpretar índices de interfaces, acrescentar contexto de sistemas autônomos e de roteamento, distinguir peering de trânsito, reter grandes volumes de dados e permitir que engenheiros formulem perguntas específicas. A interface é útil porque se apoia no próprio modelo de dados do operador, não porque exibe um conjunto genérico de gráficos coloridos.

A cronologia inicial é menos completa do que a arquitetura atual. O histórico do repositório aponta para um desenvolvimento contínuo no início da década de 2020, com a coleta, a classificação e a exploração pela web amadurecendo 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 nem do crescimento da base de usuários. O artigo deve preservar essas lacunas, em vez de inventar um mito de fundação.

O papel mais importante da Free é oferecer um ambiente operacional. Uma operadora de internet com tráfego elevado revela problemas que demonstrações de laboratório não mostram: rajadas de exportações UDP, enorme quantidade de interfaces, grande diversidade de endereços, rotas em mudança contínua e a necessidade de relacionar o volume de tráfego às relações comerciais. Esse contexto influencia as prioridades de projeto, mas não comprova que todos os recursos sejam implementados da mesma maneira dentro da Free, que a empresa 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 conjunto em seu próprio ambiente, manter metadados sensíveis sob controle e modificar o programa de acordo com os termos da GNU Affero General Public License version 3. A transparência, no entanto, não substitui o suporte. A organização ainda precisa de pessoas que entendam 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 incorporar as perguntas certas com mais precisão do que um produto analítico genérico. Também pode carregar o risco de concentração em uma pequena comunidade de mantenedores e os pressupostos operacionais dos ambientes que ajudaram a moldá-lo.

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

É fácil entender a atração exercida por um coletor integrado. Um único processo, ou um conjunto interligado, recebe os registros, faz a decodificação e o enriquecimento e os grava no armazenamento. A implantação é simples de explicar e possui 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 operação de 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 os pacotes de fluxo e publicar no Kafka uma representação codificada e compacta. Os processos outlet consomem o fluxo, decodificam os registros, acrescentam metadados, aplicam classificadores e inserem lotes no ClickHouse. A capacidade de recepção, a capacidade de enriquecimento e a taxa do banco de dados podem, então, ser dimensionadas como problemas relacionados, porém independentes.

A separação muda o comportamento diante das falhas. Uma lentidão temporária no ClickHouse já não precisa interromper imediatamente o processo que escuta o tráfego UDP; o Kafka pode manter um acúmulo dentro dos limites de retenção e armazenamento disponíveis. É possível acrescentar processos outlet quando o enriquecimento fica atrasado. As partições distribuem o trabalho, enquanto o inlet permanece pequeno o suficiente para se concentrar nos soquetes e no estado dos exportadores.

O desenho 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 conseguiram acompanhar, 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 reúna e preserve as métricas necessárias.

Componentes adicionais significam novas formas de falha. Os brokers 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 ordem. Os processos outlet podem produzir resultados diferentes se operarem com estruturas de dados ou configurações de enriquecimento distintas. O ClickHouse pode continuar respondendo a consultas antigas enquanto os dados recentes esperam em outro ponto. A arquitetura 2.0 amplia o controle ao tornar visível o caminho de processamento, mas não passa a administrá-lo sozinha.

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 versões mostra manutenção ativa até a 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 apareceram nas maiores escalas.

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

O Kafka absorve o atraso de processamento depois que os dados chegam

O Kafka é a articulação central 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 impede que o atraso do enriquecimento ou de uma gravação cara retorne diretamente ao soquete voltado ao exportador.

O limite temporal é preciso. O Kafka só consegue proteger os dados depois que o inlet os recebe e publica. Um pacote descartado na rede, omitido pelo exportador, perdido em um buffer de soquete cheio ou rejeitado antes da publicação nunca entra no fluxo mantido temporariamente pelo Kafka. Descrever o caminho como «sem perdas» apenas porque o Kafka está presente apaga seu trecho mais frágil.

Mesmo depois da publicação, a durabilidade depende das escolhas realizadas. A replicação entre brokers, as confirmações, a capacidade dos discos, a retenção e a 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. Uma divisão que concentre os exportadores mais pesados pode produzir atrasos desiguais. A falha de um broker durante um período de replicação insuficiente também pode eliminar registros que o inlet já havia aceitado.

A ordem também exige cuidado. O Kafka garante a ordenação dentro de cada partição, não uma ordem global entre todas as partições do conjunto. As análises de fluxo geralmente se importam mais com carimbos de data e hora delimitados e janelas de agregação do que com 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 a ordem e saber como reinicializações ou redistribuições os afetam.

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 de resposta a incidentes acredita estar observando tráfego atual, esse atraso passa a fazer parte da evidência e deve aparecer no próprio modelo de integridade do serviço.

O Kafka também muda 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 operar um sistema distribuído de mensagens. A capacidade e a flexibilidade podem justificar a carga adicional, mas ela continua sendo um custo assumido pelo operador, não uma propriedade gratuita do software aberto.

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

O ClickHouse torna consultável um longo histórico do tráfego

As medições de fluxo combinam com um banco de dados colunar porque muitas perguntas examinam poucos campos em uma quantidade enorme de linhas. Um engenheiro de peering pode agregar bytes por sistema autônomo de destino e por período. Um planejador de capacidade pode comparar interfaces ou locais ao longo de semanas. Um responsável por 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 realiza agregações sem reconstruir cada registro completo em todas as consultas.

O Akvorado insere os dados em lotes no ClickHouse e os organiza para trabalhos analíticos delimitados no tempo. Campos derivados ou previamente calculados podem facilitar a consulta de dimensões frequentes. O banco de dados oferece a persistência que transforma exportações passageiras em memória; assim, um engenheiro pode retornar a uma mudança no tráfego depois que os contadores dos dispositivos já superaram aquele momento e o estado original do roteamento se alterou.

Essa memória possui um custo físico. 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 o comportamento das mesclagens determinam o tempo das consultas e a estabilidade das inserções. As políticas de retenção também decidem se o sistema mantém dias, meses ou períodos ainda maiores. Uma implantação que retenha 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 no ClickHouse importa porque os novos dados e as 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 pode continuar tecnicamente disponível e, ainda assim, ficar operacionalmente atrasado. A pressão sobre os discos pode aparecer primeiro como mesclagens mais lentas, depois como atraso nas inserções 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 cujo significado difere do registro original. Uma consulta ampla sobre uma dimensão de alta cardinalidade pode exigir uma leitura cara. O operador precisa de limites, monitoramento das consultas e uma distinção clara entre dados em resoluçã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 um significado estável e ser organizados ou indexados de forma adequada ao trabalho. A evolução da estrutura de dados pode acrescentar dimensões e, ao mesmo tempo, criar tarefas de migração e compatibilidade. Os Protocol Buffers dinâmicos dão mais flexibilidade à representação de transporte; na outra ponta, porém, o ClickHouse precisa de um modelo analítico coerente.

O ClickHouse, portanto, é mais do que uma dependência escondida sob a interface web. Ele integra o 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 responderá à pergunta do operador quando ela se tornar importante.

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

Um registro bruto pode informar que o tráfego entrou pela interface 287 e saiu pela 914. Esses números possuem significado para o dispositivo exportador, mas não dizem ao engenheiro se o caminho atravessou uma porta de cliente, uma interconexão privada, uma operadora de trânsito, um enlace 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 manter temporariamente em cache nomes, descrições, velocidades e endereços das interfaces, transformando índices numéricos em enlaces compreensíveis. Isso torna o gráfico adequado à revisão de capacidade ou à investigação de um incidente. Também cria um problema temporal: o índice pode ser reutilizado, a descrição pode mudar e a consulta pode falhar. Um registro gerado na segunda-feira talvez seja exibido com metadados coletados posteriormente se a aplicação não preservar cuidadosamente a relação histórica.

Os 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 um local, permitindo que uma equipe de peering agregue o tráfego por rede e geografia. São referências úteis, não registros completos de propriedade. As origens dos prefixos mudam, organizações se fundem, o anycast complica a localização e bancos comerciais usam métodos que podem divergir. O rótulo deve manter proveniência suficiente para que o analista consiga contestá-lo.

O contexto do Border Gateway Protocol associa o tráfego à camada de controle. A arquitetura atual do Akvorado aceita informações de roteamento, inclusive dados por meio do BGP Monitoring Protocol, ou BMP. Informações sobre prefixo, par e próximo salto ajudam a explicar o caminho aparente e a relação que talvez tenha transportado o tráfego. A principal limitação é o tempo: uma captura do roteamento realizada depois do fluxo pode não descrever o caminho escolhido quando os pacotes passaram.

O enriquecimento cria valor e também novos tipos de evidência. Os dados do dispositivo descrevem interfaces locais. Os dados de roteamento descrevem o estado da camada de controle. Os bancos de IP e ASN fornecem associações externas. Os 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 formule 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. O mesmo erro, porém, pode colocar o tráfego na categoria errada de cliente ou trânsito e afetar acertos financeiros, investimentos ou vendas. Com o enriquecimento, o coletor se transforma em um sistema operacional, e um deslize aparentemente inocente nos metadados pode virar um fato institucional.

Na classificação, registros técnicos viram evidências comerciais

As redes não colocam um bit de «par», «cliente» ou «trânsito» em cada pacote. 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 para o negócio.

O valor aparece imediatamente. Um gráfico de utilização total pode mostrar que um enlace está ficando cheio, mas não revela se o crescimento vem de clientes pagantes, pares sem compensação financeira, trânsito de saída ou tráfego interno do backbone. A classificação permite separar esses fluxos e perguntar qual relação impulsiona a mudança. Equipes de peering podem procurar candidatos cujo volume cresceu, enquanto os planejadores de capacidade avaliam se uma nova porta, rota ou linha 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 um limite comercial. Uma comunidade BGP pode funcionar como uma 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 corresponder à consequência. Classificadores usados para exploração interna podem ser testados informalmente. Já aqueles 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 um caminho.

A consistência histórica é outro problema. Se o classificador mudar hoje, os registros antigos preservam o rótulo vigente quando foram coletados ou são reinterpretados conforme a política atual? As duas abordagens são úteis. A primeira preserva aquilo em que a organização acreditava na época; 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 ficam sob o controle do operador. Ainda assim, 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 grande poder, mas expõe detalhes do armazenamento e pode produzir consultas perigosas ou caras. A linguagem semelhante a SQL do Akvorado oferece aos usuários condições, agrupamentos e operadores familiares e os associa ao modelo de consulta 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 responsável por incidentes pode passar de um pico agregado a uma pequena lista de partes envolvidas. Quando a interface de consulta mantém essas etapas próximas da linguagem do domínio, o intervalo entre a suspeita e a evidência diminui.

A abstração tem limites. Um campo só pode ser consultado se existir na estrutura de dados e estiver preenchido corretamente. Um nome alternativo conveniente pode esconder se o valor veio do exportador ou de um banco de enriquecimento. A verificação de pertencimento a um grupo pode ser rápida ou cara, dependendo da 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 da estrutura dos dados foi uma das razões pelas quais Vincent Bernat documentou o uso de Protocol Buffers dinâmicos em 2023. Formatos de fluxo e enriquecimentos mudam, e uma definição fixa compilada pode obrigar todos os produtores e consumidores a avançar juntos. A representação dinâmica permite transportar novos campos com mais flexibilidade, mantendo compactas as mensagens do inlet. As regras de compatibilidade, os números dos campos e seus significados, contudo, exigem disciplina, sobretudo enquanto consumidores antigos ou registros armazenados continuam em uso.

A interface web completa o caminho ao transformar filtros em tabelas e gráficos. A visualização é útil porque as pessoas percebem mudanças, padrões periódicos e anomalias mais rapidamente do que ao ler linhas brutas. Ela também pode produzir confiança indevida. Uma linha suave talvez se baseie em tráfego amostrado, uma fila atrasada e um classificador atualizado. O desenho deve revelar a janela temporal, a agregação e os limites relevantes da evidência, em vez de escondê-los atrás da apresentação.

Uma boa camada de consulta cumpre duas funções. Torna dados complexos acessíveis e preserva uma parte suficiente do modelo para que o operador revise a resposta. A implementação aberta do Akvorado dá às equipes a oportunidade de examinar esse caminho. Fazer isso de fato depende da cultura operacional, não da licença do programa.

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

A análise de fluxos justifica seu lugar dentro da rede quando muda uma decisão. O planejamento de capacidade é um dos exemplos mais claros. Os contadores das interfaces podem mostrar o uso, mas o histórico dos fluxos consegue 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 enlace existente, acrescentar uma sessão de peering, deslocar tráfego ou investigar uma mudança repentina.

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

A análise de peering ilustra a diferença entre o alcance técnico e o 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 isolado não comprova benefício mútuo nem determina localização, disponibilidade de portas, política ou condições contratuais. O Akvorado pode revelar um padrão que merece investigação. A decisão de peering continua nas mãos de operadores que entendem caminhos de roteamento, custo, resiliência e a disposição da contraparte.

As projeções de capacidade têm um limite semelhante. O crescimento histórico pode orientar o investimento, mas o lançamento de novas aplicações, a perda de clientes, mudanças no cache e eventos de roteamento podem alterar o padrão. Uma janela longa de retenção ajuda as equipes a perceber 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 limites, em vez de uma única previsão categórica.

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 enlace de trânsito diminuir e o de um par 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, comprova que todos os pacotes seguiram o caminho desejado 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 persistente e consultável das observações sobre as quais a decisão pode ser discutida. Em organizações onde o conhecimento sobre peering e capacidade continua disperso entre planilhas, scripts temporários e a memória das pessoas, esse registro compartilhado pode se transformar em infraestrutura por direito próprio.

O histórico de fluxos restringe o escopo do 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 predominaram e se o evento ainda estava em andamento. Essas perguntas podem reduzir um relato amplo de interrupção ou congestionamento a um conjunto menor de sistemas e relações.

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

Um grande pico de tráfego não significa automaticamente um ataque. Ele pode resultar de 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 possuem a carga útil da aplicação nem o estado do ponto de extremidade. As equipes de segurança podem usá-los para selecionar candidatos a bloqueio ou investigação mais profunda. A atribuição e a intenção exigem evidências adicionais.

Um gráfico tranquilo também pode enganar. Se um exportador parar, o desaparecimento dos registros talvez pareça uma recuperação. Se o atraso do Kafka aumentar, a interface pode exibir um estado antigo. Se um classificador mudar, o tráfego pode migrar entre categorias sem ter mudado no enlace. Os procedimentos de resposta a incidentes devem incluir verificações explícitas da atualidade dos dados, da integridade dos exportadores, das lacunas de sequência e do atraso na cadeia de processamento antes da interpretação do tráfego.

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 linhas de base passadas e testar explicações concorrentes. Isso se torna ainda mais valioso quando o estado original do dispositivo já foi substituído. Uma revisão 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 em incidentes é que ele «apoia a investigação». O sistema pode tornar a falha compreensível e reduzir o espaço de busca. O gráfico, porém, continua sendo uma observação que passou por exportadores e metadados, não uma conclusão causal.

Um caso que prioriza 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 que prioriza IPv6. O caso é útil porque vem de fora da narrativa principal do projeto e coloca o programa em um contexto específico de implantação. Ele mostra que o conjunto pode ser adaptado a um ambiente no qual o IPv6 é central, e não um acréscimo posterior.

O peso de um único caso continua limitado. Ele não comprova quantas instalações ativas do Akvorado existem, sua participação de mercado, o comportamento do IPv6 em todos os ambientes nem sua adequação a todos os operadores. Equipamentos, exportadores, perfis de tráfego, experiência da equipe e objetivos de retenção nessa implantação podem diferir dos de uma grande operadora, empresa ou rede de conteúdo. O estudo de caso é uma 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 preservar seus dados. Essa possibilidade separa o projeto de uma ferramenta exclusivamente 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. A adoção é mais fácil quando o operador entende as funções do inlet, do Kafka, do outlet e do ClickHouse sem orientação particular. Os materiais públicos de instalação e o ambiente de demonstração reduzem a barreira inicial. Ainda assim, não conseguem prever todos os modelos específicos de fornecedores, problemas de dimensionamento ou políticas de segurança. Estudos de caso externos revelam onde o modelo documentado resiste quando aplicado a outra rede.

Relatos adicionais e independentes de implantação fortaleceriam de maneira relevante 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 perdas, experiência de migração e a relação entre estimativas de fluxo e contadores de interfaces. Também deveriam descrever falhas, porque capturas de tela bem-sucedidas dizem pouco sobre o comportamento do sistema sob pressão.

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

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

Os registros de fluxo normalmente omitem a carga útil das aplicações, mas podem revelar muito sobre as relações. Endereços, portas, horários, volumes e interfaces talvez mostrem 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 da infraestrutura que controla. O operador pode definir onde os dados residem, por quanto tempo são preservados, quem tem permissão para 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 da 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 integrar o perímetro de segurança. Uma função analítica excessivamente ampla pode revelar relações além da necessidade do usuário. Backups e réplicas podem manter os dados depois do fim do prazo nominal de retenção. A exportação dos resultados de consultas também pode transferir informações sensíveis para 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 necessite de registros mais detalhados por um período mais curto. Uma única política sem prazo definido amplia ao mesmo tempo o potencial de investigação e o impacto de uma invasão. Os níveis de acesso, agregação, exclusão e auditoria devem acompanhar as perguntas que a organização decidiu ter o direito de formular e está preparada para responder.

O enriquecimento pode aumentar o risco à privacidade na mesma medida em que eleva o valor operacional. Associar um endereço a uma organização ou localização torna o registro mais fácil de compreender e também de usar indevidamente. Uma associação imprecisa pode ainda direcionar suspeitas à parte errada. Os analistas precisam distinguir quais campos vieram do exportador, quais vieram de metadados internos e quais tiveram origem em bancos de dados externos.

A licença AGPLv3 dá aos usuários acesso ao código conforme seus termos, mas não define a governança de dados da organização. A auto-hospedagem remove um fornecedor da cadeia de custódia. Não elimina a necessidade de privilégios mínimos, 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 com os operadores o custo de executar o sistema

O Akvorado não exige uma taxa tradicional de licença de software quando é usado conforme os termos da AGPLv3. Isso pode tornar a plataforma atraente para operadores que desejam controlar custos, dados e personalização. Não significa que a operação seja gratuita. Uma implantação em 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ós. Sua capacidade precisa ser planejada, suas atualizações devem ser testadas e suas falhas precisam ser corrigidas. A cobertura dos exportadores exige manutenção contínua à medida que os dispositivos 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 devem 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 forma. Um serviço gerenciado pode reunir hospedagem, suporte, integrações e uma área mais ampla de produto em um único contrato. O ElastiFlow e outros conjuntos abertos ou comerciais oferecem diferentes opções de armazenamento, licenciamento e suporte. pmacct, ntopng, FastNetMon, ferramentas gerais de observabilidade e sistemas de análise de pacotes resolvem partes adjacentes do problema. A comparação deve considerar o modelo operacional e os requisitos das evidências, não uma contagem dos recursos do painel.

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

Por isso, é importante que o Akvorado não tenha uma empresa reconhecida de suporte comercial para o projeto inteiro. Consultorias podem ajudar em implantações individuais, mas as evidências examinadas não comprovam a existência de um único fornecedor que garanta migrações, resposta de segurança ou níveis de serviço para todo o projeto. Uma organização que adote o conjunto precisa decidir se consegue operá-lo de forma independente, contratar conhecimento especializado ou contribuir o suficiente com o projeto para reduzir os riscos 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. Um grande operador que retenha registros detalhados e de alta cardinalidade pode enfrentar custos significativos 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 nem 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 criar grande valor para quem o utiliza sem possuir um balanço financeiro que o meça.

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

Vincent Bernat é o principal idealizador e mantenedor geral publicamente associado ao Akvorado. O repositório registra contribuições de outras pessoas, e os lançamentos, relatos de problemas e solicitações de integração tornam o desenvolvimento visível. Os materiais examinados não identificaram uma fundação separada, um conselho eleito, uma estrutura formal de membros ou um arranjo completo de financiamento.

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

A mesma estrutura, porém, concentra a autoridade prática. 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, a estrutura dinâmica dos dados, os classificadores e os caminhos de migração pode ficar concentrado em poucas pessoas. Criar uma derivação é legalmente 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 documentadas publicamente por completo. Se as necessidades da empresa mudarem, se os mantenedores assumirem outras funções ou se o apoio diminuir, os usuários externos precisarão saber se a comunidade mais ampla de colaboradores consegue continuar os lançamentos, as correções de segurança e as 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. Os fabricantes de equipamentos mudam o comportamento das exportações. Organismos de padronização desenvolvem os trabalhos relacionados a IPFIX e BMP. Bancos de dados externos alteram suas 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 narrativa madura de governança não exige que o Akvorado se transforme em uma grande instituição. Exige, porém, 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 sofrem pressão. Esses elementos não estavam claros como um marco público completo ao fim da pesquisa.

A abertura do projeto, portanto, deve ser descrita com precisão. O código e grande parte do caminho decisório 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 a rede inteira. Está em preservar observações selecionadas e interrogá-las muito depois de os dispositivos que as produziram terem mudado. O projeto associa exportações de roteadores, enfileiramento, enriquecimento, armazenamento e consultas 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 enquanto calibram os totais de fluxo com os contadores. Equipes de peering podem descobrir relações de tráfego enquanto revisam as regras de classificação. Responsáveis por incidentes podem restringir o tempo e o escopo enquanto procuram evidências em roteamento, registros, pacotes e pontos de extremidade. Equipes de privacidade podem manter os dados localmente e limitar quem os lê e por quanto tempo permanecem armazenados.

O principal modo 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, atraso dos consumidores, 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 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 depois da 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 a carga 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 ou se torne um padrão global. Exige que continue bom na tarefa mais restrita que escolheu: transformar exportações incompletas de fluxo em uma memória de trabalho honesta e duradoura. A evidência decisiva será a capacidade dos operadores de rastrear uma linha na tela até os dispositivos, a amostragem, as filas, os metadados e as regras que a produziram.