6. Observabilidad#

El módulo de ventilación de un router troncal de un proveedor de servicios falló silenciosamente durante la noche. No hubo alertas. El subsistema de gestión térmica de las tarjetas de línea detectó el aumento de temperatura y comenzó a reducir la velocidad de los ASICs de reenvío para proteger el hardware. El rendimiento en un enlace de tránsito en producción cayó un 40 %. El sistema de monitorización no vio nada: los sensores térmicos que sondeaba estaban en el supervisor del chasis, no en las tarjetas de línea individuales. Los sondeos SNMP se ejecutaban cada cinco minutos e informaban del dispositivo como sano. Los contadores de interfaz mostraban un menor rendimiento, pero no había ningún umbral configurado para ese patrón porque el enlace siempre había estado muy por debajo de su capacidad.

Tres horas después, una violación del SLA de un cliente generó un ticket. El ingeniero de guardia accedió por SSH al router, observó el fallo del ventilador en el registro de alarmas local y reinició el módulo de ventilación. El controlador de ventiladores se reinició y la reducción térmica se levantó en minutos. El tráfico se recuperó. La violación del SLA fue documentada, el cliente fue notificado y el incidente se cerró.

La causa raíz nunca se confirmó. Para cuando alguien investigó, el router llevaba horas funcionando con normalidad. No había datos térmicos de las tarjetas de línea, no había registro del evento de reducción y no había forma de correlacionar la caída de rendimiento con el fallo del ventilador en ningún sistema de monitorización. El informe del incidente concluyó: “presunto problema de hardware, resuelto mediante reinicio de hardware”. Volvió a ocurrir seis meses después en otro router.

El fallo no fue un umbral que faltaba. El equipo tenía miles de umbrales. El fallo fue una cobertura incompleta: el sistema de monitorización recopilaba datos de las fuentes que siempre se habían sondeado, no de todas las fuentes que podían cambiar el comportamiento del dispositivo. Los datos térmicos de las tarjetas de línea estaban disponibles vía gNMI en los tres tipos de chasis de la flota. Nadie había configurado la ruta de recopilación porque nadie había escrito un runbook para fallos de ventiladores.

La monitorización de redes tradicional vigila las cosas que están rotas: ¿está la interfaz activa? ¿Supera la CPU el 90 %? ¿Responde este servicio? Es útil, pero reactiva: se observa el fallo.

La observabilidad es diferente. Trata de entender por qué las cosas fallan o están a punto de fallar. No es solo “ese dispositivo está caído” sino “por qué está caído, qué se rompe como consecuencia, cuál es el impacto en el negocio”. Con la automatización de redes, la observabilidad se convierte en el bucle de retroalimentación: se observa algo, el sistema lo detecta, decide cómo responder, actúa y verifica que la solución funcionó. Eso es la automatización de bucle cerrado.

Este capítulo cubre todo lo necesario para ver qué está ocurriendo en la red: qué datos recopilar, cómo recopilarlos, cómo almacenarlos, cómo generar alertas sobre ellos y cómo mostrárselos a las personas de una manera que realmente les ayude a tomar decisiones.

Aquí se cubren dos bloques constructivos: Collector y Observability, porque están estrechamente conectados.

Tanto si se usa una plataforma todo-en-uno tradicional (SolarWinds, LibreNMS), un servicio en la nube (Datadog, New Relic) o se construye una pila propia a partir de piezas de código abierto (Prometheus, Grafana, etc.), la arquitectura subyacente es la misma. Entender esos patrones ayuda a elegir el enfoque adecuado para la escala y el equipo.

Esta sección está fuertemente influenciada por el libro Modern Network Observability de Packt, coescrito con David Flores y Josh Vanderaa. Si se desea profundizar en la práctica y aprender una implementación con la pila TPG (Telegraf-Prometheus-Grafana) y otras herramientas, se recomienda su lectura.

6.1. Fundamentos#

Antes de entrar en los detalles de bajo nivel, aquí se establecen los fundamentos de la observabilidad de redes dentro de la estrategia de automatización de redes, definiendo sus objetivos, pilares de soporte y alcance.

6.1.1. Contexto#

Probablemente ya se monitoriza la red. Se usa Simple Network Management Protocol (SNMP), se revisa el System Logging Protocol (Syslog), hay dashboards que muestran la utilización de los enlaces. Eso es monitorización: indica si las cosas funcionan.

Pero la automatización necesita más. Cuando la red cambia (porque la automatización la cambió), es preciso saber de inmediato si algo se rompe. Cuando llega una alerta, se necesita contexto: ¿a qué clientes afecta? ¿Qué servicios fallaron? ¿Cuál es el radio de impacto? La monitorización tradicional genera alarmas. La automatización necesita inteligencia.

La diferencia clave es la siguiente:

• Monitorización: ¿Está la interfaz activa? ¿Es alta la CPU? Preguntas simples de sí o no.
• Observabilidad: ¿Por qué cayó la interfaz? ¿Qué está afectando? ¿Cómo se resuelve automáticamente? ¿Qué ocurrió históricamente que llevó a esto?

La observabilidad alimenta la automatización. El sistema observa la red, detecta problemas, decide qué hacer, actúa y verifica que la solución funcionó. Ese ciclo que se repite se denomina “automatización de bucle cerrado”.

Las herramientas de monitorización tradicionales (las grandes plataformas monolíticas como SolarWinds) intentan hacer todo en un solo producto. Puede funcionar, pero a menudo se paga por características que no se necesitan y se está limitado por características que sí se necesitan. La alternativa es construir la observabilidad a partir de piezas: elegir el colector que funciona para los dispositivos, el almacenamiento que escala con los datos, las alertas que se ajustan a los flujos de trabajo de automatización. Es más difícil de ensamblar, pero mucho más flexible.

Este capítulo recorre ambos enfoques y los patrones que funcionan independientemente de cuál se elija.

Una elección inicial es sobre cómo se ejecuta la plataforma:

• Monolítica (SolarWinds, LibreNMS): Un producto lo hace todo. Se instala, se configura y ya está. Adecuado si la red es sencilla y no se tiene experiencia en DevOps. Malo si se quiere flexibilidad o la red es inusual: se está atrapado en su modelo.

• Cloud SaaS (Datadog, New Relic, Kentik): Ellos gestionan todo. Rápido de desplegar, sin problemas de infraestructura, dashboards atractivos desde el primer momento. Pero se paga mensualmente según el volumen, los datos residen en sus servidores (relevante para algunos regímenes de cumplimiento) y cuando se alcanzan sus límites, no hay salida. Se han visto equipos gastando 50.000 dólares al mes en observabilidad SaaS preguntándose por qué su director financiero no está contento.

• Construido propio (Prometheus + Grafana, o pila Telegraf-Prometheus-Grafana (TPG)): Flexibilidad total, sin dependencia de proveedores, mejor economía a escala. Pero ahora se gestionan bases de datos, colas de mensajes e infraestructura de colectores. Si no se cuenta con personas que puedan operar esto, se pasará más tiempo arreglando la observabilidad que arreglando la red.

La pregunta real: ¿Se tiene el equipo para gestionarlo? Si la respuesta es sí, constrúyelo. Si no, cómpralo. No hay que engañarse sobre en qué categoría se está.

Tras esa elección, surgen dos preguntas más:

• ¿Dónde se ejecuta? En las propias instalaciones (control total, pero se gestiona), en la nube (ellos lo gestionan, pero los datos salen de la red) o en modo híbrido (algunos componentes locales, otros en la nube).
• ¿Cuál es el modelo de costes? ¿Por dispositivo? ¿Por métrica ingerida? ¿Suscripción plana? Estas decisiones se acumulan rápidamente cuando se recopilan millones de puntos de datos por minuto.

6.1.2. Objetivos#

El sistema de observabilidad necesita hacer siete cosas:

1. Observar todo automáticamente. ¿Se conecta un nuevo dispositivo? Debería comenzar a reportar datos sin que nadie lo registre manualmente. ¿Entra en funcionamiento un nuevo servicio? Ya está siendo monitorizado. Esto requiere integración con la fuente de verdad para que la observabilidad sepa qué existe.

2. Gestionar entornos heterogéneos con buenos datos. La red probablemente tiene dispositivos de Cisco, Arista, Juniper, proveedores de nube, servidores Linux, contenedores. Cada uno expone datos de formas distintas. Y hay que olvidarse de los intervalos de cinco minutos: se necesitan datos en tiempo casi real cuando la automatización está realizando cambios.

3. Correlacionar datos entre capas. Un servidor está lento. ¿Es congestión de red o es un problema de base de datos? Se necesitan datos de dispositivos de red, servidores y aplicaciones, todos hablando el mismo idioma, para poder trazar líneas entre ellos.

4. Escalar sin colapsar. Las redes crecen. Cuando se recopila un millón de métricas por segundo, las arquitecturas tradicionales se derrumban. Se necesitan sistemas diseñados para escalar desde el primer día.

