En breve

  • Akvorado es un proyecto activo de análisis de flujos de código abierto, creado por iniciativa del ingeniero de redes Vincent Bernat, apoyado en el entorno de Free y desarrollado por una comunidad pública, no por una empresa concreta.
  • La arquitectura 2.x separa la recepción UDP, el transporte Kafka, el enriquecimiento y el almacenamiento en ClickHouse, lo que permite escalar cada etapa de forma independiente, aunque no elimina las pérdidas previas a la recepción ni los defectos de las fuentes.
  • La plataforma aporta valor cuando convierte direcciones, índices de interfaz y contadores en contexto de peering, capacidad e incidentes, pero las conclusiones dependen de los metadatos, los clasificadores y el tiempo.

Una versión de mantenimiento señala una reorganización más amplia

El 14 de julio de 2026, los mantenedores de Akvorado publicaron la versión 2.4.1. La propia versión era una señal corriente de que el proyecto recibe mantenimiento activo. Detrás se escondía un hecho más importante: la generación actual ya no encarga a un único recolector estrechamente acoplado aceptar cada exportación de flujo, decodificarla, enriquecerla y escribirla de inmediato en el almacén analítico.

En Akvorado 2.0, ese camino está dividido en nodos de trabajo separados: inlet acepta los datagramas, Apache Kafka transporta una representación compacta, los procesos outlet añaden contexto y ClickHouse almacena el resultado para su consulta y agregación.

Esta arquitectura responde a un problema práctico familiar para los operadores. Una red grande produce muchas más pruebas de tráfico de las que los ingenieros pueden revisar paquete a paquete. Los routers y conmutadores pueden condensar las observaciones en registros NetFlow, IP Flow Information Export —IPFIX— y sFlow. La exportación conserva suficientes datos para responder preguntas sobre volumen, dirección, interfaces y puntos de interacción sin almacenar cada carga útil. Akvorado recoge esas pruebas, añade significado de red y ofrece un historial mediante una interfaz web y un lenguaje de filtros.

Tras la aparente sencillez del gráfico hay una cadena de decisiones. El dispositivo exportador determina qué paquetes o flujos se representan. El muestreo puede excluir conexiones breves. Los datagramas UDP pueden perderse antes de que el recolector los registre. Las plantillas cambian. Los identificadores de interfaz se reutilizan. La cinta de enrutamiento puede describir una ruta que ya cambió después de que el tráfico pasara. Una base de sistemas autónomos o de geolocalización puede clasificar erróneamente una dirección.

Una regla escrita por una persona puede etiquetar el tráfico como de cliente, peering o tránsito aunque esa característica no estuviera en el propio paquete.

Akvorado importa porque expone buena parte de esa cadena en código abierto, en lugar de presentar un gráfico como resultado inexplicable de un dispositivo. El proyecto da a los operadores control sobre la recopilación, la retención, el enriquecimiento, las consultas y el acceso. A cambio, les traslada la responsabilidad de las debilidades de cada componente elegido. La pregunta clave aquí es operativa, no comercial: hasta dónde puede un sistema autoalojado convertir una exportación incompleta en una memoria fiable del funcionamiento de la red sin que un panel pulido prometa más de lo que los datos confirman.

La respuesta depende de la tarea. Para planificar capacidad, una tendencia muestreada puede ser útil aunque no sea un recuento exacto de paquetes. Para el peering, la dirección general del tráfico y el contexto de sistemas autónomos pueden mostrar hacia dónde se mueve la demanda. En un incidente, el historial puede acotar la franja temporal, la interfaz y la contraparte. Ninguno de estos casos exige omnisciencia a nivel de paquetes. Todos exigen entender qué representa el registro, qué omite y cómo el enriquecimiento posterior ha alterado su significado.

Los registros de flujo existen porque los paquetes completos son demasiado caros de almacenar a largo plazo

La captura completa de paquetes puede conservar cabeceras, orden y a veces carga útil con el detalle suficiente para una reconstrucción forense minuciosa. En enlaces congestionados también genera enormes costes de almacenamiento, control de acceso y privacidad. La telemetría de flujos propone otro compromiso. El exportador agrupa o muestrea el tráfico y envía registros con campos individuales: direcciones de origen y destino, puertos, protocolo, contadores, marcas de tiempo e interfaces de entrada y salida.

El resultado es más pequeño, más fácil de almacenar y agregar durante mucho tiempo, pero ya no es una reproducción literal de los paquetes que circularon por la red.

NetFlow e IPFIX suelen describir las conexiones con registros creados al expirar una entrada de caché o al terminar el flujo. IPFIX formaliza la arquitectura de exportadores, recolectores, plantillas y registros de datos. El recolector necesita una plantilla para interpretar los valores posteriores; la posición de un campo no tiene significado estable por sí misma. Las implementaciones de fabricantes y las distintas reglas de caché hacen que dos exportadores describan tráfico similar de forma diferente. Los decodificadores de Akvorado se sitúan en la frontera entre la familia de estándares y el comportamiento real de los dispositivos.

sFlow suele resolver la tarea mediante muestreo de paquetes y contadores. El dispositivo selecciona paquetes a una frecuencia definida, exporta la información de la muestra y puede transmitir estadísticas de interfaz. Con volúmenes suficientemente grandes permite ver pautas generales sin obligar al hardware o al recolector a tratar cada paquete como un evento individual. El precio es visible en los bordes: un flujo breve puede no aparecer nunca en la muestra, un pico repentino puede quedar subestimado y la estimación no puede leerse responsablemente sin la frecuencia de muestreo y su denominador.

La distinción importa porque un «flujo» no es un único tipo de prueba. Una cabecera muestreada, un registro de conexión agregado y un contador de interfaz responden a preguntas distintas. Pueden corroborarse entre sí, pero no pueden fusionarse en una sola afirmación de exactitud. Akvorado conserva y muestra los campos recibidos; no obliga al exportador a revelar paquetes que no fueron muestreados ni campos que no fueron enviados.