5. Permitir que las personas analicen los datos de forma inteligente. Dar a los analistas acceso para consultar los datos, no solo dashboards predefinidos, sino consultas potentes para que puedan responder sus propias preguntas. Y necesitan tanto datos en tiempo real como históricos (tendencias, detección de anomalías).

6. Detectar problemas y resolverlos automáticamente. La mayor parte del tiempo, la automatización debería responder a los problemas sin esperar a un humano. Solo cuando la automatización no puede resolverlo debería alertarse a alguien. Y esa alerta debe explicar qué está mal, no solo mostrar números en bruto.

7. Mostrar a las personas lo que necesitan ver. Un dashboard no sirve de nada si muestra demasiado o lo incorrecto. Hay que dar al equipo de operaciones de red su vista, al negocio la suya y a los ingenieros la suya. Cada persona obtiene lo que le ayuda a hacer su trabajo.

6.1.3. Pilares#

Cada objetivo necesita bloques constructivos específicos para funcionar. Estos son los necesarios:

1. Saber qué observar. La fuente de verdad tiene todos los dispositivos, servicios y credenciales. La observabilidad debe extraer esos datos automáticamente para que los colectores sepan qué monitorizar. Cuando se añade un dispositivo a la SoT, la monitorización entra en línea automáticamente.

2. Recopilar datos eficientemente. Se necesitan múltiples métodos de recopilación: Simple Network Management Protocol (SNMP) para equipos más antiguos, streaming con gRPC Network Management Interface (gNMI) para dispositivos modernos, System Logging Protocol (Syslog) para eventos, flujos (NetFlow, IP Flow Information Export (IPFIX)) para tráfico, quizás capturas de paquetes para diagnóstico profundo. Distintas herramientas, distintas velocidades, distinta riqueza de datos. La buena noticia: no hay que elegir solo una.

3. Normalizar todo. Las métricas de Arista son distintas de las de Cisco, que son distintas de las de los proveedores de nube. Los logs son texto no estructurado, los flujos son binarios. Se necesita una capa que traduzca todo esto a un lenguaje común y añada contexto (qué dispositivo, qué cliente, qué servicio).

4. Mover los datos de forma fiable a escala. Los pipelines de monitorización tradicionales son secuenciales: colector -> procesador -> almacenamiento. A escala, esto es un cuello de botella. Se necesitan buses de mensajes y plataformas de streaming que desacoplen cada etapa para que puedan escalar de forma independiente.

5. Almacenar de forma inteligente. Los datos de series temporales (métricas) necesitan bases de datos optimizadas para ello. Los logs necesitan algo diferente. Hay que consultar millones de puntos de datos en milisegundos. No todas las bases de datos son iguales para esto.

6. Transformar los datos en acciones. Las métricas en bruto no disparan la automatización. Se necesitan reglas: “si la CPU supera el 90 %, comprobar si es mantenimiento previsto; si no, seguir estos pasos”. Y esas reglas se incorporan al orquestador de automatización o al sistema de alertas.

7. Mostrarlo visualmente. Los datos son inútiles si nadie los mira. Se necesitan dashboards, pero inteligentes: distintas vistas para distintas personas, con capacidad de profundizar, mostrar tendencias y comparaciones.

Por último, antes de detallar las siete funcionalidades que realizan estos pilares, conviene aclarar qué entra en el alcance de la Observabilidad.

6.1.4. Alcance#

Para ampliar los objetivos introducidos anteriormente, hay otros puntos que también pertenecen a las responsabilidades de la Observabilidad:

• Distintos niveles de observación adaptados a las perspectivas de los usuarios (técnica, operativa, de negocio)
• Integración con pipelines de CI/CD, proporcionando retroalimentación para pruebas y validación automatizadas
• Observabilidad del propio sistema de automatización (meta-monitorización de Collectors, procesadores y sistemas de alertas)

Sin embargo, hay funciones que pertenecen a otros componentes de la arquitectura:

• Definir la intención de red: cómo debería ser la red (responsabilidad de la SoT)
• Ejecutar cambios de red: implementar realmente la remediación (responsabilidad del Executor)
• Orquestar flujos de trabajo complejos: coordinar la remediación multietapa entre múltiples sistemas (responsabilidad del Orchestrator)

Este límite claro garantiza que Observability se centre en la detección y los insights, mientras que otros bloques constructivos gestionan la definición de la intención, la ejecución y la orquestación.

La transición a una observabilidad moderna requiere una planificación cuidadosa. No hay que tomarlo como algo tan simple como reemplazar una herramienta de monitorización por otra; hay que transformar la mentalidad. A mayor potencia, mayor responsabilidad, y habrá más que elegir y ajustar.

Tras esta introducción inicial que expone los conceptos clave relacionados con el bloque de Observabilidad, a continuación se aborda cada funcionalidad.

6.2. Funcionalidades#

Los siete objetivos y pilares se realizan a través de siete funcionalidades principales. Cada funcionalidad se corresponde con un objetivo y su pilar de soporte, creando una cadena directa desde los requisitos de negocio hasta la implementación técnica:

1. Inventario: Consume la intención de la SoT y proporciona los metadatos, listas de dispositivos y objetivos de recopilación a todos los componentes posteriores.
2. Collector: Recupera los datos observados de la red usando múltiples protocolos y métodos de recopilación, tanto basados en sondeo (pull) como en streaming (push).
3. Procesador: Normaliza los datos heterogéneos en un esquema común y los enriquece con metadatos contextuales (etiquetas, relaciones, contexto de negocio), además de realizar otras operaciones sobre los datos.
4. Distribución: Desacopla los productores de datos de los consumidores usando patrones distribuidos y asíncronos. Mueve datos y eventos de forma fiable desde los Collectors a través de los procesadores hasta los sistemas de persistencia y alertas.
5. Persistencia: Almacena los datos normalizados en bases de datos optimizadas para la ingesta, retención y consulta eficiente a escala.
6. Alertas: Analiza los datos persistidos usando reglas y umbrales flexibles para detectar condiciones de interés, generando eventos que disparan sistemas externos (automatización o notificaciones humanas).
7. Visualización: Renderiza los datos observados y los eventos disparados en dashboards, informes y otras interfaces visuales adaptadas a distintas audiencias y casos de uso.

graph LR

    %% --- Subgraphs ---
    subgraph Goals["Objetivos"]
        direction TB
        A1[Observar toda la red con el mínimo esfuerzo humano]
        A2[Soportar entornos de red heterogéneos con suficientes datos y precisión]
        A3[Observar datos de diferentes capas IT con contexto]
        A4[Manejar escenarios de red a escala masiva]
        A5[Ofrecer acceso a datos de observabilidad para análisis sofisticado en tiempo casi real]
        A6[Ser proactivo para detectar problemas de red y reducir el tiempo de recuperación]
        A7[Crear visualizaciones personalizadas orientadas al usuario]
    end

    subgraph Pillars["Pilares"]
        direction TB
        B1[Integración estrecha con la SoT para saber qué necesita monitorizarse]
        B2[Capacidad de recopilar datos por distintos protocolos con actualizaciones muy frecuentes o bajo demanda]
        B3[Normalización de datos heterogéneos con metadatos contextuales para un análisis más rico]
        B4[Sistemas de distribución de datos escalables para arquitecturas de escala horizontal]
        B5[Capa de persistencia que soporta datos de series temporales y lenguajes de consulta potentes]
        B6[Definiciones de reglas flexibles y escenarios de enrutamiento con integración de sistemas externos]
        B7[Visualizaciones personalizadas e integración de múltiples almacenes de datos]
    end

    subgraph Functionalities["Funcionalidades"]
        direction TB
        C1[Inventario]
        C2[Colector]
        C3[Procesador]
        C4[Distribución]
        C5[Persistencia]
        C6[Alertas]
        C7[Visualización]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

Estos componentes pueden verse como un pipeline de datos o ETL (Extract, Transform and Load), con el siguiente diagrama:

flowchart TB
    A[Red] --> B[Colector]

    subgraph Observability
       direction LR
       B --> C[Distribución] -->  D[Persistencia]
       B -.-> P[Procesamiento]
       C -.-> P
       D -.-> P
       D --> E[Alertas]
       E -.-> P
       D --> G[Visualización]
       X[Inventario] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[Orquestación]
    G -.-> H[Presentación]
    Y[SoT] -.-> X

Figura 1: Pipeline de Observabilidad.

6.2.1. Inventario#

El componente de inventario responde a una pregunta sencilla: ¿qué debería estar monitorizando?

Ya se tiene esta información en algún lugar: está en la fuente de verdad. Hay nombres de dispositivos, direcciones IP, qué son, si están activos y credenciales. No hay que duplicarlo manualmente. Hay que importarlo automáticamente.

Lo que se necesita de la SoT:

• Un nombre o ID único para cada dispositivo o servicio (para saber que es el dispositivo que se cree)
• Cómo alcanzarlo: dirección IP, nombre de host y credenciales (si se necesita extraer datos activamente)
• Qué es: el tipo y el proveedor (para saber qué Collectors funcionan con él)
• Si está activo: si está planificado, activo o en proceso de retirada (para no alertar por caídas previstas)

Más allá de lo básico, también puede interesar:

• Especificaciones del sistema operativo o del dispositivo: algunos dispositivos usan protocolos distintos, algunos son antiguos y necesitan un tratamiento especial
• Contexto: quién lo posee, dónde está ubicado, qué clientes dependen de él (útil para filtrar alertas y dashboards)

¿Por qué automatizar esto en lugar de construir una lista manualmente? Porque la gente se olvida de actualizar las listas. Se añaden dispositivos y nadie se lo dice a la monitorización, y de repente se pierde visibilidad. Pero si la observabilidad lee de la SoT, cuando se añade un dispositivo ahí, automáticamente empieza a monitorizarse.

¿Push o pull?

• Pull: La observabilidad consulta la SoT periódicamente en busca de actualizaciones. Simple, pero si algo cambia en medio del intervalo, se pierde.
• Push: Cuando la SoT cambia, señala automáticamente a la observabilidad (webhooks, bus de mensajes). Más rápido y fiable.

Si se tienen buenos datos en la SoT y una integración real (no copiar y pegar manualmente), el inventario se vuelve automático y nunca se pierde la observación de un nuevo dispositivo.

6.2.2. Colectores#

Los datos tienen que venir de algún lugar. Los Collectors son los puentes entre la red y la plataforma de Observability. Son responsables de extraer (o recibir) datos de los dispositivos y alimentarlos al pipeline. Sin Collectors eficaces, todo lo que hay más abajo no vale nada.

Hay dos enfoques fundamentales desde la perspectiva de quién controla el flujo de datos:

• Pasivo o Push: Los dispositivos envían datos al colector. Por ejemplo, servidores syslog que reciben mensajes de log de los routers, o colectores IPFIX que escuchan registros de flujo. El dispositivo decide qué enviar y cuándo.
• Activo o Poll: El Collector pide datos a los dispositivos. Se conecta a cada dispositivo y extrae información usando Simple Network Management Protocol (SNMP), gRPC Network Management Interface (gNMI), Representational State Transfer (REST) Application Programming Interface (API)s o se suscribe a datos en streaming. El Collector tiene el control: decide qué pedir y cuándo.

También se pueden categorizar los colectores por despliegue:

• Sin agente: No hay software que instalar en los dispositivos. Un servidor colector central (normalmente ejecutándose en otro lugar) se conecta a cada dispositivo individualmente. Simple para empezar, pero puede convertirse en un cuello de botella al escalar.
• Basado en agente: Se instala un pequeño agente en cada dispositivo o servicio. Los agentes envían datos a una ubicación central o extraen directamente de fuentes locales. Más distribuido, más fácil de escalar, pero con más componentes que gestionar.

Independientemente del método de recopilación, es importante destacar los distintos tipos de datos que pueden ser de interés en el entorno de automatización de redes. Se clasifican en cuatro grandes categorías:

• Plano de gestión: El estado del dispositivo, o para leer datos sobre la configuración, los logs o las estadísticas de red. Los protocolos de este grupo son Simple Network Management Protocol (SNMP), System Logging Protocol (Syslog), gRPC Network Management Interface (gNMI), NETCONF y RESTCONF.
• Plano de control: Aquí se ejecutan los protocolos distribuidos que determinan el reenvío de paquetes de la red, como las tablas de reenvío de capa 2 o capa 3. Algunos ejemplos de protocolos de plano de control son OSPF, IS-IS y BGP. Estos planos se pueden observar mediante técnicas como Ping o Traceroute, o protocolos de telemetría como BMP.
• Plano de reenvío: Este plano es donde se mueven los paquetes (por ejemplo, las interfaces de red), y es el más exigente en términos de volumen y velocidad de datos. Naturalmente, al observarlo, también es fundamental no impactar el objetivo principal del plano, que es reenviar paquetes. En este grupo se encuentran herramientas como TcpDump, IPFIX, sFlow, Netflow, Cisco SLA, PSAMP y eBPF.
• Datos externos: Esta categoría incluye todo lo que no es específico del dispositivo de red. Por ejemplo, información del proveedor de circuitos y el contacto para una interfaz determinada, procedente de un sistema externo de gestión de activos o sensores físicos de IoT, podrían encajar en este amplio campo.

flowchart TB
    subgraph Network Device/Service["Dispositivo/Servicio de Red"]
        direction TB
        A[Plano de Gestión]
        B[Plano de Control]
        C[Plano de Reenvío]
        A --> B
        B --> C
    end

    D[Datos externos]

Figura 2: Alcance del Colector.

Hay que dejar de hacer scraping de la salida de Command Line Interface (CLI). Todos lo hemos hecho. Pero estamos en 2026 y todos los principales proveedores ya soportan telemetría adecuada.

El scraping de CLI es frágil (los proveedores cambian el formato de salida), lento (el scraping y el análisis de texto es costoso), poco fiable (timeouts aleatorios de comandos) y escala muy mal. Si un dispositivo es tan antiguo que solo tiene CLI, o se reemplaza o se acepta que tendrá observabilidad limitada. No hay que construir toda la pila de monitorización alrededor del mínimo común denominador.

En realidad, se reducen a dos preguntas fundamentales sobre lo que se recopila:

• Qué recopilar: ¿Métricas? ¿Logs? ¿Registros de flujo? Cada uno tiene modelos de datos distintos. SNMP tiene MIBs, los equipos modernos hablan gNMI, las aplicaciones usan OpenTelemetry. El sueño es un estándar universal que permita correlacionar datos de todo, pero eso aún no existe. Por eso puede ser necesario construir una capa de traducción propia que convierta todos estos formatos distintos en algo consistente (que es lo que hace la capa de procesamiento a continuación).
• Cómo obtenerlos: ¿Qué protocolo? SNMP es antiguo pero estable, gNMI es moderno y envía datos continuamente, IPFIX captura lo que realmente fluye. Varía según lo que se trata de observar.

Esta tabla resume qué se puede recopilar y las herramientas disponibles:

Tabla 1: Datos y Protocolos a recopilar.

Para una comprensión más profunda de las distintas opciones, se recomienda el libro Modern Network Observability.

La recopilación de datos de red se aplica a centros de datos, backbones de ISP, servicios de red en la nube, interfaces del kernel de Linux o paquetes en bruto. Depende del entorno.

La clave es la siguiente: antes de decidir qué recopilar, hay que empezar por el problema que se intenta resolver. Esa decisión impulsa todo lo demás. ¿Se detecta la saturación de interfaces? ¿Se monitoriza la convergencia BGP? ¿Se rastrea tráfico DDoS? El problema determina qué datos se necesitan y con qué frecuencia.

Para aumentar la frecuencia de los datos recopilados (interesante en algunos casos) o para convergir métodos de recopilación, estos son algunos patrones que han aumentado su adopción recientemente:

Telemetría en streaming

Los dispositivos envían datos continuamente usando modelos YANG. Se configuran suscripciones y los datos fluyen en tiempo real. Dos variantes:

• Dial-In: El colector pide al dispositivo que empiece a enviar (el colector inicia).
• Dial-Out: El dispositivo está preconfigurado para enviar a la plataforma (el dispositivo inicia).

Latencia mucho menor que el sondeo, y el dispositivo mantiene el control del flujo.

flowchart TB
    A[Colector]
    B[Dispositivo]
    A -.->|Dial-In| B
    B -->|Streaming| A
    B -.->|Dial-Out| A

Figura 3: Telemetría en Streaming.

Métricas expuestas por Hypertext Transfer Protocol (HTTP)

El scraping Hypertext Transfer Protocol (HTTP) (métricas basadas en pull) es simple y escala bien. Simple Network Management Protocol (SNMP) hace esto, pero cada vez más los sistemas operativos de red exponen métricas directamente vía Hypertext Transfer Protocol (HTTP) en formato Prometheus. Más fácil de consumir para los Collectors, sin necesidad de analizar Management Information Base (MIB)s Simple Network Management Protocol (SNMP) especiales. SONiC, Cumulus, Arista EOS y otros exponen métricas de esta manera.

Tabla 2: Métricas expuestas por HTTP.

El enfoque de scraping proporciona baja latencia y métricas en tiempo casi real, etiquetas ricas y recopilación basada en pull (control central de la tasa y el timeout), conectando bien con la observabilidad de escala cloud.

OpenTelemetry

OpenTelemetry es un estándar y toolkit neutro respecto al proveedor para recopilar, procesar y exportar datos de telemetría. Se puede entender como un lenguaje de telemetría y pipeline común que unifica métricas, logs y trazas entre redes, sistemas y aplicaciones.