El almacenamiento prolongado es la principal ventaja operativa. Un contador de interfaz mostrará que en un momento concreto un canal llevaba más tráfico, pero normalmente no dirá qué redes y servicios participaron. La captura de paquetes respondería con más detalle, pero muchos operadores no pueden conservarla semanas o meses en cada enlace de alta velocidad. Los registros de flujo ocupan un punto intermedio. Guardan suficientes mediciones para volver al suceso más adelante, si la política de muestreo y exportación se mantuvo conocida.

Por eso el análisis de flujos pertenece a la pila de infraestructura, no al adorno de un panel. El recolector forma parte del sistema de producción de pruebas. Sus resultados pueden orientar adquisiciones, cambios de peering, gestión de tráfico e investigaciones. Decisiones con esas consecuencias exigen un camino documentado desde la configuración del dispositivo hasta el resultado de la consulta.

El exportador decide qué podrá saber Akvorado en absoluto

La primera dependencia de Akvorado está fuera de su repositorio. Los routers y conmutadores determinan si la exportación está activada, qué interfaces participan, cómo se codifican los registros, cuándo expira la caché, qué muestreo se aplica y qué campos se transmiten. Las rutas de reenvío por hardware pueden revelar distintos niveles de detalle. Incluso un recolector impecable obtendrá un relato incompleto si los dispositivos de origen están configurados de forma desigual o no saben emitir los datos necesarios.

El procesamiento de plantillas es uno de los puntos frágiles. IPFIX y varias versiones de NetFlow usan plantillas para que el exportador defina la estructura de los registros posteriores. Si el recolector pierde una plantilla, recibe datos antes de la definición o se encuentra con un campo empresarial modificado, puede no decodificar el registro correctamente. A veces se puede solicitar o esperar una nueva plantilla, pero la telemetría perdida en el intervalo no regresa automáticamente. Una operación segura trata el estado de las plantillas como una dependencia observable, no como una tubería de protocolo oculta.

La información de secuencia puede detectar parte de las discontinuidades. Los exportadores numeran paquetes o registros, lo que permite al recolector ver un reinicio o un salto. Es una señal de diagnóstico, no de recuperación. Un número faltante muestra un hueco en las pruebas, pero no recrea el tráfico ausente. Un reinicio del exportador, una pérdida en tránsito, el desbordamiento del socket y la planificación del host pueden parecerse, por lo que el contador de pérdidas abre una investigación sin nombrar la causa.

El muestreo crea otro tipo de incertidumbre. Un paquete de entre miles puede estimar razonablemente un gran flujo estable para parte de la planificación de capacidad, pero decir casi nada sobre conexiones raras. El error no es un porcentaje fijo aplicable en todas partes. Depende de la distribución de flujos, del método de muestreo, de la ventana temporal y de la pregunta. Una tendencia del tránsito general y una conclusión de seguridad sobre una conexión breve exigen estándares de prueba distintos.

La calibración mantiene visible la incertidumbre. Un equipo puede comparar el volumen de bytes estimado por flujos con los contadores de interfaz del mismo período. Una discrepancia sostenida puede indicar supuestos de muestreo, cobertura de exportación, pérdida de datagramas o error de clasificación. Las fuentes miden con mecanismos distintos y no están obligadas a coincidir perfectamente; la comparación muestra si el sistema es suficientemente estable para la tarea prevista.

Aquí pasa la primera frontera de autoridad de Akvorado. El proyecto solo puede decodificar, enriquecer y consultar los datos que realmente llegaron. No controla el instrumento en el punto de observación. Si el operador considera que la configuración de los exportadores es problema ajeno, todo el análisis posterior se construye sobre un denominador desconocido.

Vincent Bernat diseñó Akvorado en torno a preguntas reales de los operadores

Akvorado surgió hacia 2019 de necesidades prácticas de análisis de flujos. Los artículos públicos y la historia del código señalan al ingeniero de redes Vincent Bernat como principal iniciador y mantenedor destacado. El programa también está estrechamente ligado al entorno operativo del proveedor de internet francés Free, que aportó un importante contexto de producción y apoyo. Los datos disponibles no permiten describir Akvorado como un producto comercial de Free, una empresa independiente o un servicio que Free gestione para todos los usuarios.

Esta delimitación explica el carácter del proyecto. Los materiales públicos se centran en tareas familiares para el operador: aceptar distintos formatos de flujo, traducir índices de interfaz, añadir contexto de sistemas autónomos y enrutamiento, separar peering y tránsito, almacenar grandes volúmenes durante mucho tiempo y permitir a los ingenieros formular preguntas concretas. La interfaz es útil porque funciona sobre el modelo de datos del propio operador, no porque ofrezca un conjunto universal de gráficos de colores.

La cronología temprana es menos completa que la arquitectura actual. El historial del repositorio muestra desarrollo continuado a principios de los años 2020: la recopilación, la clasificación y la investigación web maduraron antes de la reorganización de la 2.0. En 2023, Vincent Bernat describió públicamente el lenguaje de filtros tipo SQL y los Protocol Buffers dinámicos; en 2024 se publicaron versiones. No existe un registro público de la fecha exacta del primer despliegue en producción, del inicio del proyecto ni del crecimiento del número de usuarios. El perfil debe conservar estos vacíos, no inventar una historia del fundador.

El papel más importante de Free es proporcionar el entorno operativo. Un ISP con mucho tráfico revela problemas invisibles en una demostración de laboratorio: picos de exportación UDP, un número enorme de interfaces, alta cardinalidad de direcciones, enrutamiento en cambio constante y la necesidad de vincular el volumen de tráfico con las relaciones comerciales. Ese trasfondo influye en las prioridades de desarrollo, pero no demuestra que cada función esté igualmente desplegada dentro de Free, que la empresa financie a todos los colaboradores o que controle el futuro del proyecto.