No reemplaza protocolos de red como SNMP, NetFlow, gNMI o BMP. En cambio, estandariza cómo se representa y transporta la telemetría tras la recopilación.

En la monitorización de redes tradicional, los modelos de datos son diversos y usan esquemas y nombres específicos de proveedor, lo que dificulta la correlación entre capas (red - sistema - aplicación). OpenTelemetry ayuda proporcionando:

• Un modelo de datos común para métricas, logs y trazas
• Un protocolo de transporte estándar (OpenTelemetry Protocol (OTLP)), sobre gRPC Remote Procedure Call (gRPC) o Hypertext Transfer Protocol (HTTP)
• Un único pipeline de procesamiento para múltiples tipos de señal

Grafana Alloy o Telegraf son ejemplos de Collector que implementan OpenTelemetry Protocol (OTLP). Recopilan datos de distintos exportadores y los exportan a diferentes backends como métricas (Time Series Database (TSDB)s compatibles con Prometheus), logs (Loki, Elasticsearch, ClickHouse) y trazas (Tempo, Jaeger).

Y esto nos lleva a una consideración final sobre la estructura común de los colectores modernos y configurables, con etapas de Entrada, Procesamiento y Salida. Por ejemplo, en Telegraf, OTLP es una opción para un plugin de salida.

OpenTelemetry como decisión arquitectónica

Adoptar OpenTelemetry no es solo una decisión de herramientas: es una decisión arquitectónica sobre cómo se unifica el pipeline de observabilidad. La elección es entre dos enfoques:

Nativo al protocolo: cada tipo de señal viaja a través de su protocolo nativo de extremo a extremo (gNMI a Prometheus, syslog a Elasticsearch, NetFlow a ClickHouse). Cada pipeline está optimizado para su señal. El coste son múltiples pipelines independientes sin modelo de datos compartido, lo que hace que la correlación entre tipos de señal sea costosa.

Nativo a OTel: las señales se convierten a OpenTelemetry Protocol (OTLP) lo antes posible y fluyen a través de un único pipeline hacia un backend unificado. La correlación entre métricas, logs y trazas es natural porque comparten un modelo de datos. El coste es que el soporte OTel en dispositivos de red aún está madurando: la mayoría de los proveedores no emiten OTLP de forma nativa, lo que requiere una capa de adaptación (gNMI a OTel, SNMP a OTel) que añade complejidad operativa.

La recomendación práctica para entornos de automatización de redes hoy en día: adoptar OTel para señales adyacentes a las aplicaciones donde el soporte del proveedor es sólido (telemetría de la plataforma de automatización, salud del servicio, logs de aplicación estructurados) y continuar con pipelines nativos al protocolo para la telemetría de red tradicional (sondeo SNMP, streaming gNMI) hasta que el soporte OTel en los dispositivos madure. Diseñar el pipeline para acomodar ambos enfoques en paralelo en lugar de forzar una estandarización prematura que requiera adaptadores para cada dispositivo de red.

La tendencia es clara: OpenTelemetry acabará convirtiéndose en el estándar para todos los datos de observabilidad. Empezar con él para la propia plataforma de automatización (la meta-monitorización del Capítulo 5) es un primer paso de bajo riesgo que construye familiaridad antes de extenderlo a los dispositivos de red.

Arquitectura del Colector

De forma simplificada, cada colector puede desglosarse en tres partes (a veces son configurables y otras veces están más integradas).

flowchart LR
    A[ENTRADA] --> B[PROCESADOR] --> C[SALIDA]

Figura 4: Arquitectura del Colector.

• Entrada: Define qué debe observarse y bajo qué parámetros.
• Procesamiento: Aunque es opcional, resulta muy conveniente en cuanto los datos entran en el pipeline de datos para garantizar la consistencia de la estructura de datos. El procesamiento puede volverse muy complejo y puede impactar el rendimiento a escala, por lo que no todo el procesamiento tiene que hacerse en este nivel.
• Salida: Muestra cómo el colector mueve los datos hacia el pipeline. Puede enviarlos directamente a otros bloques como procesamiento o persistencia, o usar el componente de distribución para escalar.

Hay muchos colectores (cada uno con distintas capacidades) como Telegraf, Grafana Alloy, gNMIc, PMACCT, goflow, etc., pero usan una arquitectura similar. Por eso, al elegir uno (a veces pueden necesitarse varios), el enfoque debería ser:

1. Capacidades del dispositivo: ¿qué protocolos soportan los dispositivos?
2. Volumen de datos: los datos de alto volumen necesitan streaming; los de bajo volumen pueden usar sondeo.
3. Requisitos de latencia: tiempo casi real frente a intervalos tradicionales.
4. Habilidades del equipo y encaje con el ecosistema del backend.

Todas las soluciones “completas” de observabilidad de redes como Suzieq, Kentik y otras también implementan colectores integrados para los datos de observabilidad tratados.

Después de recopilar los datos, un paso que ya se ha introducido es el Procesador, que manipula los datos en distintas etapas del pipeline.

6.2.3. Procesador#

Los datos en bruto de los colectores son desordenados. Distintos dispositivos exportan métricas de formas diferentes, los logs son texto no estructurado y los valores pueden estar en distintas unidades. La capa de procesamiento limpia esto y lo hace útil.

Objetivo: Una vez recibidos los datos, deben ajustarse a estándares compartidos para poder converger señales de múltiples fuentes, correlacionarlas y enriquecerlas con contexto adicional. Sin este paso de procesamiento, los pipelines de observabilidad se fragmentan rápidamente, son difíciles de consultar y costosos de operar. Hay múltiples oportunidades para procesarlos dependiendo de la escala, la complejidad y los requisitos operativos.

A continuación se presentan las acciones de procesamiento comunes que se aplican a los pipelines de observabilidad.

6.2.3.1. Normalización/Transformación#

Los datos llegan en formatos distintos. Arista envía métricas de una manera, Cisco de otra, el syslog es texto, NetFlow es binario. La normalización traduce todo esto a un formato común para que el backend no tenga que entender 50 dialectos distintos.

Estructuración

Los dispositivos emiten datos de formas que tienen sentido para ellos. La tarea es traducirlos a un formato que funcione para el análisis:

• Basado en logs:

  Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

  a

  {
  "timestamp": "2025-03-18T14:22:11Z",
  "level": "INFO",
  "device": "leaf01",
  "component": "interface",
  "event": "oper_state_change",
  "interface": "swp1",
  "previous_state": "UP",
  "current_state": "DOWN"
  }

• Basado en métricas: <nombre_métrica>{<etiquetas>} <valor>

  interface_admin_state{hostname="leaf01", ifname="swp1"} 1
  interface_oper_state{hostname="leaf01", ifname="swp1"} 0
  interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
  interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
  interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

• Basado en tabla: algunas herramientas (por ejemplo, Suzieq) organizan los datos en vistas de estado tabulares e indexadas por tiempo:

  | hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
  |----------|--------|------------|-----------|-------|----------|-----------|-----------|
  | leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
  | leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

Renombrado y alineación

Distintas fuentes de telemetría describen el mismo concepto usando distintos nombres, rutas y convenciones de etiquetas. Por ejemplo:

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

La normalización los alinea en un modelo consistente, incluyendo el nombre del objeto, el renombrado de etiquetas y el valor (usando la misma conversión de unidades):

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. Enriquecimiento#

El enriquecimiento añade contenido extra a los datos de observabilidad más allá de lo que realmente se observa. Estas dimensiones extra añadidas a los datos permiten un consumo más sofisticado. Por ejemplo, se puede entender que las métricas pertenecen a un dispositivo que desempeña un rol específico en la red y actuar en consecuencia.

Hay dos enfoques principales para el enriquecimiento:

• Extensión de datos Añadir metadatos o etiquetas extra a los datos observados para complementarlos. Estos datos podrían ser estáticos (por ejemplo, org=mi-empresa) para marcar todos los datos, dinámicos basados en el contexto de recopilación (por ejemplo, collector_id=1234), o dinámicos basados en los propios datos observados (por ejemplo, dado hostname=rtr-1, crear una etiqueta location=BCN-01 correlacionando con la SoT).

  intf_oper_state{
      name="swp1", 
      device="leaf01",
      role="leaf",
      location="BCN0001"
  } 1

• Creación de nuevos datos Siguiendo el patrón de “métricas de información” del ecosistema Prometheus, se pueden generar métricas que no representan el estado real sino el estado previsto. Estas métricas son útiles en etapas posteriores del pipeline de observabilidad para añadir más dimensiones al análisis, como se verá en la sección de Alertas.

  device_info{
      name="leaf1",
      role="leaf",
      vendor="arista",
      model="7050SX3",
      platform="eos",
      os_version="4.29.2F",
      location="BCN0001",
      rack="AB1",
      rack_unit="U32",
      environment="prod"
  } 1

  Las métricas de información son un tipo curioso de datos que no tienen el dato relevante en el valor (por ejemplo, el 1 de las métricas anteriores) sino en las etiquetas. Este truco permite reutilizar Time Series Database (TSDB)s que no soportan ciertos tipos de valores (como cadenas de texto).

Ambos enfoques añaden etiquetas y contexto. Eso es muy útil para las alertas y el análisis. Pero hay un coste que considerar:

• Cardinalidad: Cada nueva etiqueta multiplica las series temporales. Dispositivo × interfaces × métricas ya tiene alta cardinalidad. Añadir etiquetas sin criterio hace que el almacenamiento explote y las consultas se ralenticen. Hay que ser reflexivo.
• Frecuencia de actualización: Los racks de los dispositivos y las IPs de gestión no cambian cada segundo. No hay que sondear los datos de enriquecimiento como si fueran métricas volátiles. Las actualizaciones basadas en eventos funcionan mejor, con menos consultas a la fuente de verdad.
• Resiliencia: Si la fuente de verdad se cae, el enriquecimiento se detiene. Hay que mantenerlo en caché para seguir operando, aunque sea de forma degradada. La automatización depende de estos datos, así que deben ser sólidos.

6.2.3.3. Transformación / Derivación / Agregación#

Tomar métricas en bruto y derivar nuevas a partir de ellas. Ejemplo: combinar todo el tráfico de entrada de las interfaces de switches leaf y spine en una única métrica de “ancho de banda del fabric utilizado” para tendencias. Se están combinando datos existentes para responder preguntas más amplias o alimentar dashboards. Prometheus llama a esto “recording rules”.

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

En el ecosistema Prometheus, esto se conoce como recording rules.

Otra funcionalidad de procesamiento para reducir la cantidad de datos es la agregación, reduciendo la dimensionalidad ajustada al uso final de los datos. Por ejemplo, resumir información de interfaces por dispositivo, o resumir información de dispositivos por sede. También puede ser útil crear cálculos de tasas a partir de métricas de contadores, o agrupar en histogramas, para muchos análisis.

6.2.3.4. Filtrado#

Eliminar la basura pronto. No todos los logs merecen almacenarse. No todas las métricas de interfaz importan (quizás no interesen los loopbacks). Cuanto antes se filtre, menos se desperdicia en almacenamiento y procesamiento. Las listas de permitidos (solo conservar esto) son más seguras que las listas de bloqueados (descartar aquello).

6.2.3.5. Muestreo / Throttling#

Incluso después de filtrar, el volumen puede seguir siendo demasiado alto. Hay que limitarlo. Muestrear probabilísticamente (“conservar el 10 % de estas solicitudes”), centrarse en las métricas top-K (“almacenar solo las 100 interfaces más ocupadas”) o limitar la tasa por fuente (“máximo 1000 métricas por dispositivo”). A medida que los datos envejecen en la base de datos, se agregan (la granularidad de 5 segundos se convierte en promedios de 5 minutos) para ahorrar espacio.

Por último, todos estos procesadores pueden ejecutarse en distintas etapas del pipeline de observabilidad, dependiendo del caso de uso:

• Colector: El mejor para normalización ligera y filtrado temprano
• Procesador dedicado: Necesario a escala para el enriquecimiento dinámico y las transformaciones complejas
• Capa de persistencia: Adecuada para recording rules y rollups a largo plazo (la normalización siempre debe ocurrir antes)
• Capa de alertas: Deriva eventos de los datos almacenados y aplica la lógica de negocio

En la práctica, los pipelines de observabilidad eficaces distribuyen el procesamiento entre capas, dependiendo de las herramientas, la escala y las restricciones operativas.

6.2.4. Distribución#

Los pipelines lineales simples (colector -> procesador -> base de datos) no escalan. Si la base de datos se ralentiza, el colector se atasca. Si es necesario actualizar el procesador, se detiene la recopilación. Todo está estrechamente acoplado y es frágil.

Aquí es donde entran los brokers de mensajes.

Los brokers de mensajes como Apache Kafka o NATS se ubican en el medio. Los productores (colectores, dispositivos) publican en topics. Los consumidores (procesadores, bases de datos, alertas) consumen a su propio ritmo. Totalmente desacoplados.

Ventajas:

• Escalabilidad: Cada componente escala de forma independiente.
• Resiliencia: Si un consumidor es lento, los datos se acumulan en cola en lugar de perderse.
• Flexibilidad: Los mismos datos alimentan múltiples backends sin duplicación en el origen. Se puede actualizar o reiniciar un componente sin afectar a los demás.

Ver el Capítulo 11 para más información sobre patrones de escalado y fiabilidad.

6.2.5. Persistencia#

Una vez procesados los datos, necesitan tener un lugar donde vivir. La capa de base de datos almacena todos los datos de observabilidad. Debe gestionar enormes volúmenes, soportar consultas rápidas y mantener los costes razonables.

Las buenas bases de datos para observabilidad comparten características comunes:

• Conscientes del tiempo: Los datos están inherentemente marcados con timestamps. Las bases de datos optimizan para consultas de rango y cálculos con ventanas de tiempo.
• Alto rendimiento de escritura: La ingesta constante de métricas. Las bases de datos lo gestionan sin ralentizarse.
• Multidimensionales: Las métricas llevan etiquetas (dispositivo, interfaz, ubicación). Se consultan y agregan eficientemente.
• Consultas flexibles: Se necesitan lenguajes expresivos (PromQL, LogQL) para explorar datos sin esquemas predefinidos.
• Gestión del ciclo de vida: El almacenamiento crece rápido. Se soporta retención, downsampling y eliminación para controlar los costes.
• Flexibilidad de esquema: Aparecen nuevas métricas constantemente. Las bases de datos gestionan la evolución sin costosas migraciones.

¿Qué tipos de bases de datos funcionan?

Ninguna base de datos gestiona perfectamente todas las cargas de trabajo de observabilidad, y quien diga lo contrario está vendiendo algo. Lo que realmente funciona:

1. Bases de datos de series temporales (Time Series Database (TSDB)): Por aquí hay que empezar. Prometheus ganó la batalla de las métricas. Su modelo de datos (métricas con etiquetas) se convirtió en el estándar de facto, y PromQL es el lenguaje de consulta que todo el mundo conoce. Se puede usar Prometheus si se tienen menos de 100 millones de series activas. A partir de ahí, hay que mirar VictoriaMetrics (compatible con Prometheus, escala mejor, usa menos memoria). InfluxDB está bien, pero sus licencias siguen cambiando. Hay que evitar soluciones específicas de proveedor salvo que ya se esté en su ecosistema.

2. Bases de datos columnares: ClickHouse es el rey aquí. Es absurdamente rápido para la agregación de logs y el análisis de flujos. Si se necesita consultar miles de millones de filas para informes o análisis histórico, esta es la herramienta. InfluxDB v3 intenta competir, pero ClickHouse tiene años de madurez. Los ficheros Parquet funcionan para cargas de trabajo analíticas donde no se necesitan escrituras en tiempo real (como hace Suzieq).

3. Bases de datos de búsqueda de texto: Elasticsearch si no hay más remedio, pero honestamente, alternativas modernas como Loki (de Grafana) son más simples y baratas de operar. Splunk es excelente si alguien más lo paga. El secreto sucio: la mayoría de los equipos invierten demasiado en búsqueda de logs y demasiado poco en el logging estructurado que haría innecesaria esa búsqueda.

La recomendación: empezar con Prometheus (o similar) para métricas, Loki (o similar) para logs. Añadir ClickHouse (o similar) cuando se necesite análisis histórico serio. Esa pila aguantará hasta una escala enorme antes de necesitar algo más sofisticado.

Esta clasificación no es absoluta; la mayoría de las herramientas tienen una clasificación principal, pero luego implementan algunas características de otras (especialmente series temporales).

Dos conceptos importantes al diseñar el almacenamiento: cardinalidad (cuántos valores únicos puede tomar una etiqueta) y dimensionalidad (cuántas etiquetas tiene una métrica). Etiquetas de alta cardinalidad multiplicadas por muchas dimensiones equivale a una explosión en los datos almacenados y consultas lentas. Este es uno de los mayores retos en observabilidad. Ver el Capítulo 11 para consideraciones de escalado en profundidad.

Después de toda la gestión de datos, hay dos pasos finales:

• Crear eventos para que los use la automatización o para que intervengan personas: Alertas
• Visualizar los datos para proporcionar información que apoye la toma de decisiones: Visualización

6.2.6. Alertas#

Las alertas convierten los datos en acciones. El objetivo: alimentar la automatización con ellas. Notificar a los humanos cuando la automatización no puede resolverlo.

Las alertas fluyen por etapas:

• Detección: Encontrar algo incorrecto en los datos.
• Procesamiento: Enriquecer con contexto. ¿Es crítico? ¿Menor? ¿Falsa alarma? Correlacionar alertas relacionadas para reducir el ruido.
• Enrutamiento: Enviar a la orquestación (ejecutar flujos de trabajo), a los equipos (Slack) o a la gestión de incidentes (PagerDuty).
• Escalado: Si la automatización falla, los humanos intervienen.

flowchart LR
    A[Detección] --> B[Procesador] --> C[Enrutamiento] --> D[Escalado]

Figura 5: Etapas de las Alertas.

La parte difícil no es configurar las alertas. Es prevenir la fatiga por alertas. Se han visto NOCs con 10.000 alertas activas donde nadie las mira ya. En ese punto, no se tiene monitorización, se tiene ruido caro.

Así es como realmente se soluciona:

1. Enrutar el 95 % de las alertas a la automatización, no a los humanos. Si un humano ve una alerta, debería ser porque la automatización lo intentó y falló. ¿Una interfaz oscilando? La automatización comprueba si es mantenimiento, reinicia la óptica, abre un ticket con el proveedor. El humano solo recibe la alerta si la automatización no puede resolverlo.

2. Eliminar los umbrales estáticos. Las alertas de “CPU > 80 %” son inútiles. El 80 % puede ser normal para ese dispositivo. Hay que usar baselines dinámicas: alertar cuando algo se desvía de su patrón histórico, no de un número arbitrario.

3. Agrupar alertas relacionadas. Cuando un switch troncal falla, se generarán 500 alertas de los dispositivos dependientes. Mostrar una: “Switch troncal caído, 500 dispositivos afectados”. No 500 alertas individuales.

4. Exigir un runbook para cada alerta. Si no se puede escribir qué debe hacer alguien cuando recibe la alerta, hay que eliminarla. En serio. Si la acción es “investigar”, eso no es una acción, es una pérdida de tiempo.

5. Medir la calidad de las alertas. Rastrear las tasas de falsos positivos. Cualquier alerta con más de un 10 % de falsos positivos debe corregirse o eliminarse. Rastrear el tiempo de reconocimiento. Si las alertas están sin reconocer durante horas, no son lo suficientemente importantes como para existir.

El objetivo no es “monitorización exhaustiva”. El objetivo es “solo alertar a los humanos sobre cosas que los humanos necesitan resolver”.

6.2.6.1. El papel de la IA y AIOps en la observabilidad#

Dejemos a un lado el marketing: la mayoría de la “observabilidad potenciada por IA” es solo detección de anomalías con un presupuesto de marketing. Dicho esto, hay valor real aquí si se despliega correctamente.

Lo que realmente funciona:

• Detección de anomalías: El aprendizaje automático es genuinamente mejor que los umbrales estáticos para aprender qué es “normal” para cada dispositivo. Una CPU al 85 % puede estar bien para el dispositivo A y ser un desastre para el B. El ML lo descubre automáticamente. Esto ya es una funcionalidad básica, no magia.

• Correlación de alertas: Cuando 50 cosas se rompen simultáneamente, el ML puede agruparlas y sugerir “el switch troncal es probablemente la causa raíz”. Ahorra horas de diagnóstico. Pero aún se necesitan humanos para verificarlo, porque el ML falla el 20 % de las veces.

• Previsión de capacidad: El ML es decente en “basándose en las tendencias, este enlace se saturará en 6 semanas”. Mejor que los humanos mirando gráficas. Aun así necesita criterio humano sobre si importa.

Lo que está sobrevendido:

• Análisis automático de causas raíz: Todos los proveedores lo prometen. Ninguno lo cumple de forma fiable. Se obtienen sugerencias, a veces buenas, pero “la IA diagnosticó y resolvió el problema” es un 95 % de marketing y un 5 % de ejemplos seleccionados.

• Redes autocurativas: La automatización puede resolver problemas conocidos con soluciones conocidas. Eso no es IA, es buena ingeniería. La verdadera “autocuración” para problemas nuevos aún no existe. Cuando los proveedores hacen una demo, hay que pedirles que muestren los casos de fallo.

• “AIOps reemplaza el NOC”: No. AIOps ayuda al NOC a ser más eficaz. ¿El criterio humano, el contexto de negocio y la capacidad de gestionar casos extremos? Eso sigue siendo tarea de los humanos.

Conclusión: usar ML para la detección de anomalías y la clasificación de alertas. Ser escéptico con todo lo demás hasta haberlo probado en la red real, no en una demo de proveedor.

6.2.6.2. La interfaz alerta-acción#

Una alerta que lee un humano es una notificación. Una alerta que consume la automatización es un contrato. Estos dos consumidores tienen requisitos diferentes, y confundirlos es una de las razones más comunes por las que los pipelines de alertas fallan en la frontera con el Orquestador.

Cuando una alerta está destinada a la automatización, su payload debe ser consumible por máquinas sin necesidad de análisis. Eso significa datos estructurados, no una línea de asunto legible por humanos. Como mínimo, un payload de alerta destinado a la automatización debe incluir:

• Identidad del dispositivo: un identificador canónico que coincida exactamente con el registro de la SoT (no un hostname que pueda diferir entre DNS y el CMDB)
• Clase de alerta: un tipo estable y enumerado sobre el que el Orquestador pueda enrutar (no una descripción de texto libre que cambia cuando alguien edita la regla de alerta)
• Severidad: una enumeración definida, no un valor de umbral numérico
• Timestamp: la hora del evento en UTC ISO 8601, no la hora de entrega de la notificación
• Contexto relevante: la métrica o estado específico que disparó la alerta, en un campo que el Orquestador pueda leer directamente (por ejemplo, "interface": "Ethernet0/1", no embebido en la cadena del mensaje)
• Traza de origen: un enlace o referencia al evento en bruto en el sistema de Observabilidad, para que el Orquestador pueda volver a consultarlo para obtener contexto adicional

Un payload que cumple este contrato permite al Orquestador enrutar la alerta al flujo de trabajo correcto, pasar la identidad del dispositivo a la consulta de la SoT e invocar el Ejecutor con parámetros estructurados, sin análisis de texto. Un payload que no cumple este contrato obliga al Orquestador a analizar texto legible por humanos, lo que se rompe cada vez que cambia la descripción de la alerta.

Hay que definir este contrato antes de construir las reglas de alertas, no después. Los autores de reglas de alertas que escriben para legibilidad humana producen mensajes difíciles de automatizar. Los que escriben para ambas audiencias producen mensajes que no sirven bien a ninguna. La solución más limpia son dos rutas de enrutamiento paralelas: un formato de alerta para humanos (Slack, PagerDuty), otro para la automatización (cola de mensajes, endpoint de webhook). Ambos disparados por la misma regla de detección; distintas plantillas de payload para distintos consumidores.

6.2.7. Visualización#

Objetivo: Todos los datos observados deben aportar valor a quienes toman decisiones, por lo que la visualización orientada al usuario debe responder a sus necesidades.

El bloque final es la capa de dashboards e informes. Sin rodeos: la mayoría de los dashboards son terribles. O son métricas de vanidad que hacen sentir bien a los directivos ("¡99,99 % de disponibilidad!") o son vómito de datos (50 gráficos por pantalla, nadie sabe qué significa ninguno).

Así se construyen dashboards que realmente ayudan:

• Construir para decisiones, no para decoración. Cada widget debe responder a una pregunta específica o desencadenar una acción específica. Si alguien mira un gráfico y no sabe qué hacer con él, hay que eliminarlo.

• Mostrar problemas, no solo datos. Las señales verde/amarillo/rojo superan a los números en bruto. “Utilización de interfaz: 45 %” no sirve de nada. “Utilización de interfaz: normal” o “Utilización de interfaz: AVISO, tendiendo hacia la saturación” sí es accionable.

• La navegación jerárquica supera a un gran dashboard único. Empezar con un resumen global de salud (“3 sedes tienen problemas”). Hacer clic en una sede para ver la salud de los dispositivos. Hacer clic en un dispositivo para ver las interfaces. Cinco dashboards enfocados superan a un desastre congestionado.

• Adaptar al público. El personal del NOC necesita estado operativo en tiempo real y navegación profunda. Los managers necesitan resúmenes de tendencias e impacto en el negocio. Los ingenieros necesitan acceso a datos en bruto e interfaces de consulta. Un dashboard que intenta servir a todos no sirve a nadie.

• Hacerlo interactivo o no molestarse. Los dashboards estáticos envejecen mal. Hay que permitir filtrar, hacer zoom y ajustar rangos de tiempo. Apoyar la investigación, no solo mostrar imágenes bonitas.

Y aquí va la opinión controvertida: la mayoría de los equipos tienen demasiados dashboards. Se han visto organizaciones con más de 200 dashboards donde cada persona mira 2 de ellos. Hay que eliminar los dashboards que nadie usa. Si nadie lo mira durante 3 meses, no importa.