El repositorio público ofrece a los operadores externos otra fuente de confianza. Pueden estudiar el código, las incidencias, las notas de versión y la configuración; ejecutar toda la pila en sus propias instalaciones; mantener los metadatos sensibles bajo control interno; y modificar el programa bajo los términos de la GNU Affero General Public License versión 3. Sin embargo, la transparencia no sustituye al soporte. Las organizaciones siguen necesitando personas que entiendan los exportadores, Kafka, ClickHouse, los datos de enrutamiento y las consecuencias de las actualizaciones.

El origen de Akvorado configura así la tensión central sin resolverla. Un programa nacido de necesidades de operadores puede codificar las preguntas necesarias con más precisión que un producto analítico genérico. A la vez, puede cargar con el riesgo de concentración en un círculo pequeño de mantenedores y con los supuestos del entorno en el que se creó.

La versión 2.0 separó la recepción de la interpretación

El atractivo de un recolector integrado único es comprensible. Un solo proceso o una pila estrechamente acoplada acepta, decodifica, enriquece y escribe los registros. El despliegue es más fácil de explicar y hay menos componentes. La debilidad aparece cuando la entrada y el análisis dejan de avanzar al mismo ritmo. Un pico de datagramas UDP no esperará a que termine una fusión en la base de datos o a que se acelere una consulta externa de metadatos. Si el camino de recepción se bloquea, la parte más temprana e insustituible de las pruebas puede desaparecer en la entrada.

Akvorado 2.0 separó esas responsabilidades. Inlet se centra en aceptar datagramas de flujo y publicar una representación codificada compacta en Kafka. Los procesos outlet leen el flujo, decodifican los registros, añaden metadatos, aplican clasificadores e insertan los datos por lotes en ClickHouse. La capacidad de recepción, enriquecimiento y base de datos puede escalarse como tareas relacionadas pero independientes.

El desacoplamiento cambia el comportamiento ante fallos. Una ralentización temporal de ClickHouse ya no tiene por qué detener de inmediato el receptor UDP; Kafka puede retener la cola dentro del plazo de retención y el disco disponible. Si el enriquecimiento se retrasa, se pueden añadir procesos outlet. Las particiones reparten el trabajo y el inlet permanece lo bastante pequeño para ocuparse de los sockets y del estado de los exportadores.

El diseño crea un vocabulario operativo más claro. Los ingenieros pueden preguntar por separado si los datagramas llegaron al inlet, si fueron publicados, si los consumidores siguen el ritmo, si el enriquecimiento tuvo éxito y si ClickHouse aceptó el lote. Un servicio monolítica puede ocultar todas las etapas tras un único indicador de salud. Los componentes separados hacen observables las transiciones —si el despliegue realmente recoge y almacena las métricas necesarias.

Más componentes significan más formas de fallo. Los brokers de Kafka requieren cálculo de capacidad, elección de replicación, política de retención y mantenimiento. El retraso de los consumidores puede crecer inadvertidamente. Las particiones afectan al reparto y al orden. Los procesos outlet divergen si usan esquemas o configuraciones de enriquecimiento distintas. ClickHouse puede responder a consultas antiguas mientras los datos recientes esperan en otra parte. La arquitectura 2.0 refuerza el control al hacer explícito el pipeline; no lo hace autogestionado.

La migración es otra frontera. Una reorganización que cambia la representación de los mensajes, los roles de los servicios y el comportamiento del almacenamiento crea trabajo de compatibilidad y operación para los usuarios anteriores. El historial público muestra mantenimiento activo hasta la 2.4.1, pero no hay un recuento independiente de cuántos operadores migraron desde versiones anteriores, cuánto tardaron ni qué fallos surgieron a mayor escala.

El cambio de la 2.0 se entiende mejor como una redistribución de responsabilidades. Inlet protege el momento de llegada. Kafka absorbe la diferencia de ritmo tras la publicación. Outlet convierte los registros brutos en el esquema de Akvorado. ClickHouse conserva el historial analítico. Cada etapa puede mejorarse y probarse por separado y, ante un fallo, cada una deja su propio tipo de hueco.

Kafka absorbe los retrasos de procesamiento después de la llegada de los datos

Kafka es la bisagra de la arquitectura actual de Akvorado, porque convierte el camino de recepción sensible a picos en un flujo que los procesos posteriores pueden tratar a otro ritmo. Los mensajes se colocan en temas y particiones, se retienen un plazo definido y los leen los procesos outlet. Ese amortiguador impide que un enriquecimiento costoso o el retraso del almacén se devuelvan de inmediato como presión sobre el socket que acepta la exportación.

El límite temporal es exacto. Kafka solo puede proteger los datos después de que el inlet los haya recibido y publicado. Un datagrama perdido en la red, descartado por el exportador, desaparecido por un búfer de socket lleno o rechazado antes de la publicación nunca entra en el flujo que Kafka almacena en búfer. Llamar al pipeline «sin pérdidas» por el mero hecho de contar con Kafka escondería el tramo más vulnerable del camino.

Tras la publicación, la durabilidad sigue dependiendo de la configuración. La replicación de los brokers, los acuses de recibo, la capacidad de disco, el plazo de retención y la recuperación ante fallos fijan el nivel de protección. Una retención corta puede convertir un fallo prolongado de ClickHouse en pérdida de datos. Un particionado que concentre a los exportadores pesados en particiones separadas crea retrasos desiguales. Un fallo de broker en un período de replicación insuficiente puede eliminar registros que el inlet ya había aceptado.

El orden también exige atención. Kafka garantiza la secuencia dentro de una partición, no entre todas las particiones del clúster. El análisis de flujos suele necesitar marcas de tiempo acotadas y ventanas de agregación más que un orden absoluto único. Aun así, el estado de las plantillas, la secuencia del exportador y las actualizaciones de enriquecimiento pueden depender de la posición relativa de los registros. El operador debe saber qué supuestos hace el outlet y cómo los afectan un reinicio o un rebalanceo.

El retraso del consumidor es la señal operativa más útil, porque traduce la arquitectura al tiempo. Una cola de diez millones de registros dice poco sin la velocidad de llegada y de procesamiento. El lag en segundos o minutos muestra cuánto se retrasa la vista analítica respecto a la red. Cuando un equipo de capacidad o de respuesta cree que ve el tráfico actual, el retraso pasa a formar parte de la prueba y debe entrar en el modelo de salud del propio servicio.

Kafka también cambia las habilidades que Akvorado requiere. Un pequeño equipo de red que antes gestionaba un recolector y una base de datos ahora mantiene un sistema distribuido de mensajería. La carga adicional puede justificarse por la escala y la resiliencia. Sigue siendo un coste del operador, no una propiedad gratuita del código abierto.

La afirmación correcta es estrecha y útil: Kafka desacopla la recepción del trabajo posterior. Da margen para superar diferencias temporales de ritmo. No devuelve los registros perdidos antes del inlet, no garantiza la durabilidad de cualquier despliegue ni elimina la necesidad de vigilar la cola como infraestructura de producción.

ClickHouse hace consultable el historial largo del tráfico

La telemetría de flujos encaja bien en una base columnar, porque muchas preguntas recorren unos pocos campos entre un número enorme de filas. Un ingeniero de peering puede agrupar bytes por sistema autónomo de destino y por tiempo. Un especialista en capacidad puede comparar interfaces o emplazamientos por semanas. Un participante en una investigación puede filtrar un conjunto pequeño de direcciones y puertos en un intervalo breve. El almacenamiento columnar lee las columnas necesarias, comprime los valores repetidos y agrega sin reconstruir cada registro en cada consulta.

Akvorado inserta los datos en ClickHouse por lotes y los organiza para el análisis con límites temporales. Los campos derivados o materializados simplifican las mediciones frecuentes. La base aporta la persistencia que convierte la exportación efímera en memoria: el ingeniero vuelve a un desplazamiento de tráfico después de que los contadores del dispositivo avanzaran y el estado original de las rutas cambió.

Esa memoria tiene un precio físico. Las direcciones, puertos, metadatos de interfaces y etiquetas de alta cardinalidad ocupan espacio y afectan a la compresión. Las particiones, las claves de ordenación y las fusiones en segundo plano determinan la latencia de las consultas y la resistencia de las inserciones. La política de retención decide si los datos permanecen días, meses o más. Un despliegue que conserve cada medición indefinidamente puede agotar los discos o gastar en almacenamiento más de lo que justifican las preguntas.

El trabajo en segundo plano de ClickHouse importa porque los datos recientes y las consultas históricas compiten por el mismo sistema. Las fusiones, la compactación y la replicación consumen E/S mientras outlet inserta nuevos lotes. La base puede seguir técnicamente disponible pero operativamente rezagada. La presión de disco se manifiesta primero en fusiones más lentas, luego en las inserciones y, finalmente, en la falta de pruebas recientes para el usuario.

El diseño de consultas crea una ilusión parecida. Un gráfico devuelto con rapidez puede apoyarse en campos precalculados o derivados cuyo significado difiere del registro bruto. Una consulta amplia sobre una dimensión de alta cardinalidad puede provocar un recorrido costoso. El operador necesita límites, observabilidad de las consultas y una diferencia clara entre el detalle completo y cualquier política de agregación o retención del despliegue concreto.

El lenguaje de filtros tipo SQL libera a los usuarios de la sintaxis directa de la base, pero no elimina su modelo. Los campos deben existir, tener un significado estable y estar indexados u organizados para la carga. La evolución del esquema añade dimensiones y a la vez crea migración y compatibilidad. Los Protocol Buffers dinámicos hacen más flexible la representación de transporte; ClickHouse sigue necesitando un esquema analítico coherente al otro lado.

Por eso ClickHouse es más que una dependencia oculta bajo la interfaz web. Forma parte del contrato operativo del producto. El estado del almacenamiento, la velocidad de las fusiones, la latencia de las consultas y la retención determinan si Akvorado responde a la pregunta justo cuando se necesita la respuesta.

El enriquecimiento convierte los índices de interfaz en un mapa de negocio

Un registro bruto solo puede decir que el tráfico entró por la interfaz 287 y salió por la 914. Para el dispositivo exportador los números tienen sentido, pero no dicen al ingeniero si la ruta pasó por un puerto de cliente, una conexión privada, un proveedor de tránsito, una columna vertebral o una interfaz de gestión. Akvorado enriquece los registros para que la consulta se formule en el lenguaje de la red, no del exportador.

El sondeo mediante Simple Network Management Protocol —SNMP— aporta parte de ese contexto. Akvorado puede almacenar en caché nombres, descripciones, velocidades y direcciones de interfaces, convirtiendo los índices numéricos en líneas reconocibles. El gráfico pasa a servir para comprobar capacidad e incidentes. A la vez surge un problema temporal: los índices se reutilizan, las descripciones se editan, los sondeos fallan. Un registro creado el lunes puede mostrarse con metadatos obtenidos después si la implementación no conserva el vínculo histórico.

Las bases de direcciones y sistemas autónomos añaden otra capa. Vinculan un prefijo IP con una organización, un ASN o una ubicación y permiten a los equipos de peering agrupar el tráfico por red y geografía. Son referencias útiles, pero no registros de propiedad infalibles. Los orígenes de prefijos cambian, las organizaciones se fusionan, anycast complica la geografía y las bases comerciales usan metodologías divergentes. La etiqueta debe conservar suficiente procedencia para que un analista pueda cuestionarla.

El contexto de Border Gateway Protocol vincula el tráfico con el plano de control. La arquitectura actual de Akvorado admite información de enrutamiento, incluidos los datos del BGP Monitoring Protocol —BMP. El prefijo, el peer y el siguiente salto ayudan a explicar qué ruta era visible y qué relación pudo llevar el tráfico. La principal salvedad es el tiempo: una instantánea de enrutamiento recogida después del flujo puede no describir la ruta elegida cuando los paquetes pasaron.