La frontera Visualización/Presentación

La visualización se sitúa en una frontera arquitectónica que merece tratarse directamente en lugar de dejarse como una nota al pie. La capa de Presentación (Capítulo 8) es responsable de las interfaces orientadas al usuario: control de acceso, portales de autoservicio, integración con ITSM y el diseño de la experiencia de usuario sobre cómo las personas solicitan y consumen información. La visualización de los datos de observabilidad pertenece aquí en el Capítulo 6 porque las decisiones de diseño están impulsadas enteramente por los datos: qué métricas están disponibles, cómo está estructurada la alerta, qué rutas de navegación soporta la capa de persistencia. No se puede diseñar un dashboard de observabilidad eficaz sin entender el modelo de datos que hay detrás.

La distinción que importa en la práctica: los dashboards construidos directamente sobre datos de observabilidad para decisiones operativas (qué está ocurriendo ahora mismo, ¿está sano este servicio?) son una preocupación de Observabilidad. Cómo se presentan esos mismos dashboards a usuarios no técnicos, embebidos en un portal de autoservicio o integrados con flujos de trabajo de gestión de cambios, es una preocupación de Presentación. El Capítulo 8 revisita estas herramientas desde esa perspectiva de acceso y flujo de trabajo. La mayoría de las herramientas de visualización (Grafana siendo la más común) difuminan esta línea haciendo ambas cosas, lo que hace que la separación parezca artificial. No lo es. Las preocupaciones son genuinamente diferentes aunque la misma herramienta sirva a ambas.

Las reglas básicas:

• Claridad: Fácil de entender. Cada elemento tiene un propósito.
• Relevancia: Mostrar solo los datos que apoyan decisiones. El ruido mata el insight.
• Orientado al usuario: Construir para el público. El personal del NOC y los managers necesitan vistas diferentes.
• Interactivo: Permitir navegar, hacer zoom y ajustar el tiempo. Apoyar la investigación.
• Jerárquico: Visión general global primero, luego profundizar. Muchos dashboards enfocados superan a uno congestionado.

flowchart TD
    A[Visión Global] --> B[Resumen del Sitio] --> C[Resumen del Dispositivo] --> D[Detalle del Dispositivo] --> E[Detalle de la Interfaz]

Figura 6: Navegación Jerárquica.

En el libro Modern Network Observability, el capítulo 11 (“Application of Your Observability Data”) contiene muchos más detalles para diseñar dashboards.

Hay que tener en cuenta que este bloque está muy relacionado con la percepción del usuario, por lo que no hay que olvidar entrevistarlos e involucrarlos en el proceso.

6.2.8. Observabilidad del Sistema de Automatización#

La mayoría de los equipos construyen observabilidad para la red. Casi ninguno construye observabilidad para el propio sistema de automatización. Este es un punto ciego significativo: cuando el pipeline de automatización falla, el fallo a menudo es silencioso. No salta ninguna alerta, porque el sistema responsable de generarlas puede ser el que acaba de dejar de funcionar.

Un playbook que termina con estado 0 después de desplegar en cero dispositivos no genera ningún error. Una instancia de Telegraf que silenciosamente deja de sondear un protocolo específico de proveedor no produce ninguna alerta de datos faltantes, salvo que se instrumente específicamente para ello. Un job de sincronización de la SoT que falla a las 2 de la madrugada y deja el inventario desactualizado 12 horas hará que cada ejecución posterior trabaje con listas de dispositivos desactualizadas, y nada señalará que esto ha ocurrido.

Qué monitorizar en la plataforma de automatización

• Capa de ejecución (AWX, Ansible):

  • Tasa de éxito de jobs a lo largo del tiempo: una tasa de fallos que sube lentamente es una advertencia temprana de que algo se está degradando
  • Duración de la ejecución: un job que normalmente tarda 4 minutos y pasa a tardar 40 señala un problema con la plataforma, la red o ambos
  • Jobs atascados en estado pendiente o en ejecución más allá de su ventana esperada
  • Frecuencia de rollbacks: una tasa de rollbacks creciente generalmente indica un defecto en los datos de intención o en las plantillas
  • Dispositivos alcanzados por job frente a los esperados: un despliegue que toca 10 dispositivos en lugar de 800 puede haber fallado silenciosamente en la sincronización del inventario sin ningún error

• Capa de Fuente de Verdad:

  • Tiempo de respuesta de la API y tasa de errores: una API de SoT lenta bloqueará todos los jobs de ejecución que la consulten
  • Estado de los jobs de sincronización por fuente: tiempo del último sync exitoso, conteo de fallos consecutivos
  • Completitud de los datos: cuántos registros de dispositivos carecen de campos obligatorios de los que depende la ejecución

• Capa de recopilación:

  • Timestamp de la última recopilación exitosa por dispositivo: un dispositivo que no se ha sondeado en tres intervalos consecutivos es efectivamente un punto ciego de monitorización
  • Desfase de recopilación en toda la flota: si la antigüedad media de los datos está creciendo, el colector está quedándose atrás
  • Ciclos de sondeo perdidos por protocolo: los fallos SNMP y las caídas de suscripciones gNMI deben contarse y alertarse por separado

El problema del fallo silencioso

Los fallos de automatización más difíciles de detectar son los jobs que se completan con éxito pero no producen ningún cambio significativo. Un playbook que despliega en cero dispositivos por un filtro de inventario roto saldrá con estado 0. La única forma de capturar esta clase de fallo es instrumentar a nivel de resultado: “¿el número esperado de dispositivos cambió de estado?” en lugar de “¿el proceso del job terminó limpiamente?”.

Esto significa añadir métricas de resultado a los jobs de ejecución: un contador para los dispositivos configurados con éxito, un gauge para los dispositivos que requirieron rollback y una comprobación de que el job tocó al menos N dispositivos antes de marcarlo como exitoso.

Recomendación arquitectónica

Monitorizar la plataforma de automatización en una pila de observabilidad separada y mínima que no dependa del sistema de observabilidad principal al que da soporte. Si la instancia principal de Prometheus cae, las alertas para el pipeline de automatización no deben caer con ella. Una pila secundaria ligera (o un servicio de alertas SaaS) que cubra solo la salud de los componentes principales de automatización (AWX, Telegraf, API de SoT, jobs de sincronización) proporciona una red de seguridad que el sistema de observabilidad principal no puede proporcionarse a sí mismo.

Esto conecta directamente con el Capítulo 7 (Orquestación): un Orquestador sano debe reportar su propio estado operativo como una preocupación de primer nivel. Si el Orquestador no puede observarse, tampoco puede observarse la automatización que coordina.

6.3. Ejemplo de Implementación#

Esta sección ilustra cómo las funcionalidades de observabilidad se combinan mediante un caso de uso práctico usando la pila Telegraf, Prometheus y Grafana y otras herramientas.

Esto no es en absoluto una recomendación de herramientas, pero al estar construido completamente sobre componentes de código abierto, puede probarse libremente.

6.3.1. Caso de Uso: Validación Post-Despliegue y Monitorización Continua de un Servicio de Campus#

Se continúa con la red de campus del Capítulo 5. El nuevo servicio de VLAN ha sido desplegado en los switches objetivo del edificio-b por el bloque de Ejecución. Ahora la Observabilidad toma el relevo: primero para validar que el despliegue realmente tuvo éxito desde una perspectiva del estado de red, y luego para monitorizar la salud del servicio de forma continua en todo el campus.

Escenario: Tras desplegar un nuevo segmento de servicio VLAN en aproximadamente 800 switches de campus de Cisco, Arista y HPE, el equipo de operaciones necesita confirmar que el servicio está activo y es consistente en todos los dispositivos objetivo, detectar la deriva de configuración si un switch pierde la VLAN y monitorizar la salud del tráfico a lo largo del tiempo, sin comprobaciones manuales por dispositivo.

Requisitos:

• Validar que la membresía en la VLAN está activa y es consistente en todos los switches objetivo tras el despliegue
• Alertar sobre deriva de configuración: VLAN que falta en un switch, cambios inesperados en la membresía de trunk
• Monitorizar la salud del tráfico del servicio: niveles de utilización y tasas de error por puerto de acceso
• Detectar picos de tráfico repentinos (cambio mayor al 50 %) que puedan indicar flujos mal enrutados
• Mantener 30 días de datos a resolución de 30 segundos para cumplimiento y planificación de capacidad
• Integrar con Nautobot para datos de inventario de dispositivos y VLAN
• Disparar flujos de trabajo de orquestación para remediación automatizada cuando se detecte deriva

6.3.2. Arquitectura de la Solución#