La etapa de enriquecimiento crea valor y nuevos tipos de pruebas. Los metadatos de dispositivos describen interfaces locales. Los datos de enrutamiento, el estado del plano de control. Las bases de IP y ASN, correspondencias externas. Los datos geográficos estiman el lugar. Nada de esto es una propiedad nativa del paquete. Akvorado combina las fuentes para que el operador formule mejores preguntas, pero el resultado hereda la marca temporal y el modelo de error de cada una.

La diferencia es especialmente importante cuando una misma información se usa en el trabajo técnico y comercial. Una descripción de interfaz desactualizada puede ser una molestia de diagnóstico. El mismo error puede trasladar tráfico a una categoría de cliente o tránsito equivocada y afectar a cálculos, inversiones o ventas. Es en el enriquecimiento donde el recolector se convierte en sistema operativa y un error inocente de metadatos se convierte en un hecho organizativo.

La clasificación convierte los registros técnicos en pruebas comerciales

Las redes no transmiten en cada paquete un bit de «peer», «cliente» o «tránsito». Las categorías proceden de contratos, relaciones de enrutamiento, construcción de interfaces y política del operador. Los clasificadores de Akvorado pueden combinar interfaces, sistemas autónomos, prefijos, comunidades BGP y otros metadatos, asignando etiquetas que hacen el tráfico comercialmente comprensible.

El valor se ve de inmediato. Un gráfico de carga general muestra el llenado del canal, pero no explica si el crecimiento se debe a clientes de pago, peers gratuitos, tránsito ascendente o movimiento interno de la columna vertebral. La clasificación separa estos flujos y permite preguntar qué relación conduce el cambio. El equipo de peering busca candidatos con tráfico creciente. El planificador decide si un nuevo puerto, ruta o canal se justifica.

El clasificador sirve a la vez como documento de política expresado en código. Una regla que asocia una interfaz a la categoría «cliente» fija un supuesto sobre la construcción de la red. Una lista de prefijos puede codificar un límite comercial. Una comunidad BGP puede servir como designación de una categoría contractual. Cuando los datos de entrada cambian y las reglas no, el panel conserva el aspecto exacto aunque el significado derive.

El rigor de la verificación debe corresponderse con las consecuencias. Los clasificadores para investigación interna pueden probarse de forma informal. Los que sostienen presupuestos de capacidad, negociaciones con socios o cálculos requieren gestión de cambios, revisión entre pares y calibración con datos independientes. Una edición pequeña puede reclasificar meses de historial o alterar la aparente economía de una ruta.

La coherencia histórica es otro problema. Si hoy cambia un clasificador, ¿deben los registros antiguos conservar la etiqueta aplicada en su momento o recibir la nueva interpretación? Ambos modelos son útiles. El primero conserva la visión de la organización de aquel momento. El segundo permite comparar informes con la definición actual. El sistema y el analista deben saber qué variante refleja el gráfico.

Akvorado hace visibles estas decisiones para su gobernanza, porque las reglas y los datos quedan en manos del operador. No elige la ontología comercial correcta de la red. Quizá la verificación más importante del panel ocurre fuera de la interfaz, cuando los equipos de ingeniería, peering y finanzas acuerdan el significado de las categorías.

El lenguaje tipo SQL acorta la distancia entre los datos y el operador

Una base de flujos solo es útil cuando los ingenieros pueden formular preguntas con la rapidez suficiente para influir en la operación. El SQL directo es potente, pero expone los detalles del almacenamiento y puede generar consultas inseguras o costosas. El lenguaje tipo SQL de Akvorado ofrece condiciones, conjuntos y operadores familiares, traduciéndolos al modelo de consultas propio del proyecto.

El lenguaje importa porque las preguntas operativas son iterativas. Un ingeniero puede empezar por una interfaz y luego acotar por sistema autónomo, familia de direcciones, protocolo, puerto o dirección. Un analista de peering puede comparar la red antes y después de un cambio de ruta. Quien gestiona un incidente puede pasar de un pico general a una lista corta de nodos. Una interfaz cercana al vocabulario del dominio reduce el tiempo entre la sospecha y la prueba.

La abstracción tiene un límite. Un campo solo puede consultarse si existe en el esquema y está correctamente rellenado. Un alias cómodo puede ocultar si el valor vino del exportador o de la base de enriquecimiento. La verificación de pertenencia a un conjunto puede ser rápida o costosa según la implementación. El lenguaje protege al usuario de parte de la complejidad de la base; no hace preciso un campo mal definido.

La evolución del esquema es una de las razones por las que Vincent Bernat describió en 2023 el uso de Protocol Buffers dinámicos. Los formatos de flujo y el enriquecimiento cambian, y una definición de mensaje compilada rígida puede obligar a todos los productores y consumidores a actualizarse a la vez. La representación dinámica traslada con más flexibilidad los campos nuevos y mantiene los mensajes del inlet compactos. Las reglas de compatibilidad, los números de campo y la semántica exigen disciplina, especialmente mientras los consumidores antiguos siguen operando y se conservan registros anteriores.

La interfaz web completa el camino, convirtiendo los filtros en tablas y gráficos. La visualización es útil porque las personas detectan antes los desplazamientos, la periodicidad y los valores atípicos que leyendo filas brutas. También crea una falsa confianza. Una línea suave puede construirse sobre tráfico muestreado, una cola retrasada y un clasificador actualizado. La ventana temporal, la agregación y los límites de los datos deben estar disponibles en el diseño, no escondidos tras la representación.

Una buena capa de consultas cumple dos tareas. Hace accesibles datos complejos y conserva suficiente del modelo para que el operador pueda impugnar la respuesta. La implementación abierta de Akvorado da a los equipos la posibilidad de verificar ese camino. Si la aprovechan es una cuestión de cultura operativa, no de licencia.