Antes de comenzar el análisis de la solución, es importante obtener una estimación de la escala del escenario. Con aproximadamente 800 switches de campus x 48 puertos x 8 métricas = aproximadamente 307K series temporales activas. Esto está bien dentro de lo que un único nodo de Prometheus puede manejar (cómodo hasta aproximadamente 1M de series), pero la capa de colectores necesita múltiples instancias de Telegraf para distribuir la carga de sondeo entre 800 dispositivos a intervalos de 30 segundos.

Justificación de la selección de componentes:

• Telegraf fue elegido como colector por su soporte multi-protocolo (SNMP para dispositivos HPE legacy y Cisco antiguos, gNMI para Arista y plataformas Cisco más nuevas), su extenso ecosistema de plugins y sus procesadores integrados para la normalización de datos. A escala de 800 dispositivos, una única instancia de Telegraf estaría al límite con intervalos de sondeo de 30 segundos, por lo que se despliegan dos o tres instancias con Consul coordinando qué objetivos gestiona cada una.
• Prometheus sirve como capa de persistencia, optimizado para datos de series temporales con su potente lenguaje de consulta PromQL para condiciones de alerta complejas. A 32K series, opera bien dentro de su zona de confort, con integración nativa con Alertmanager.
• Grafana proporciona visualización con soporte multi-datasource, consultando simultáneamente métricas de Prometheus y metadatos de Nautobot para crear dashboards ricos en contexto adaptados a distintas audiencias (NOC, planificación de capacidad, gestión).

Arquitectura

A alto nivel, la siguiente figura muestra los componentes principales y sus roles:

flowchart TB
    subgraph Sources["Fuentes de Datos"]
        NB[Nautobot<br/>Fuente de Verdad]
        SW[Dispositivos de Red<br/>SNMP/gNMI]
    end

    subgraph Collection["Capa de Recopilación"]
        T[Telegraf<br/>Colectores]
        SD[Consul<br/>Descubrimiento de Servicios]
    end

    subgraph Storage["Almacenamiento"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["Alertas"]
        AM[Alertmanager<br/>Enrutamiento]
    end

    subgraph Presentation["Visualización"]
        G[Grafana<br/>Dashboards]
    end

    subgraph Integration["Sistemas Externos"]
        ORCH[Orquestador<br/>Automatización]
        SLACK[Slack<br/>Notificaciones]
    end

    NB -->|Inventario de Dispositivos| SD
    SD -->|Objetivos Dinámicos| T
    SW -->|Métricas| T
    T -->|Exponer HTTP| P
    P -->|Reglas de Alerta| AM
    P <-->|Consultas| G
    NB -->|Metadatos| G
    AM -->|Webhook| ORCH
    AM -->|Alertas| SLACK

Figura 7: Ejemplo de Solución de Observabilidad.

Esta arquitectura de solución simplista está cubierta en extenso en el libro Modern Network Observability. Si se desea un enfoque práctico con un escenario de laboratorio para probar, se recomienda su lectura.

6.3.3. Flujo de Implementación#

Integración del Inventario: Nautobot sirve como única fuente de verdad, definiendo qué dispositivos monitorizar con perfiles de monitorización y credenciales SNMP. Un servicio de sincronización ligero (por ejemplo, un script Python usando webhooks) actualiza continuamente el registro de servicios de Consul con información de dispositivos, habilitando el descubrimiento dinámico desde el colector.

Recopilación de Datos: Telegraf usa Consul para el descubrimiento de servicios, sondeando automáticamente SNMP de los dispositivos según van apareciendo en Nautobot. Los procesadores de Telegraf normalizan y enriquecen los datos (convirtiendo códigos de estado en etiquetas, renombrando campos a nombres estándar y añadiendo información contextual de Nautobot) y exponen las métricas en formato Prometheus en un endpoint HTTP.

Persistencia y Análisis: Prometheus extrae los endpoints de Telegraf usando el descubrimiento de servicios de Consul, almacenando métricas en su base de datos de series temporales. Las recording rules precalculan porcentajes de utilización de interfaces y tasas de ancho de banda para optimizar el rendimiento de las consultas.

Lógica de Alertas: Las reglas de alerta en Prometheus definen las condiciones (por ejemplo, utilización de interfaz mayor al 80 % durante 5 minutos, picos de tráfico mayores al 50 %). Cuando las condiciones se cumplen, Alertmanager gestiona el enrutamiento: las alertas críticas con etiquetas automation: enabled van al webhook del orquestador, mientras las demás se enrutan a Slack o PagerDuty según la severidad.

Visualización: Los dashboards de Grafana ofrecen múltiples vistas: tendencias de ancho de banda de todo el fabric, interfaces con mayor saturación, navegación por dispositivo con mapas de calor de interfaces. Las variables de plantilla permiten filtrar por sede, rol o dispositivo. Los dashboards consultan tanto Prometheus (métricas) como Nautobot (metadatos de dispositivos) para el enriquecimiento contextual.

Automatización de Bucle Cerrado: Cuando saltan alertas críticas de saturación, Alertmanager envía webhooks a la plataforma de orquestación, que dispara flujos de trabajo automatizados de ingeniería de tráfico para redistribuir la carga entre los caminos disponibles. Este componente se cubre en el Capítulo 7.

6.3.4. Resumen de la Solución#

Beneficios Operativos:

• Reducción del esfuerzo manual de monitorización mediante la integración con la SoT
• Detección proactiva de problemas con latencia inferior al minuto
• Remediación en bucle cerrado que reduce el MTTR de horas a minutos
• Contexto rico que combina métricas con datos de inventario

Consideraciones de Escalabilidad:

• La arquitectura actual gestiona aproximadamente 800 switches de campus usando 2-3 instancias distribuidas de Telegraf detrás de Consul; añadir más edificios o dispositivos significa añadir más instancias de colectores, no rediseñar la arquitectura
• La capacidad de Prometheus es suficiente con aproximadamente 307K series con margen para crecer; un único nodo gestiona hasta aproximadamente 1M de series antes de requerir federación o un backend distribuido

Este breve ejercicio de solución cierra este capítulo que define los objetivos y funcionalidades básicas de la Observabilidad dentro de una arquitectura de automatización de redes.

6.4. Resumen#

La observabilidad en la automatización de redes va mucho más allá de la monitorización tradicional, proporcionando la base arquitectónica para entender el comportamiento de la red, detectar problemas de forma proactiva y habilitar la remediación automatizada a escala. Construida sobre siete objetivos fundamentales, desde el descubrimiento automático con mínimo esfuerzo humano hasta el análisis sofisticado en tiempo real y las visualizaciones orientadas al usuario, la observabilidad transforma cómo las organizaciones responden a los eventos de red, pasando de la resolución reactiva de problemas a operaciones proactivas y basadas en datos.

La realización de estos objetivos requiere siete pilares y funcionalidades arquitectónicas interconectados: integración con la SoT para el descubrimiento automático del inventario, colectores multi-protocolo que soportan la ingesta de datos en tiempo casi real mediante telemetría en streaming y protocolos modernos, procesadores que normalizan datos heterogéneos y los enriquecen con metadatos contextuales, sistemas distribuidos para el movimiento de datos a escala y alto volumen, bases de datos especializadas (series temporales, columnares y de búsqueda de texto) optimizadas para distintas cargas de trabajo de observabilidad, alertas inteligentes con detección y enrutamiento mejorados por IA/ML hacia la orquestación o los respondedores humanos, y visualizaciones adaptadas que presentan la información en los niveles de abstracción apropiados para distintas audiencias.

Implementar la observabilidad requiere decisiones arquitectónicas tempranas en el proceso de diseño. Las organizaciones deben elegir entre plataformas tradicionales on-premises, soluciones SaaS cloud-native que ofrecen despliegue rápido y análisis potenciados por IA, o pilas de código abierto componibles que proporcionan máxima flexibilidad. Cada enfoque implica compromisos en coste, control, carga operativa y capacidad. El éxito también depende de entender los requisitos de procesamiento de datos, desde la normalización y el enriquecimiento hasta el filtrado y la agregación, y cómo las capacidades emergentes de AIOps pueden reducir la fatiga por alertas y habilitar operaciones predictivas.

La observabilidad no es una única herramienta sino un patrón arquitectónico coherente. El éxito depende de tratarla como un sistema, donde el inventario impulsa la recopilación, la recopilación habilita el procesamiento, el procesamiento alimenta la distribución, la distribución conecta con la persistencia, la persistencia informa las alertas, y las alertas en última instancia impulsan la visualización y la respuesta automatizada. Al diseñar cuidadosamente cada componente y cómo interactúan, las organizaciones pueden construir sistemas de observabilidad que escalen con sus redes, se integren con protocolos modernos como OpenTelemetry y gNMI, y transformen la visibilidad operativa en inteligencia accionable que impulsa la automatización de bucle cerrado.

Referencias y Lecturas Adicionales#

• Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): Un enfoque práctico usando herramientas de código abierto como Telegraf, Prometheus y Grafana

💬 Found something to improve? Send feedback for this chapter