La clasificación da significado comercial al volumen de tráfico

El análisis de flujos ocupa su lugar en la red cuando cambia una decisión. La planificación de capacidad es uno de los ejemplos más claros. Los contadores de interfaz muestran la utilización, y el historial de flujos desglosa la demanda por red de destino, región, protocolo, clase de cliente y otras dimensiones. Esos detalles ayudan a decidir si ampliar el canal existente, añadir una sesión de peering, trasladar tráfico o investigar un cambio brusco.

La decisión sigue limitada por la cadena de pruebas. Los datos muestreados pueden representar bien un gran flujo estable y omitir multitud de breves. Un conjunto incompleto de exportadores silencia parte de la red. Un clasificador puede asignar la relación equivocada. Un cambio de ruta posterior confunde la interpretación si no se conservó el estado anterior del plano de control. La utilidad para la planificación nace de mediciones coherentes en el tiempo, no de convertir un solo número en verdad al nivel del recuento.

El análisis de peering muestra la diferencia entre la viabilidad técnica y el sentido comercial. Un sistema autónomo que aparece con frecuencia en los datos de destino puede ser candidato para una conexión directa, pero el volumen de tráfico por sí solo no establece beneficio mutuo, ubicación, puerto disponible, política ni condiciones contractuales. Akvorado señala una pauta que merece estudio. La decisión queda en manos de los operadores que entienden las rutas, el coste, la resiliencia y la disposición de la contraparte.

Las previsiones de capacidad tienen un límite parecido. El crecimiento histórico ayuda a orientar la inversión, pero el lanzamiento de aplicaciones, la pérdida de clientes, los cambios de caché y los sucesos de enrutamiento alteran el patrón. El almacenamiento largo muestra estacionalidad y cambios estructurales, pero no convierte el futuro en continuación del pasado. La aplicación responsable consiste en definir escenarios y umbrales, no un único pronóstico determinista.

El historial de flujos también comprueba si la intervención funcionó. Tras un cambio de política de rutas, los ingenieros comparan la distribución antes y después del suceso. Si el canal de tránsito bajó y el de peering subió, el resultado es coherente con el traslado previsto. Los registros BGP y los contadores de interfaz refuerzan la interpretación. Ninguna señal por separado demuestra que cada paquete fue por la ruta deseada o que la experiencia del usuario mejoró.

Aquí el valor de Akvorado es fácil de exagerar y de subestimar. No automatiza la decisión comercial. Da a la red un informe duradero y consultable de las observaciones sobre las que esa decisión puede fundamentarse. En organizaciones donde el conocimiento de peering y capacidad vive en hojas de cálculo, scripts puntuales y la memoria de personas concretas, el informe común se convierte en infraestructura.

El historial de flujos acota el marco del incidente sin probar su causa

Durante un incidente, la primera ventaja de los flujos conservados es el tiempo. Los ingenieros preguntan cuándo cambió el patrón, qué interfaces participaron, qué nodos o sistemas autónomos dominaron y si el suceso continúa. Estas preguntas acotan un mensaje general de fallo o saturación a un conjunto menor de sistemas y relaciones.

La prueba es más fuerte en combinación. Los contadores de interfaz confirman la magnitud del cambio del canal. Los registros BGP o BMP muestran un suceso del plano de control. Los registros del dispositivo revelan un reinicio o una actualización de política. Una captura breve de paquetes aporta detalles. La telemetría del punto final indica si falló la aplicación. El historial de Akvorado vincula las fuentes por tiempo e identidad de red, pero no las sustituye.

Un gran pico de tráfico no significa automáticamente un ataque. La causa puede ser un lanzamiento popular, una copia de seguridad, un fallo de caché, un cambio de ruta o un error de medición. Los metadatos de flujo muestran orígenes, destinos, puertos y volumen; normalmente no contienen la carga útil de la aplicación ni el estado del sistema final. El equipo de seguridad puede encontrar candidatos para bloquear o profundizar. La atribución y la intención exigen datos adicionales.

Un gráfico tranquilo también engaña. Si un exportador se detuvo, la desaparición de registros puede parecer una recuperación. Si el lag de Kafka creció, la interfaz mostrará un estado antiguo. Si cambió el clasificador, el tráfico se moverá entre categorías sin cambiar en la línea. El procedimiento de incidente debe comprobar explícitamente la frescura, la salud de los exportadores, las discontinuidades de secuencia y el retraso del pipeline antes de interpretar el tráfico.

El almacenamiento sigue siendo útil cuando la urgencia ha pasado. Los equipos pueden reconstruir los minutos previos a la señal, comparar el suceso con líneas base anteriores y examinar explicaciones rivales. Esto es especialmente valioso cuando el estado original del dispositivo ya se sobrescribió. El análisis también revela las debilidades del propio sistema de pruebas: interfaces ausentes, descripciones SNMP desactualizadas, muestreo insuficiente o una ventana de retención demasiado corta.

La formulación correcta para Akvorado en un incidente es «apoya la investigación». Hace el fallo más comprensible y reduce el área de búsqueda. El gráfico sigue siendo una observación que pasó por exportadores y metadatos, no un veredicto causal.

El caso IPv6-first muestra la portabilidad — y los límites de un solo ejemplo

El 9 de abril de 2026, el APNIC Blog publicó un material práctico sobre la instalación de Akvorado en una red IPv6-first. El caso es útil porque no procede del relato central del proyecto y coloca el programa en un entorno concreto. Muestra que la pila puede adaptarse a una red donde IPv6 está en el centro y no se añade después.

El peso de un solo caso es limitado. No establece el número de instalaciones activas de Akvorado, la cuota de mercado, un comportamiento universal con IPv6 ni la idoneidad para cada operador. El equipamiento, los exportadores, el perfil de tráfico, la experiencia del equipo y los objetivos de retención pueden diferir de los de un gran operador, una empresa o una red de contenidos. El caso práctico demuestra uso, no difusión.

El significado más amplio está en la portabilidad. Akvorado se distribuye como programa abierto, no como servicio centralizado. Un equipo externo puede instalarlo, conectar sus propios exportadores, definir clasificadores y conservar los datos en sus instalaciones. Eso separa el proyecto de la herramienta interna de Free y permite que el repositorio viva fuera del entorno que ayudó a formarlo.

La portabilidad pone a prueba también la documentación. El proyecto es más fácil de adoptar cuando un operador sin instrucciones privadas entiende los roles de inlet, Kafka, outlet y ClickHouse. Los materiales abiertos de instalación y el entorno de demostración reducen la primera barrera. No prevén cada plantilla de fabricante, cada problema de escala ni cada política de seguridad. Los casos externos muestran dónde el modelo documentado resiste el contacto con otra red.

Informes independientes adicionales reforzarían considerablemente la evidencia. Las publicaciones útiles indicarían tipos de exportadores, frecuencia de muestreo, volumen de registros, plazo de retención, costes de infraestructura, pérdidas medidas, experiencia de migración y la relación entre estimaciones de flujos y contadores de interfaz. También describirían fallos, porque una captura de pantalla exitosa dice casi nada del funcionamiento bajo carga.

La imagen pública de la adopción de Akvorado es plausible pero incompleta. La actividad del repositorio, las versiones y el caso de APNIC muestran un proyecto vivo que se usa más allá de un solo mantenedor. No confirman un número exacto de instalaciones ni convierten la pila en la elección estándar para el análisis de flujos.

El autoalojamiento mantiene los metadatos sensibles cerca

Los registros de flujo normalmente no contienen la carga útil de la aplicación, pero revelan mucho sobre las relaciones. Direcciones, puertos, tiempos, volúmenes e interfaces muestran qué sistemas se comunicaron, con qué frecuencia y por qué parte de la red. El almacenamiento prolongado convierte las observaciones en un historial de comportamiento. Para un operador, una empresa o una institución pública, ese conjunto es a la vez útil y sensible.

El modelo de Akvorado permite mantener la recopilación, Kafka, ClickHouse y la interfaz web dentro de una infraestructura bajo control. El operador decide dónde están los datos, cuánto se conservan, quién puede consultar y qué fuentes de enriquecimiento se usan. Es una ventaja sustancial para los equipos a los que no se les permite enviar telemetría de red detallada a un servicio externo.

El control local no es más fuerte que la práctica local. La interfaz web, la API, las credenciales de la base, el acceso a Kafka y los hosts subyacentes entran en el perímetro de seguridad. Un rol de analista demasiado amplio abre relaciones más allá de lo necesario. Las copias de seguridad y las réplicas conservan los datos tras el plazo formal. La exportación de resultados traslada información sensible a sistemas menos controlados.

La retención necesita un propósito. A la planificación de capacidad puede bastarle un historial agregado, mientras que la respuesta a incidentes necesita registros más detallados durante un período corto. Una política indefinida única maximiza a la vez las posibilidades de investigación y las consecuencias de una filtración. Los niveles de acceso, la agregación, el borrado y la auditoría deben seguir las preguntas que la organización decidió tener derecho y disposición de responder.

El enriquecimiento añade riesgo de privacidad junto con valor operativo. Correspondencia de una dirección con una organización o un lugar hace el registro más comprensible y más fácil de abusar. Una correspondencia errónea puede dirigir la sospecha hacia otra parte. Los analistas deben ver qué campos vinieron del exportador, de los metadatos internos o de bases externas.

La licencia AGPLv3 da acceso al código en sus condiciones, pero no diseña la gobernanza de datos de la organización. El autoalojamiento elimina a un proveedor de la cadena de custodia. No elimina los mínimos de privilegio, el mantenimiento seguro, los límites de retención ni la claridad sobre quién puede convertir los metadatos de tráfico en decisiones.

La licencia abierta deja a los operadores los gastos de operar la pila

Akvorado no exige una cuota habitual de licencia de software cuando se usa bajo los términos de la AGPLv3. Eso atrae a los operadores que quieren controlar el coste, los datos y la configuración. De ahí no se sigue una explotación gratuita. Un despliegue en producción consume servidores o máquinas virtuales, almacenamiento, capacidad de red, tiempo del personal y guardias.

Kafka y ClickHouse son por sí mismos sistemas complejos. Su capacidad debe planificarse, las actualizaciones probarse y los fallos resolverse. La cobertura de exportadores exige mantenimiento constante a medida que cambian dispositivos y firmwares. Las credenciales SNMP y los metadatos deben protegerse. Los clasificadores deben verificarse. Los parches de seguridad deben aplicarse. El mayor coste puede ser el tiempo de ingeniería que mantiene la fiabilidad de las pruebas.

Las plataformas comerciales como Kentik distribuyen esos costes de otra manera. Un servicio gestionado reúne alojamiento, soporte, integraciones y una superficie de producto más amplia en un contrato. ElastiFlow y otras pilas abiertas o comerciales eligen otros modelos de almacenamiento, licenciamiento y soporte. pmacct, ntopng, FastNetMon, las herramientas generales de observabilidad y los sistemas de captura resuelven partes vecinas de la tarea. Hay que comparar modelos operativos y requisitos de pruebas, no el número de funciones del panel.

El operador de una instalación propia controla mejor los registros brutos, el esquema, el almacenamiento y la lógica de consulta. También asume el riesgo de la marcha de un especialista, el cambio de una dependencia o una actualización fallida. El cliente de un servicio gestionado traslada al proveedor parte de la infraestructura y el soporte, aceptando dependencia del contrato, la ubicación de los datos, el precio y el plan de producto. Ningún modelo elimina el lock-in; lo colocan de forma distinta.

La ausencia de una única empresa comercial de soporte para Akvorado importa. Los consultores pueden ayudar en despliegues concretos, pero los materiales examinados no muestran un proveedor que garantice la migración, la respuesta a vulnerabilidades o un nivel de servicio para el proyecto en su conjunto. La organización debe decidir si puede trabajar por su cuenta, contratar experiencia o invertir lo suficiente en upstream para reducir su riesgo.

El coste total depende también del valor del historial conservado. Una red pequeña con un volumen modesto de flujos puede operar económicamente en infraestructura ordinaria. Un gran operador que conserve registros detallados de alta cardinalidad afrontará gastos significativos de disco y base de datos. El denominador útil no es el coste de un servidor, sino el coste de producir pruebas suficientemente fiables para cambiar una decisión operativa.

El límite económico es fácil de pasar por alto, porque los proyectos de código abierto no publican ingresos ni valoración. La sostenibilidad de Akvorado descansa en el trabajo de los mantenedores, el apoyo operativo de Free, las contribuciones externas y la disposición de cada usuario a mantener las dependencias. El proyecto puede crear un enorme valor aguas abajo sin un balance que lo mida.

Un proyecto abierto puede seguir dependiendo de pocos mantenedores

Vincent Bernat es el principal iniciador y mantenedor público vinculado a Akvorado. El repositorio registra contribuciones de otras personas, y las versiones, incidencias y pull requests hacen visible el desarrollo. En los materiales examinados no se han encontrado una fundación independiente, un consejo electo, un órgano formal de miembros ni un esquema completo de financiación.

La gobernanza en torno al repositorio tiene fortalezas reales. Las decisiones dejan rastro público. Los usuarios proponen cambios, leen las discusiones y crean una bifurcación si no están de acuerdo con la dirección. La licencia y el código fuente ofrecen una salida técnica que un servicio cerrado no tiene. El proyecto puede responder con rapidez cuando los mantenedores comparten un modelo operativo claro.

Esa misma estructura concentra la autoridad práctica. Los mantenedores deciden qué cambios entran en las versiones oficiales, cómo se mantendrá la compatibilidad y qué errores recibirán atención. El conocimiento de inlet, del esquema dinámico, de los clasificadores y de las migraciones puede estar en pocas manos. Una bifurcación es legalmente posible pero operativamente costosa si la comunidad que se marcha no posee ese conocimiento.

El apoyo de Free reduce parte del riesgo de continuidad al vincular el proyecto a un entorno de producción. A la vez crea una dependencia de prioridades no divulgadas por completo públicamente. Si los requisitos de la empresa cambian, los mantenedores cambian de rol o el apoyo disminuye, los usuarios externos deben saber si una comunidad más amplia podrá sostener las versiones, la seguridad y las actualizaciones de dependencias.

Los proyectos upstream añaden otra capa de control distribuido. Kafka y ClickHouse fijan sus propios planes. Los fabricantes cambian el comportamiento de los exportadores. Las organizaciones de estandarización desarrollan el trabajo en torno a IPFIX y BMP. Las bases externas cambian esquemas y licencias. Akvorado puede adaptarse, fijar versiones o sustituir componentes, pero no puede prohibir esas decisiones.

Una gobernanza madura no exige convertir a Akvorado en una gran fundación. Debe hacer comprensible la continuidad. Una política documentada de versiones, un círculo más amplio de mantenedores, un proceso de seguridad, compromisos de compatibilidad y un plan de sucesión mostrarían qué ocurriría si se tensan las actuales relaciones informales. A la fecha del estudio no existía un mecanismo público completo.

La apertura del proyecto debe describirse con precisión. El código y buena parte de las decisiones son públicos. La financiación, el reparto del tiempo y la sucesión se ven peor. La transparencia reduce la dependencia de la confianza, pero no elimina la dependencia de las personas.

El mejor panel muestra su denominador

La contribución de Akvorado no es la promesa de ver toda la red. Es una forma de conservar e investigar observaciones seleccionadas mucho después de que los dispositivos que las generaron cambiaron de estado. El proyecto une la exportación de los routers, las colas, el enriquecimiento, el almacenamiento y las consultas en una forma que el operador puede verificar y ejecutar por su cuenta.

Los usos más fuertes aceptan la incertidumbre en lugar de ocultarla. Los equipos de capacidad siguen tendencias estables y contrastan las sumas de flujos con los contadores. Los equipos de peering buscan relaciones y comprueban las reglas de clasificación. La respuesta a incidentes acota tiempo y ámbito mientras busca datos de enrutamiento, registros, paquetes y extremos. Los equipos de privacidad mantienen la información localmente y limitan el acceso y el plazo.

El principal modo de fallo es primero epistémico y solo después técnico: un gráfico limpio hace que un denominador desconocido parezca exacto. Exportadores ausentes, muestreo de paquetes, pérdida de UDP, consumidores retrasados, información de interfaces anticuada y etiquetas retrospectivas pueden construir una línea plausible. El sistema es más seguro cuando esas condiciones se miden junto al tráfico en lugar de esconderse como detalles de implementación.

Ese es también el mejor test de la siguiente etapa de Akvorado. La frecuencia de versiones tras la 2.4.1 mostrará si la arquitectura 2.x sigue siendo mantenible. Los despliegues independientes revelarán el coste de la migración, la pérdida de datos, la velocidad de consulta y la carga operativa general. Una contabilidad temporal más precisa del enrutamiento y los metadatos reforzará el análisis histórico. Un proceso de seguridad y gobernanza más amplio reducirá el riesgo de continuidad.

El éxito no exige sustituir cada plataforma gestionada ni un estatus de estándar universal. El proyecto necesita seguir siendo bueno en una tarea más estrecha: convertir una exportación de flujos incompleta en una memoria honesta y duradera del funcionamiento de la red. La prueba decisiva es si los operadores pueden rastrear la línea de la pantalla de vuelta hasta los dispositivos, el muestreo, las colas, los metadatos y las reglas, y explicar qué demuestra y qué no demuestra.