6. Observabilitat#

El router core d’un proveïdor de serveis va tenir una fallada silenciosa d’un mòdul de ventilació durant la nit. No hi va haver cap alerta. El subsistema de gestió tèrmica de les targes de línia va detectar temperatures en augment i va començar a limitar els ASICs d’encaminament per protegir el maquinari. El throughput d’un enllaç de trànsit en producció va caure un 40%. El sistema de monitoratge no va veure res: els sensors tèrmics que consultava eren al supervisor del xassís, no a les targes de línia individuals. Les consultes SNMP s’executaven cada cinc minuts i indicaven que el dispositiu estava en bon estat. Els comptadors d’interfícies mostraven un throughput reduït, però no hi havia cap llindar configurat per a aquest patró perquè l’enllaç sempre havia estat molt per sota de la capacitat.

Tres hores més tard, un incompliment del SLA d’un client va generar un tiquet. L’enginyer de guàrdia va accedir per SSH al router, va notar la fallada del ventilador al registre d’alarmes local i va reiniciar el mòdul. El controlador de ventilació es va reiniciar i la limitació tèrmica es va aixecar en pocs minuts. El trànsit es va recuperar. L’incompliment del SLA es va documentar, es va notificar al client i l’incident es va tancar.

La causa arrel mai es va confirmar. Quan algú va investigar, el router feia hores que funcionava amb normalitat. No hi havia dades tèrmiques de les targes de línia, cap registre de l’event de limitació, i cap manera de correlacionar la reducció de throughput amb la fallada del ventilador en cap sistema de monitoratge. L’informe d’incident va concloure: “presumpta incidència de maquinari, resolta amb reinici de maquinari.” Va tornar a passar sis mesos després en un router diferent.

La fallada no era un llindar absent. L’equip tenia milers de llindars. La fallada era una cobertura incompleta: el sistema de monitoratge recollia de les fonts que sempre s’havien consultat, no de totes les fonts que podien modificar el comportament del dispositiu. Les dades tèrmiques de les targes de línia estaven disponibles via gNMI en tots tres tipus de xassís de la flota. Ningú havia configurat el path de recollida perquè ningú havia escrit un runbook per a fallades de ventilació.

El monitoratge de xarxa tradicional vigileu les coses trencades: la interfície és activa? La CPU supera el 90%? Aquest servei respon? Això és útil, però és reactiu: esteu vigilant per detectar fallades.

L’observabilitat és diferent. Tracta d’entendre per qué les coses fallen o estan a punt de fallar. No és només “aquell dispositiu està caigut” sinó “per qué ha caigut, qué es trenca perquè ha caigut, quin és l’impacte en el negoci”. Amb l’automatització de xarxes, l’observabilitat es converteix en el bucle de retroalimentació: observeu alguna cosa, el vostre sistema ho detecta, decideix com respondre, pren acció i verifica que la solució ha funcionat. Això és l’automatització de bucle tancat.

Aquest capítol cobreix tot el que necessiteu per veure qué passa a la vostra xarxa: quines dades recollir, com recollir-les, com emmagatzemar-les, com alertar-ne, i com mostrar-les a les persones d’una manera que realment els ajudi a prendre decisions.

Tant si feu servir una plataforma monolítica tradicional (SolarWinds, LibreNMS), un servei cloud (Datadog, New Relic) o construïu la vostra pròpia pila a partir de components open-source (Prometheus, Grafana, etc.), l’arquitectura subjacent és la mateixa. Entendre aquests patrons us ajuda a triar l’enfocament adequat per a la vostra escala i equip.

6.1. Fonaments#

Abans d’entrar en els detalls de baix nivell, establim els conceptes fonamentals sobre l’observabilitat de xarxa dins de l’estratègia d’automatització, definint els seus objectius, els pilars de suport i l’abast.

6.1.1. Context#

Probablement ja monitoreu la vostra xarxa. Feu servir Simple Network Management Protocol (SNMP), consulteu el System Logging Protocol (Syslog), teniu panells que mostren la utilització dels enllaços. Això és monitoratge: us diu si les coses funcionen.

Però l’automatització necessita més. Quan la xarxa canvia (perquè l’automatització l’ha canviada), heu de saber immediatament si alguna cosa es trenca. Quan rebeu una alerta, necessiteu context: quins clients es veuen afectats? Quins serveis han fallat? Quin és el radi d’impacte? El monitoratge tradicional us dona alarmes. L’automatització necessita intel·ligència.

Aquí teniu la diferència clau:

• Monitoratge: La interfície és activa? La CPU és alta? Preguntes simples de sí/no.
• Observabilitat: Per qué ha caigut la interfície? Qué impacta? Com ho podem solucionar automàticament? Qué va passar històricament que ha portat a això?

L’observabilitat alimenta l’automatització. El vostre sistema observa la xarxa, detecta problemes, decideix qué fer, pren acció i verifica que la solució ha funcionat. Aquell cicle repetint-se s’anomena “automatització de bucle tancat.”

Les eines de monitoratge tradicionals (les grans monolítiques com SolarWinds) intenten fer-ho tot en un sol producte. Pot funcionar, però sovint pagueu per funcionalitats que no necessiteu i esteu limitats en les que sí necessiteu. L’alternativa és construir l’observabilitat a partir de peces: trieu el collector que funciona per als vostres dispositius, l’emmagatzematge que escala amb les vostres dades, les alertes que s’adapten als vostres fluxos de treball d’automatització. Això és més difícil d’assemblar però molt més flexible.

Aquest capítol recorre ambdós enfocaments i els patrons que funcionen independentment del que trieu.

Una primera elecció és sobre com s’executa la plataforma:

• Monolítica (SolarWinds, LibreNMS): Un producte ho fa tot. L’instal·leu, el configureu i endavant. Bé si la vostra xarxa és directa i no teniu experiència DevOps. Mal si voleu flexibilitat o la vostra xarxa és inusual: esteu lligats al seu model.

• Cloud SaaS (Datadog, New Relic, Kentik): Ells ho executen tot. Ràpid de desplegar, sense problemes d’infraestructura, panells visuals des del primer dia. Però pagueu mensualment en funció del volum, les vostres dades viuen als seus servidors (important en alguns règims de compliment) i quan toqueu els seus límits, esteu atrapats. He vist equips gastar 50.000 USD/mes en observabilitat SaaS preguntant-se per qué el CFO no n’estava content.

• Construïda per vosaltres (Prometheus + Grafana, o pila Telegraf-Prometheus-Grafana (TPG)): Flexibilitat total, sense dependència de proveïdor, millor economia a escala. Però ara gestioneu bases de dades, cues de missatges i infraestructura de collectors. Si no teniu persones que puguin operar tot això, passareu més temps reparant l’observabilitat que reparant la xarxa.

La pregunta real: Teniu l’equip per executar-ho? Si sí, construïu-ho. Si no, compreu-ho. No us enganyeu sobre en quina categoria esteu.

Després d’aquesta elecció, sorgeixen dues preguntes més:

• On s’executa? A les vostres instal·lacions (controleu-ho tot, però vosaltres ho gestioneu), al núvol (ells ho gestionen, però les vostres dades surten de la xarxa), o híbrid (algunes coses en local, altres al núvol)?
• Quin és el model de costos? Per dispositiu? Per mètrica ingestada? Subscripció plana? Aquestes decisions s’acumulen ràpidament quan recollin milions de punts de dades per minut.

6.1.2. Objectius#

El vostre sistema d’observabilitat ha de fer set coses:

1. Observar-ho tot automàticament. Es connecta un dispositiu nou? Ha de començar a informar dades sense que ningú l’enregistri manualment. Un servei nou s’activa? Ja s’està vigilant. Això requereix integració amb la vostra font de veritat perquè l’observabilitat sàpiga qué existeix.

2. Gestionar entorns heterogenis amb dades de qualitat. La vostra xarxa probablement té Cisco, Arista, Juniper, proveïdors cloud, servidors Linux, contenidors. Cadascun té maneres diferents d’exposar dades. I oblideu els intervals de 5 minuts: necessiteu dades en temps quasi real quan l’automatització fa canvis.

3. Correlacionar dades entre capes. Un servidor va lent. La xarxa és congestionada, o és un problema de base de dades? Necessiteu dades de dispositius de xarxa, servidors i aplicacions, tots parlant el mateix idioma per poder traçar línies entre ells.

4. Escalar sense col·lapsar. Les xarxes creixen. Quan recollin un milió de mètriques per segon, les arquitectures tradicionals s’enfonsen. Necessiteu sistemes dissenyats per escalar des del primer dia.

5. Permetre que les persones analitzin les dades intel·ligentment. Doneu als analistes accés per consultar les vostres dades, no només panells preconstruïts, sinó consultes potents perquè puguin respondre les seves pròpies preguntes. I necessiten dades en temps real i historial (tendències, detecció d’anomalies).

6. Detectar problemes i solucionar-los automàticament. La majoria del temps, la vostra automatització hauria de respondre als problemes sense esperar un humà. Només quan l’automatització no pugui resoldre-ho hauria d’avisar algú. I aquesta alerta ha d’explicar qué va malament, no mostrar simplement números en brut.

7. Mostrar a les persones el que necessiten veure. Un panell és inútil si mostra massa coses o les equivocades. Doneu a l’equip d’operacions de xarxa la seva vista, a l’empresa la seva, als enginyers la seva. Cada persona obté el que l’ajuda a fer la seva feina.

6.1.3. Pilars#

Cada objectiu necessita blocs constructius específics. Aquí teniu el que necessiteu:

1. Saber qué observar. La vostra font de veritat té tots els dispositius, serveis i credencials. L’observabilitat ha d’obtenir aquestes dades automàticament perquè els collectors sàpiguen qué monitorar. Quan afegiu un dispositiu al SoT, el monitoratge s’activa automàticament.

2. Recollir dades de manera eficient. Necessiteu múltiples mètodes de recollida: Simple Network Management Protocol (SNMP) per a equips antics, streaming gRPC Network Management Interface (gNMI) per a dispositius moderns, System Logging Protocol (Syslog) per a events, flows (NetFlow, IP Flow Information Export (IPFIX)) per al trànsit, potser captures de paquets per a diagnòstics profunds. Eines diferents, velocitats diferents, riquesa de dades diferent. La bona notícia: no heu de triar-ne només una.

3. Normalitzar-ho tot. Les vostres mètriques d’Arista es veuen diferent de les de Cisco, que es veuen diferent de les del proveïdor cloud. El vostre logging és text no estructurat, els flows són binaris. Necessiteu una capa que tradueixi tot això a un llenguatge comú i afegeixi context (quin dispositiu, quin client, quin servei).

4. Moure dades de manera fiable a escala. Les pipelines de monitoratge tradicionals són seqüencials: collector -> processador -> emmagatzematge. A escala, això és un coll d’ampolla. Necessiteu buses de missatges i plataformes de streaming que desacoblin cada etapa perquè puguin escalar independentment.

5. Emmagatzemar-ho intel·ligentment. Les dades de sèries temporals (mètriques) necessiten bases de dades optimitzades per a això. Els registres necessiten alguna cosa diferent. Necessiteu consultar entre milions de punts de dades en mil·lisegons. No totes les bases de dades són iguals.

6. Convertir dades en accions. Les mètriques en brut no activen l’automatització. Necessiteu regles: “si CPU > 90%, comproveu si és manteniment previst, si no, feu aquests passos.” I aquestes regles s’alimenten al vostre orquestrador d’automatització o sistema d’alertes.

7. Mostrar-ho visualment. Les dades són inútils si ningú les mira. Necessiteu panells, però intel·ligents: vistes diferents per a persones diferents, capaços de fer drill-down, capaços de mostrar tendències i comparacions.

Finalment, abans de detallar les set funcionalitats que realitzen aquests pilars, aclarim qué cau dins de l’abast de l’Observabilitat.

6.1.4. Abast#

Per ampliar els objectius introduïts anteriorment, hi ha altres punts que també pertanyen a les responsabilitats de l’Observabilitat:

• Diferents nivells d’observació adaptats a les perspectives dels usuaris (tècnica, operacional, de negoci)
• Integració amb pipelines de CI/CD, proporcionant retroalimentació per a proves i validació automatitzades
• Observabilitat del propi sistema d’automatització (meta-monitoratge de Collectors, processadors i sistemes d’alerta)

No obstant això, hi ha funcions que pertanyen a altres components de l’arquitectura:

• Definir la intenció de xarxa: com hauria de semblar la xarxa (responsabilitat de la Intenció/SoT)
• Executar canvis de xarxa: implementar realment la remediació (responsabilitat de l’Executor)
• Orquestrar fluxos de treball complexos: coordinar la remediació en múltiples passos entre múltiples sistemes (responsabilitat de l’Orchestrator)

Aquest límit clar assegura que l’Observability se centri en la detecció i els insights, mentre que altres blocs constructius gestionen la definició d’intenció, l’execució i l’orquestració.

Després d’aquesta introducció inicial que exposa els conceptes clau relacionats amb el bloc d’Observabilitat, anem a detallar cada funcionalitat.

6.2. Funcionalitats#

Els set objectius i pilars es realitzen a través de set funcionalitats bàsiques. Cada funcionalitat s’associa a un objectiu i al seu pilar de suport, creant una cadena directa des dels requisits de negoci fins a la implementació tècnica:

1. Inventari: Consumeix la intenció del SoT i proporciona metadades, llistes de dispositius i objectius de recollida a tots els components aigües avall.
2. Collector: Recupera dades observades de la xarxa usant múltiples protocols i mètodes de recollida, tant basats en pull (polling) com en push (streaming).
3. Processador: Normalitza dades heterogènies en un esquema comú i les enriqueix amb metadades contextuals (etiquetes, relacions, context de negoci), a més de fer altres operacions sobre les dades.
4. Distribució: Desacobla els productors de dades dels consumidors usant patrons distribuïts i asíncrons. Mou dades i events de manera fiable des dels Collectors a través dels processadors fins als sistemes de persistència i alertes.
5. Persistència: Emmagatzema dades normalitzades en bases de dades optimitzades per a una ingesta, retenció i consulta eficients a escala.
6. Alertes: Analitza dades persistides usant regles i llindars flexibles per detectar condicions d’interès, generant events que activen sistemes externs (automatització o notificacions humanes).
7. Visualització: Renderitza dades observades i events generats en panells, informes i altres interfícies visuals adaptades a diferents audiències i casos d’ús.

graph LR

    %% --- Subgraphs ---
    subgraph Goals["Objectius"]
        direction TB
        A1[Observar tota la xarxa amb el mínim esforç humà]
        A2[Suportar entorns de xarxa heterogenis amb dades suficients i precisió]
        A3[Observar dades de diferents capes de TI amb context]
        A4[Gestionar escenaris de xarxa a escala massiva]
        A5[Oferir accés a dades d'observabilitat per a anàlisi sofisticada en temps quasi real]
        A6[Ser proactiu per detectar problemes de xarxa i reduir el temps de recuperació]
        A7[Crear visualitzacions orientades a l'usuari i adaptades]
    end

    subgraph Pillars["Pilars"]
        direction TB
        B1[Integració estreta amb el SoT per entendre qué cal monitorar]
        B2[Capacitat de recollir dades via protocols diferents amb actualitzacions freqüents/sota demanda]
        B3[Normalització de dades heterogènies amb metadades contextuals per a una anàlisi més rica]
        B4[Sistemes de distribució de dades escalables per a arquitectures scale-out]
        B5[Capa de persistència que suporta dades de sèries temporals i llenguatges de consulta potents]
        B6[Definicions de regles flexibles i escenaris d'enrutament amb integració de sistemes externs]
        B7[Visualitzacions personalitzades i integració de múltiples emmagatzematges de dades]
    end

    subgraph Functionalities["Funcionalitats"]
        direction TB
        C1[Inventari]
        C2[Collector]
        C3[Processador]
        C4[Distribució]
        C5[Persistència]
        C6[Alertes]
        C7[Visualització]
    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;

Aquests components es poden veure com una pipeline de dades o ETL (Extract, Transform and Load), amb el diagrama següent:

flowchart TB
    A[Xarxa] --> B[Collector]

    subgraph Observability["Observabilitat"]
       direction LR
       B --> C[Distribució] -->  D[Persistència]
       B -.-> P[Processament]
       C -.-> P
       D -.-> P
       D --> E[Alertes]
       E -.-> P
       D --> G[Visualització]
       X[Inventari] -.-> B
       X -.-> G
       X -.-> P
    end

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

Figura 1: Pipeline d'Observabilitat.

6.2.1. Inventari#

El component d’inventari respon una pregunta senzilla: qué hauria de monitorar?

Ja teniu aquestes dades en algun lloc: estan a la vostra font de veritat. Teniu noms de dispositius, adreces IP, qué són, si estan actius, credencials. No les dupliqueu manualment. Importeu-les automàticament.

El que necessiteu del vostre SoT:

• Un nom o ID únic per a cada dispositiu o servei (perquè sabeu que és el dispositiu que creieu que és)
• Com arribar-hi: adreça IP, nom d’host i credencials (si heu d’obtenir dades activament)
• Qué és: el tipus i el proveïdor (perquè sàpiguen quins Collectors hi funcionen)
• Si és actiu: si està planificat, actiu o en procés de descomissió (per no alertar sobre interrupcions esperades)

Més enllà del bàsic, també us pot interessar:

• Especificitats del SO o del dispositiu: alguns dispositius usen protocols diferents, alguns són antics i necessiten tractament especial
• Context: qui en és el propietari, on es troba, de quins clients depèn (útil per filtrar alertes i panells)

Per qué automatitzar-ho en lloc de construir una llista manualment? Perquè les persones obliden actualitzar les llistes. S’afegeixen dispositius, ningú ho diu al monitoratge, i de sobte perdeu visibilitat. Però si l’observabilitat llegeix del vostre SoT, quan afegiu un dispositiu, automàticament es monitoritza.

Push vs. pull?

• Pull: L’observabilitat comprova el SoT periòdicament per detectar actualitzacions. Simple, però si alguna cosa canvia a mig interval, us ho perdeu.
• Push: Quan el SoT canvia, avisa l’observabilitat automàticament (webhooks, bus de missatges). Més ràpid i fiable.

Si teniu dades de qualitat al vostre SoT i integració real (no còpia-enganxa manual), l’inventari es torna automàtic i mai no us perdeu l’observació d’un dispositiu nou.

6.2.2. Collectors#

Les vostres dades han de venir d’algun lloc. Els Collectors són els ponts entre la vostra xarxa i la vostra plataforma d’Observability. Són responsables d’obtenir (o rebre) dades dels vostres dispositius i alimentar-les a la pipeline. Sense Collectors efectius, tot el que hi ha aigües avall és inútil.

Hi ha dos enfocaments fonamentals des de la perspectiva de qui controla el flux de dades:

• Passiu o Push: Els vostres dispositius envien dades al collector. Penseu en servidors syslog que reben missatges de registre dels routers, o collectors IPFIX que escolten registres de flux. El dispositiu decideix qué enviar i quan.
• Actiu o Poll: El Collector demana dades als dispositius. Es connecta a cada dispositiu i extreu informació usant Simple Network Management Protocol (SNMP), gRPC Network Management Interface (gNMI), Representational State Transfer (REST) Application Programming Interface (API)s, o se subscriu a dades de streaming. El Collector té el control: decideix qué demanar i quan.

També podeu categoritzar els collectors per desplegament:

• Sense agent: Cap programari a instal·lar als dispositius. Un servidor collector central (normalment executant-se en un altre lloc) es connecta a cada dispositiu individualment. Simple per començar, però pot convertir-se en un coll d’ampolla a mesura que escaleu.
• Basat en agent: Instal·leu un petit agent a cada dispositiu o servei. Els agents envien dades a una ubicació central, o extreuen directament de fonts locals. Més distribuït, més fàcil d’escalar, però amb més peces mòbils per gestionar.

Independentment del mètode de recollida, és important destacar els diferents tipus de dades que poden ser d’interès en l’entorn d’automatització de xarxes. Els classifico en quatre grans categories:

• Pla de gestió: L’estat del dispositiu, o per llegir dades sobre la configuració, el logging o les estadístiques de xarxa. Els protocols d’aquest grup són Simple Network Management Protocol (SNMP), System Logging Protocol (Syslog), gRPC Network Management Interface (gNMI), NETCONF i RESTCONF.
• Pla de control: Aquí és on s’executen els protocols distribuïts que determinen l’encaminament de paquets de la xarxa, com les taules d’encaminament de capa 2 o capa 3. Alguns exemples de protocols de pla de control són OSPF, IS-IS i BGP. Aquests plans es poden observar mitjançant tècniques com Ping o Traceroute, o protocols de telemetria com BMP.
• Pla de reenvio: Aquest és el pla on es mouen els paquets (per exemple, interfícies de xarxa), i és el més exigent en termes de volum i velocitat de dades. Naturalment, quan s’observa, també és crucial no impactar l’objectiu principal del pla, que és reenviar paquets. En aquest grup tenim eines com TcpDump, IPFIX, sFlow, Netflow, Cisco SLA, PSAMP i eBPF.
• Dades externes: Aquesta categoria inclou tot el que no és específic dels dispositius de xarxa. Per exemple, la informació del proveïdor de circuits i el contacte per a una interfície determinada, procedent d’un sistema extern de gestió d’actius o sensors físics IoT (Internet of Things), podrien encaixar en aquest ampli camp.

flowchart TB
    subgraph Network Device/Service["Dispositiu/Servei de Xarxa"]
        direction TB
        A[Pla de Gestió]
        B[Pla de Control]
        C[Pla de Reenvio]
        A --> B
        B --> C
    end

    D[Dades Externes]

Figura 2: Abast del Collector.

En realitat, es redueix a dues preguntes bàsiques sobre el que recollin:

• Qué recollir: Mètriques? Registres? Registres de flux? Cadascun té models de dades diferents. SNMP té MIBs, els equips moderns parlen gNMI, les aplicacions usen OpenTelemetry. El somni és un estàndard universal que permeti correlacionar dades entre tot, però encara no existeix. Potser haureu de construir la vostra pròpia capa de traducció que converteixi tots aquests formats diferents en alguna cosa consistent (que és el que fa la capa de processament a continuació).
• Com obtenir-ho: Quin protocol? SNMP és antic però estable, gNMI és modern i us envia dades de manera contínua, IPFIX captura el que realment flueix. Varia en funció del que intenteu observar.

Aquesta taula resumeix el que podríeu recollir i les eines disponibles:

Taula 1: Dades i Protocols a recollir.

La recollida de dades de xarxa s’aplica a centres de dades, backbones d’ISP, serveis de xarxa cloud, interfícies del kernel Linux o paquets en brut. Depèn del vostre entorn.

La clau: abans de decidir qué recollir, comenceu amb el problema que intenteu resoldre. Aquesta decisió ho condueix tot. Detecteu saturació d’interfícies? Monitoreu la convergència BGP? Seguiu trànsit DDoS? El vostre problema determina quines dades necessiteu i amb quina freqüència.

Per augmentar la freqüència de dades recollides (interessant en alguns casos) o per convergir mètodes de recollida, aquests són alguns patrons que han augmentat la seva adopció recentment:

Telemetria en streaming

Els dispositius envien dades de manera contínua usant models YANG. Configureu subscripcions i les dades flueixen en temps real. Dues variants:

• Dial-In: El collector demana al dispositiu que comenci a enviar (el collector inicia).
• Dial-Out: El dispositiu està preconfigurada per enviar-vos les dades (el dispositiu inicia).

Latència molt menor que el polling, i el dispositiu manté el control del flux.

flowchart TB
    A[Collector]
    B[Dispositiu]
    A -.->|Dial-In| B
    B -->|Streaming| A
    B -.->|Dial-Out| A

Figura 3: Telemetria en Streaming.

Mètriques exposades per Hypertext Transfer Protocol (HTTP)

El scraping Hypertext Transfer Protocol (HTTP) (mètriques basades en pull) és simple i escala bé. Simple Network Management Protocol (SNMP) fa això, però cada vegada més els sistemes operatius de xarxa exposen mètriques directament via Hypertext Transfer Protocol (HTTP) en format Prometheus. Més fàcil de consumir pels Collectors, sense necessitat d’analitzar Management Information Base (MIB) de Simple Network Management Protocol (SNMP). SONiC, Cumulus, Arista EOS i altres exposen mètriques d’aquesta manera.

Taula 2: Mètriques exposades per HTTP.

L’enfocament de scraping proporciona baixa latència i mètriques en temps quasi real, etiquetes riques i recollida basada en pull (control central de la taxa/timeout), connectant-se bé amb l’observabilitat a escala cloud.

OpenTelemetry

OpenTelemetry és un estàndard i conjunt d’eines neutral al proveïdor per recollir, processar i exportar dades de telemetria. Penseu-hi com un llenguatge de telemetria comú i una pipeline que unifica mètriques, registres i traces entre xarxes, sistemes i aplicacions.

No substitueix els protocols de xarxa com SNMP, NetFlow, gNMI o BMP. En canvi, estandarditza com es representa i transporta la telemetria després de la recollida.

En el monitoratge de xarxa tradicional, els models de dades són diversos i usen esquemes i noms específics del proveïdor, cosa que dificulta la correlació entre capes (xarxa, sistema, aplicació). En oposició, OpenTelemetry ajuda proporcionant:

• Un model de dades comú per a mètriques, registres i traces
• Un protocol de transport estàndard (OpenTelemetry Protocol (OTLP)), sobre gRPC Remote Procedure Call (gRPC) o Hypertext Transfer Protocol (HTTP)
• Una única pipeline de processament per a múltiples tipus de senyals

Grafana Alloy o Telegraf són exemples de Collector que implementen OpenTelemetry Protocol (OTLP). Recullen dades de diferents exportadors i les exporta a backends com ara mètriques (Time Series Database (TSDB)s compatibles amb Prometheus), registres (Loki, Elasticsearch, ClickHouse) i traces (Tempo, Jaeger).

I això ens porta a una consideració final sobre l’estructura comuna dels collectors moderns amb connectors, amb etapes d’Input, Processador i Output. Per exemple, a Telegraf, OTLP és una opció per a un connector de sortida.

OpenTelemetry com a elecció arquitectònica

Adoptar OpenTelemetry no és només una decisió d’eines: és una decisió arquitectònica sobre com unifiqueu la vostra pipeline d’observabilitat. L’elecció és entre dos enfocaments:

Natiu del protocol: cada tipus de senyal viatja a través del seu protocol nadiu d’extrem a extrem (gNMI a Prometheus, syslog a Elasticsearch, NetFlow a ClickHouse). Cada pipeline està optimitzada per al seu senyal. El cost és múltiples pipelines independents sense model de dades compartit, cosa que fa que la correlació entre tipus de senyals sigui costosa.

Natiu d’OTel: els senyals es converteixen a OpenTelemetry Protocol (OTLP) el més aviat possible i flueixen per una única pipeline cap a un backend unificat. La correlació entre mètriques, registres i traces és natural perquè comparteixen un model de dades. El cost és que el suport d’OTel als dispositius de xarxa encara està madurant: la majoria de proveïdors no emeten OTLP de manera nativa, cosa que requereix una capa d’adaptació (gNMI a OTel, SNMP a OTel) que afegeix complexitat operativa.

La recomanació pràctica per als entorns d’automatització de xarxes avui: adopteu OTel per a senyals adjacents a aplicacions on el suport dels proveïdors és sòlid (telemetria de la plataforma d’automatització, salut del servei, registres d’aplicació estructurats) i continueu amb pipelines natives del protocol per a la telemetria de xarxa tradicional (polling SNMP, streaming gNMI) fins que el suport d’OTel als dispositius maduri. Dissenyeu la pipeline per accommodar ambdós enfocaments simultàniament en lloc de forçar una estandarització prematura que requereixi adaptadors per a cada dispositiu de xarxa.

La tendència és clara: OpenTelemetry acabarà convertint-se en l’estàndard per a totes les dades d’observabilitat. Començar amb ell per a la pròpia plataforma d’automatització (meta-monitoratge del capítol 5) és un primer pas de baix risc que construeix familiaritat abans d’estendre-ho als dispositius de xarxa.

Arquitectura del Collector

Simplificant, cada collector es pot descompondre en tres parts (de vegades aquests son connectors i altres vegades estan més codificats).

flowchart LR
    A[ENTRADA] --> B[PROCESSADOR] --> C[SORTIDA]

Figura 4: Arquitectura del Collector.

• Input: Defineix qué s’ha d’observar i sota quins paràmetres.
• Processador: Tot i que és opcional, és molt convenient tan aviat com les dades entren a la pipeline de dades per assegurar la consistència de l’estructura de dades. El processament pot arribar a ser molt complex i pot impactar el rendiment a escala, de manera que no tot el processament s’ha de fer a aquest nivell.
• Output: Mostra com el collector mou les dades a la pipeline. Pot enviar-les directament a altres blocs com el processament o la persistència, o usar el component de distribució per escalar.

Hi ha molts collectors (cadascun amb capacitats diferents) com Telegraf, Grafana Alloy, gNMIc, PMACCT, goflow, etc., però utilitzen una arquitectura similar. Quan trieu un (de vegades en necessitareu varis), abordeu-ho com:

1. Capacitats del dispositiu: quins protocols suporten els vostres dispositius?
2. Volum de dades: alt volum necessita streaming; baix volum pot usar polling.
3. Requisits de latència: temps quasi real vs. intervals tradicionals.
4. Habilitats de l’equip i encaix amb el vostre backend.

Després de recollir les dades, un pas que s’ha introduït és el Processador que manipula les dades en diferents etapes de la pipeline.

6.2.3. Processador#

Les dades en brut dels collectors són desordenades. Dispositius diferents exporten mètriques de manera diferent, els registres són text no estructurat, els valors poden estar en unitats diferents. La capa de processament neteja tot això i el fa útil.

Objectiu: Un cop rebudes les dades, han d’adherir-se a estàndards compartits per convergir senyals de múltiples fonts, correlacionar-los i enriquir-los amb context addicional. Sense aquest pas de processament, les pipelines d’observabilitat es fragmenten ràpidament, són difícils de consultar i cares d’operar. Hi ha múltiples oportunitats per processar-les depenent de l’escala, la complexitat i els requisits operatius.

Les accions de processament comunes que s’apliquen a les pipelines d’observabilitat són les següents.

6.2.3.1. Normalització/Transformació#

Les dades arriben en formats diferents. Arista envia mètriques d’una manera, Cisco d’una altra, syslog és text, NetFlow és binari. La normalització tradueix tot això a un format comú per tal que el vostre backend no hagi d’entendre 50 dialectes diferents.

Estructuració

Els dispositius emeten dades de maneres que els fan sentit. La vostra feina és traduir-les a un format que funcioni per a l’anàlisi:

• Basada en registres:

  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"
  }

• Basada en mètriques: <nom_mètrica>{<etiquetes>} <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

• Basada en taules: algunes eines (per exemple, Suzieq) organitzen les dades en vistes d’estat tabulars indexades pel temps:

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

Reanomenament i alineació

Fonts de telemetria diferents descriuen el mateix concepte usant noms, camins i convencions d’etiquetes diferents. Per exemple:

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 normalització els alinea en un model consistent, incloent el nom de l’objecte, el reanomenament d’etiquetes i el valor (usant la mateixa conversió d’unitats):

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. Enriquiment#

L’enriquiment afegeix contingut extra a les dades d’observabilitat més enllà del que s’observa realment. Aquestes dimensions extra afegides a les dades permeten un consum de dades més sofisticat. Per exemple, podeu ser capaços d’entendre que les mètriques pertanyen a un dispositiu que juga un rol específic a la xarxa i actuar en conseqüència.

Hi ha dos enfocaments principals per a l’enriquiment:

• Extensió de dades Afegir metadades o etiquetes extra a les dades observades per complementar-les. Aquestes dades podrien ser estàtiques (per exemple, org=my-company) per marcar totes les vostres dades, dinàmiques basades en el context de recollida (per exemple, collector_id=1234), o dinàmiques basades en les pròpies dades observades (per exemple, donat hostname=rtr-1, crear una etiqueta location=BCN-01 correlacionant amb el SoT).

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

• Creació de noves dades Seguint el patró de “info metrics” de l’ecosistema Prometheus, podem generar mètriques que no representen estat real sinó estat desitjat. Aquestes mètriques són útils en etapes posteriors de la pipeline d’observabilitat per afegir més dimensions a l’anàlisi, com descobrireu a la secció d’Alertes.

  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

  Les info metrics són un tipus curiós de dades que no tenen les dades rellevants en el valor (per exemple, l'1 en les mètriques anteriors) sinó en les etiquetes. Aquest truc permet reutilitzar Time Series Database (TSDB) que no suporten alguns tipus de valors (com les cadenes de text).

Ambdós enfocaments afegeixen etiquetes i context. Això és potent per a alertes i anàlisi. Però hi ha un cost a tenir en compte:

• Cardinalitat: Cada etiqueta nova multiplica les vostres sèries temporals. Dispositiu x interfícies x mètriques ja és d’alta cardinalitat. Afegiu etiquetes descuidadament i l’emmagatzematge explota, les consultes s’alenteixen. Sigueu reflexius.
• Freqüència d’actualització: Els racks dels dispositius i les IPs de gestió no canvien cada segon. No consulteu les dades d’enriquiment com si consultéssiu mètriques volàtils. Les actualitzacions basades en events funcionen millor, menys consultes a la vostra font de veritat.
• Resiliència: Si la vostra font de veritat es desconnecta, l’enriquiment s’atura. Feu-ne una memòria cau per continuar operant, tot i que sigui de manera degradada. La vostra automatització depèn d’aquestes dades, de manera que feu-les molt robustes.

6.2.3.3. Transformació / Derivació / Agregació#

Preneu mètriques en brut i deriveu-ne de noves. Exemple: combineu tot el trànsit d’entrada d’interfícies dels switches leaf i spine en una única mètrica “ample de banda del fabric utilitzat” per a tendències. Esteu combinant dades existents per respondre preguntes més grans o alimentar panells. Prometheus anomena això “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"}

Una altra funcionalitat de processament per reduir la quantitat de dades és l’agregació, reduint la dimensionalitat ajustada a l’ús final de les dades. Per exemple, resumir informació d’interfícies per dispositiu, o resumir informació de dispositius per lloc. Per exemple, crear càlculs de taxa a partir de mètriques de comptador, o l’agrupació per histograma, pot ser útil per a moltes anàlisis.

6.2.3.4. Filtratge#

Elimineu els elements inútils aviat. No tota línia de registre val la pena emmagatzemar. No totes les mètriques d’interfície importen (potser no us preocupen els loopbacks). Com més aviat filtreu, menys malgasteu en emmagatzematge i processament. Les llistes d’admesos (conserveu això) són més segures que les llistes de denegats (elimineu allò).

6.2.3.5. Mostreig / Limitació#

Fins i tot després del filtratge, el volum pot ser massa alt. Limiteu-lo. Mostreu probabilísticament (“conserveu el 10% d’aquestes sol·licituds”), centreu-vos en les K mètriques principals (“emmagatzemeu només les 100 interfícies més ocupades”), o limiteu per font (“màxim 1000 mètriques per dispositiu”). A mesura que les dades envelleixen a la vostra base de dades, agrupeu-les (la granularitat de 5 segons es converteix en mitjanes de 5 minuts) per estalviar espai.

Finalment, tots aquests processadors es poden executar en diferents etapes de la pipeline d’observabilitat, depenent del cas d’ús:

• Collector: Millor per a la normalització lleugera i el filtratge primerenc
• Processador dedicat: Necessari a escala per a l’enriquiment dinàmic i les transformacions complexes
• Capa de persistència: Adequat per a recording rules i rollups a llarg termini (la Normalització sempre ha de passar abans d’això)
• Capa d’alertes: Deriva events de les dades emmagatzemades i aplica lògica de negoci

A la pràctica, les pipelines d’observabilitat efectives distribueixen el processament entre capes, depenent de les eines, l’escala i les restriccions operatives.

6.2.4. Distribució#

Les pipelines lineals simples (collector -> processador -> base de dades) no escalen. Si la base de dades va lenta, el collector s’encua. Si heu d’actualitzar el processador, atureu la recollida. Tot està estretament acoblat i és fràgil.

Aquí és on entren els brokers de missatges.

Els brokers de missatges com Apache Kafka o NATS s’intercalen al mig. Els productors (collectors, dispositius) publiquen a tòpics. Els consumidors (processadors, bases de dades, alertes) extreuen al seu propi ritme. Completament desacoblat.

Avantatges:

• Escalat: Cada component escala independentment.
• Resiliència: Si un consumidor va lent, les dades s’encuen en lloc de descartar-se.
• Flexibilitat: Les mateixes dades alimenten múltiples backends sense duplicació a la font. Actualitzeu o reinicieu un component sense afectar els altres.

Vegeu el Capítol 11 per a més informació sobre patrons d’escalat i fiabilitat.

6.2.5. Persistència#

Un cop processades les dades, han de viure en algun lloc. La capa de base de dades emmagatzema totes les vostres dades d’observabilitat. Ha de gestionar grans volums, suportar consultes ràpides i mantenir els costos raonables.

Les bones bases de dades per a l’observabilitat comparteixen trets comuns:

• Conscient del temps: Les dades estan inherentment marcades amb timestamp. Les bases de dades s’optimitzen per a consultes de rang i càlculs en finestres temporals.
• Alt throughput d’escriptura: Ingesta constant de mètriques. Les bases de dades ho gestionen sense alentir-se.
• Multidimensional: Les mètriques porten etiquetes (dispositiu, interfície, ubicació). Es consulten i s’agreguen eficientment.
• Consultes flexibles: Necessiteu llenguatges expressius (PromQL, LogQL) per explorar dades sense esquemes predefinits.
• Gestió del cicle de vida: L’emmagatzematge creix ràpidament. Suporteu retenció, downsampling, eliminació per controlar costos.
• Flexibilitat d’esquema: Apareixen noves mètriques constantment. Les bases de dades gestionen l’evolució sense migracions costoses.

Quins tipus de bases de dades funcionen?

Cap base de dades única gestiona perfectament totes les càrregues de treball d’observabilitat, i qui us digui el contrari us està venent alguna cosa. Aquí teniu el que realment funciona:

1. Bases de dades de sèries temporals (Time Series Database (TSDB)): Aquí és on comenceu. Prometheus va guanyar la guerra de les mètriques. El seu model de dades (mètriques amb etiquetes) es va convertir en l’estàndard de facto, i PromQL és el llenguatge de consulta que tothom coneix. Useu Prometheus si esteu per sota dels 100 milions de sèries actives. Més enllà d’això, mireu VictoriaMetrics (compatible amb Prometheus, escala millor, usa menys memòria). InfluxDB és correcte però les seves llicències segueixen canviant. Eviteu les solucions específiques de proveïdor a menys que ja estigueu dins del seu ecosistema.

2. Bases de dades columnars: ClickHouse és el rei aquí. És absurdament ràpid per a l’agregació de registres i l’anàlisi de fluxos. Si necessiteu consultar milers de milions de files per a informes o anàlisi històrica, aquesta és la vostra eina. InfluxDB v3 intenta competir, però ClickHouse té anys d’enduriment. Els fitxers Parquet funcionen per a càrregues de treball analítiques on no necessiteu escriptures en temps real (com fa Suzieq).

3. Bases de dades de cerca de text: Elasticsearch si és necessari, però sincerament, les alternatives modernes com Loki (de Grafana) són més simples i barates d’executar. Splunk és genial si algú altre el paga. El secret brut: la majoria dels equips sobreinverteixen en cerca de registres i sotainverteixen en logging estructurat que faria innecessària la cerca.

La meva recomanació: Comenceu amb Prometheus (o similar) per a mètriques, Loki (o similar) per a registres. Afegiu ClickHouse (o similar) quan necessiteu una anàlisi històrica seriosa. Aquesta pila us portarà a una escala massiva abans de necessitar alguna cosa més sofisticada.

Dos conceptes importants en el disseny de l’emmagatzematge: cardinalitat (quants valors únics pot prendre una etiqueta) i dimensionalitat (quantes etiquetes té una mètrica). Etiquetes d’alta cardinalitat multiplicades per moltes dimensions = explosió de dades emmagatzemades i consultes lentes. Aquest és un dels majors reptes en l’observabilitat. Vegeu el Capítol 11 per a consideracions d’escalat en profunditat.

Després de tota la gestió de dades, hi ha dos passos finals:

• Crear events perquè l’automatització o les persones actuïn: Alertes
• Visualitzar les dades per proporcionar informació per a la presa de decisions: Visualització

6.2.6. Alertes#

Les alertes converteixen dades en acció. El vostre objectiu: alimentar-les a l’automatització. Notificar els humans quan l’automatització no pugui resoldre-ho.

Les alertes flueixen per etapes:

• Detecció: Trobar alguna cosa incorrecta en les dades.
• Processament: Enriquir amb context. És crític? Menor? Fals positiu? Correlacionar alertes relacionades per reduir el soroll.
• Enrutament: Enviar a l’orquestració (executar fluxos de treball), equips (Slack), o gestió d’incidents (PagerDuty).
• Escalada: Si l’automatització falla, els humans intervenen.

flowchart LR
    A[Detecció] --> B[Processador] --> C[Enrutament] --> D[Escalada]

Figura 5: Etapes d'Alertes.

La part difícil no és configurar alertes. És prevenir la fatiga d’alertes. He vist NOCs amb 10.000 alertes actives on ningú les mira ja. En aquell punt, no teniu monitoratge, teniu soroll car.

Aquí teniu com realment ho solucioneu:

1. Enruteu el 95% de les alertes a l’automatització, no als humans. Si un humà veu una alerta, hauria de ser perquè l’automatització ho ha intentat i ha fallat. Flapping d’interfície? L’automatització comprova si és manteniment, reinicia les òptiques, obre un tiquet amb el proveïdor. L’humà només rep l’avís si l’automatització no pot resoldre-ho.

2. Elimineu els llindars estàtics. Les alertes “CPU > 80%” són inútils. El 80% pot ser normal per a aquell dispositiu. Useu línies de base dinàmiques: alerteu quan alguna cosa es desvia del seu patró històric, no d’algun número arbitrari.

3. Agrupeu alertes relacionades. Quan un switch core cau, rebreu 500 alertes dels dispositius aigües avall. Mostreu-ne una: “Switch core caigut, 500 dispositius afectats.” No 500 alertes individuals.

4. Exigiu un runbook per a cada alerta. Si no podeu escriure qué hauria de fer algú quan rep l’alerta, elimineu-la. De veritat. Si l’acció és “investigar”, no és una acció, és una pèrdua de temps.

5. Mesureu la qualitat de les alertes. Seguiu les taxes de falsos positius. Qualsevol alerta amb >10% de falsos positius es corregeix o s’elimina. Seguiu el temps fins a l’acció. Si les alertes queden sense acció durant hores, no són prou importants per existir.

L’objectiu no és “monitoratge exhaustiu”. L’objectiu és “avisar els humans només per coses que els humans han de solucionar.”

6.2.6.1. El paper de la IA i AIOps en l’observabilitat#

Anem a través del hype: la majoria de “l’observabilitat potenciada per IA” és simplement detecció d’anomalies amb un pressupost de màrqueting. Dit això, hi ha valor real aquí si es desplega correctament.

El que realment funciona:

• Detecció d’anomalies: El ML és genuïnament millor que els llindars estàtics per aprendre el que és “normal” per a cada dispositiu. Una CPU al 85% pot estar bé per al dispositiu A, ser un desastre per al dispositiu B. El ML ho esbrinarà automàticament. Això és una necessitat bàsica ara, no màgia.

• Correlació d’alertes: Quan 50 coses fallen simultàniament, el ML pot agrupar-les i suggerir “el switch core probablement és la causa arrel.” Estalvia hores de diagnòstic. Però seguiu necessitant humans per verificar, perquè el ML s’equivoca el 20% de les vegades.

• Previsió de capacitat: El ML és decent en “basant-se en tendències, aquest enllaç se saturarà en 6 setmanes.” Millor que els humans mirant gràfics. Encara necessita judici humà sobre si preocupa.

El que està sobrevalorat:

• Anàlisi automàtica de causa arrel: Cada proveïdor ho promet. Cap ho lliura de manera fiable. Obtindreu suggeriments, de vegades bons, però “la IA ha diagnosticat i solucionat el problema” és el 95% màrqueting i el 5% exemples triats manualment.

• Xarxes autocuratives: L’automatització pot solucionar problemes coneguts amb solucions conegudes. Això no és IA, és bona enginyeria. La veritable “autocuració” per a problemes nous no existeix encara. Quan els proveïdors ho demostren, demaneu-los que us mostrin els casos de fallada.

• “AIOps substitueix el vostre NOC”: No. AIOps ajuda el vostre NOC a ser més efectiu. El judici humà, el context de negoci i la capacitat de gestionar casos límit? Això segueix sent dels humans.

Conclusió: Useu ML per a la detecció d’anomalies i la classificació d’alertes. Sigueu escèptics de tot la resta fins que ho hàgiu provat a la vostra xarxa real, no en una demostració del proveïdor.

6.2.6.2. La interfície alerta-acció#

Una alerta que un humà llegeix és una notificació. Una alerta que l’automatització consumeix és un contracte. Aquests dos consumidors tenen requisits diferents, i confondre’ls és una de les raons més comunes per les quals les pipelines d’alertes fallen a la frontera de l’Orquestrador.

Quan una alerta va destinada a l’automatització, el seu payload ha de ser consumible per la màquina sense anàlisi. Això vol dir dades estructurades, no una línia d’assumpte llegible per humans. Com a mínim, un payload d’alerta destinat a l’automatització hauria d’incloure:

• Identitat del dispositiu: un identificador canònic que coincideixi exactament amb el registre del SoT (no un hostname que pugui diferir entre DNS i el CMDB)
• Classe d’alerta: un tipus estable i enumerat sobre el qual l’Orquestrador pot enrutar (no una descripció de text lliure que canvia quan algú edita la regla d’alerta)
• Gravetat: una enumeració definida, no un valor de llindar numèric
• Timestamp: el temps de l’event en UTC ISO 8601, no el temps de lliurament de la notificació
• Context rellevant: la mètrica o l’estat específic que ha activat l’alerta, en un camp que l’Orquestrador pugui llegir directament (per exemple, "interface": "Ethernet0/1", no integrat en la cadena del missatge)
• Rastre de font: un enllaç o referència de tornada a l’event en brut al sistema d’Observabilitat, per tal que l’Orquestrador pugui re-consultar per obtenir context addicional

Un payload que compleix aquest contracte permet a l’Orquestrador enrutar l’alerta al flux de treball correcte, passar la identitat del dispositiu a la consulta del SoT i invocar l’Executor amb paràmetres estructurats, sense cap anàlisi de cadenes de text. Un payload que no compleix aquest contracte obliga l’Orquestrador a analitzar text llegible per humans, cosa que es trenca cada cop que canvia la descripció de l’alerta.

6.2.7. Visualització#

Objectiu: Totes les dades observades haurien de proporcionar valor als responsables de la presa de decisions, per tant, elaborar visualitzacions orientades a l’usuari hauria de respondre a les seves necessitats.

El bloc final és la capa de panell/informe. Anem directes: la majoria de panells són terribles. O bé són mètriques de vanitat que fan sentir bé als executius (“99,99% de disponibilitat!”) o bé són un vòmit de dades (50 gràfics per pantalla, ningú sap el que signifiquen cap d’ells).

Aquí teniu com construir panells que realment ajuden:

• Construïu per a les decisions, no per a la decoració. Cada element hauria de respondre una pregunta específica o activar una acció específica. Si algú mira un gràfic i no sap qué fer amb ell, elimineu el gràfic.

• Mostreu problemes, no només dades. Els senyals verd/groc/vermell superen els números en brut. “Utilització de la interfície: 45%” és inútil. “Utilització de la interfície: normal” o “Utilització de la interfície: AVÍS, tendència cap a la saturació” és accionable.

• El drill-down jeràrquic supera un gran panell. Comenceu amb un resum de salut global (“3 llocs tenen problemes”). Feu clic en un lloc per veure la salut del dispositiu. Feu clic en un dispositiu per veure les interfícies. Cinc panells centrats superen un desastre desordenat.

• Adapteu-lo a l’audiència. El personal del NOC necessita l’estat operatiu en temps real i drill-down. Els gestors necessiten resums de tendències i impacte de negoci. Els enginyers necessiten accés a dades en brut i interfícies de consulta. Un panell que intenta servir a tothom no serveix a ningú.

• Feu-lo interactiu o no us molesteu. Els panells estàtics envelleixen malament. Deixeu que la gent filtri, faci zoom, ajusti intervals de temps. Suporteu la investigació, no mostreu simplement imatges boniques.

I aquí teniu la postura controvertida: la majoria dels equips tenen massa panells. He vist organitzacions amb 200+ panells on cada persona en mira 2. Elimineu els panells que ningú usa. Si ningú l’ha mirat durant 3 mesos, no importa.

La frontera Visualització/Presentació

La Visualització se situa en una frontera arquitectònica que val la pena abordar directament en lloc de deixar-la com una nota a peu de pàgina. La capa de Presentació (Capítol 8) és responsable de les interfícies orientades a l’usuari: control d’accés, portals d’autoservei, integració ITSM i el disseny de l’experiència d’usuari de com les persones sol·liciten i consumeixen informació. La visualització de les dades d’observabilitat pertany aquí al Capítol 6 perquè les decisions de disseny estan conduïdes completament per les dades: quines mètriques estan disponibles, com s’estructura l’alertes, quins camins de drill-down suporta la capa de persistència. No podeu dissenyar un panell d’observabilitat efectiu sense entendre el model de dades darrere d’ell.

La distinció que importa a la pràctica: els panells construïts directament sobre les dades d’observabilitat per a les decisions operatives (qué passa ara, aquest servei és sa) són una preocupació de l’Observabilitat. Com els mateixos panells es presenten a usuaris no tècnics, s’inclouen en un portal d’autoservei o s’integren amb els fluxos de treball de gestió de canvis és una preocupació de la Presentació. El Capítol 8 revisita aquestes eines des d’aquesta perspectiva d’accés i flux de treball. La majoria d’eines de visualització (Grafana sent la més comuna) difuminen aquesta línia fent les dues coses, que és per qué la separació sembla artificial. No ho és. Les preocupacions són genuïnament diferents fins i tot quan la mateixa eina serveix a les dues.

Les regles bàsiques:

• Claredat: Fàcil d’entendre. Cada element té propòsit.
• Rellevància: Mostreu només dades que suportin decisions. El soroll elimina els insights.
• Orientat a l’usuari: Construïu per a la vostra audiència. El personal del NOC i els gestors necessiten vistes diferents.
• Interactiu: Deixeu que la gent filtri, faci zoom, ajusti el temps. Suporteu la investigació.
• Jeràrquic: Primer una visió global, llavors drill-down. Molts panells centrats superen un panell desordenat.

flowchart TD
    A[Visió Global] --> B[Resum del Lloc] --> C[Resum del Dispositiu] --> D[Detall del Dispositiu] --> E[Detall de la Interfície]

Figura 6: Drill-Down Jeràrquic.

Tingueu en compte que aquest bloc està molt relacionat amb la percepció de l’usuari, de manera que no oblideu entrevistar-los i involucrar-los en el procés.

6.2.8. Observabilitat del Sistema d’Automatització#

La majoria dels equips construeixen observabilitat per a la xarxa. Gairebé cap construeix observabilitat per al propi sistema d’automatització. Això és un punt cec significatiu: quan la pipeline d’automatització falla, la fallada sovint és silenciosa. Cap alerta s’activa, perquè el sistema responsable de generar alertes pot ser el que acaba de deixar de funcionar.

Un playbook que surt amb estat 0 després de desplegar a zero dispositius no genera cap error. Una instància de Telegraf que deixa silenciosament de consultar un protocol específic del proveïdor no produeix cap alerta de dades absents tret que l’instrumenteu específicament. Un job de sincronització del SoT que falla a les 2 del matí i deixa l’inventari obsolet 12 hores mantindrà cada execució posterior funcionant contra llistes de dispositius desactualitzades, i res no senyalarà que això ha passat.

Qué monitorar a la plataforma d’automatització

• Capa d’execució (AWX, Ansible):

  • Taxa d’èxit dels jobs al llarg del temps: una taxa de fallada que creix lentament és un avís primerenc que alguna cosa es degrada
  • Durada de l’execució: un job que normalment triga 4 minuts i triga 40 minuts senyala un problema amb la plataforma, la xarxa, o ambdues
  • Jobs bloquejats en estats pendents o en execució més enllà de la finestra esperada
  • Freqüència de rollback: una taxa de rollback creixent normalment significa que les dades d’intenció o les plantilles tenen un defecte
  • Dispositius assolits per job versus esperats: un desplegament que toca 10 dispositius en lloc de 800 pot haver fallat silenciosament la sincronització de l’inventari sense cap error

• Capa de Font de Veritat:

  • Temps de resposta de l’API i taxa d’errors: una API del SoT lenta bloquejarà cada job d’execució que la consulti
  • Salut del job de sincronització per font: últim temps de sincronització correcta, compte de fallades consecutives
  • Completesa de les dades: quants registres de dispositius falten camps obligatoris dels quals depèn l’execució

• Capa de recollida:

  • Últim timestamp de recollida correcta per dispositiu: un dispositiu no consultat en tres intervals consecutius és efectivament un punt cec de monitoratge
  • Retard de recollida a tota la flota: si l’edat mitjana de les dades creix, el collector s’està quedant enrere
  • Cicles de polling perduts per protocol: les fallades de SNMP i les caigudes de subscripció gNMI s’han de comptar i alertar per separat

El problema de la fallada silenciosa

Les fallades d’automatització més difícils de detectar són els jobs que es completen correctament però no produeixen cap canvi significatiu. Un playbook que es desplega a zero dispositius per causa d’un filtre d’inventari trencat sortirà amb estat 0. L’única manera d’atrapar aquesta classe de fallada és instrumentar a nivell de resultat: “el nombre esperat de dispositius ha canviat d’estat?” en lloc de “el procés del job ha sortit correctament?”

Això vol dir afegir mètriques de resultat als jobs d’execució: un comptador per als dispositius configurats correctament, un gauge per als dispositius que han requerit rollback i una comprovació que el job ha tocat almenys N dispositius abans de marcar-lo com a correcte.

Recomanació arquitectònica

Monitoreu la plataforma d’automatització en una pila d’observabilitat separada i mínima que no depengui del sistema d’observabilitat principal que suporta. Si la instància principal de Prometheus cau, les alertes de la pipeline d’automatització no haurien de caure amb ella. Una pila secundària lleugera (o un servei SaaS d’alertes) que cobreixi només la salut dels components bàsics d’automatització (AWX, Telegraf, API del SoT, jobs de sincronització) proporciona una xarxa de seguretat que el sistema d’observabilitat principal no es pot proporcionar a si mateix.

Això es connecta directament amb el Capítol 7 (Orquestració): un Orquestrador sa hauria d’informar del seu propi estat operatiu com una preocupació de primer ordre. Si no es pot observar l’Orquestrador, tampoc es pot observar l’automatització que coordina.

6.3. Exemple d’Implementació#

Aquesta secció il·lustra com les funcionalitats d’observabilitat s’uneixen a través d’un cas d’ús pràctic usant la pila Telegraf, Prometheus i Grafana i altres eines.

6.3.1. Cas d’Ús: Validació Post-Desplegament i Monitoratge Continu d’un Servei de Campus#

Continuem amb la xarxa de campus del Capítol 5. El nou servei de VLAN s’ha desplegat entre els switches objectiu de l’edifici B per part del bloc d’Execució. Ara l’Observabilitat pren el relleu: primer per validar que el desplegament ha realment tingut èxit des de la perspectiva de l’estat de la xarxa, i després per monitorar la salut del servei de manera contínua a tot el campus.

Escenari: Després de desplegar un nou segment de servei de VLAN a ~800 switches de campus de Cisco, Arista i HPE, l’equip d’operacions necessita confirmar que el servei és actiu i consistent en tots els dispositius previstos, detectar la deriva de configuració si un switch perd la VLAN, i monitorar la salut del trànsit al llarg del temps, sense comprovacions manuals per dispositiu.

Requisits:

• Validar que la pertinença a la VLAN és activa i consistent a tots els switches objectiu després del desplegament
• Alertar sobre la deriva de configuració: VLAN absent d’un switch, canvis inesperats en la pertinença trunk
• Monitorar la salut del trànsit del servei: nivells d’utilització i taxes d’errors per port d’accés
• Detectar pics de trànsit sobtats (>50% de canvi) que puguin indicar fluxos mal enrutats
• Mantenir 30 dies de dades amb resolució de 30 segons per a compliment i planificació de capacitat
• Integrar-se amb Nautobot per a l’inventari de dispositius i les dades d’intenció de VLAN
• Activar fluxos de treball d’orquestració per a la remediació automatitzada quan es detecta deriva

6.3.2. Arquitectura de la Solució#

Abans de començar l’anàlisi de la solució, és important obtenir una estimació de l’escala de l’escenari. Amb ~800 switches de campus x 48 ports x 8 mètriques = aproximadament 307K sèries temporals actives. Això és ben dins del que un únic node Prometheus pot gestionar (còmode fins a ~1M sèries), però la capa de collector necessita múltiples instàncies de Telegraf per distribuir la càrrega de polling entre 800 dispositius a intervals de 30 segons.

Raonament de la selecció de components:

• Telegraf es va triar com a collector pel seu suport multiprotocol (SNMP per a dispositius HPE antics i Cisco antics, gNMI per a Arista i plataformes Cisco més noves), el seu extens ecosistema de connectors i els seus processadors integrats per a la normalització de dades. A l’escala de 800 dispositius, una única instància de Telegraf seria al límit amb intervals de polling de 30 segons, de manera que es despleguen dues o tres instàncies amb Consul coordinant quins objectius gestiona cadascuna.
• Prometheus serveix com a capa de persistència, optimitzada per a dades de sèries temporals amb el seu potent llenguatge de consulta PromQL per a condicions d’alertes complexes. Amb 307K sèries, opera molt dins de la seva zona de confort mentre proporciona integració nativa amb Alertmanager.
• Grafana proporciona visualització amb suport multifont de dades, consultant simultàniament tant les mètriques de Prometheus com les metadades de Nautobot per crear panells rics en context adaptats per a diferents audiències (NOC, planificació de capacitat, gestió).

Arquitectura

A alt nivell, la figura següent mostra els components principals i els seus rols:

flowchart TB
    subgraph Sources["Fonts de Dades"]
        NB[Nautobot<br/>Font de Veritat]
        SW[Dispositius de Xarxa<br/>SNMP/gNMI]
    end

    subgraph Collection["Capa de Recollida"]
        T[Telegraf<br/>Collectors]
        SD[Consul<br/>Descobriment de Serveis]
    end

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

    subgraph Alerting["Alertes"]
        AM[Alertmanager<br/>Enrutament]
    end

    subgraph Presentation["Visualització"]
        G[Grafana<br/>Panells]
    end

    subgraph Integration["Sistemes Externs"]
        ORCH[Orquestrador<br/>Automatització]
        SLACK[Slack<br/>Notificacions]
    end

    NB -->|Inventari de Dispositius| SD
    SD -->|Objectius Dinàmics| T
    SW -->|Mètriques| T
    T -->|Exposa HTTP| P
    P -->|Regles d'Alerta| AM
    P <-->|Consultes| G
    NB -->|Metadades| G
    AM -->|Webhook| ORCH
    AM -->|Alertes| SLACK

Figura 7: Exemple de Solució d'Observabilitat.

6.3.3. Flux d’Implementació#

Integració d’Inventari: Nautobot serveix com a única font de veritat, definint quins dispositius cal monitorar amb perfils de monitoratge i credencials SNMP. Un servei de sincronització lleuger (per exemple, un script Python usant webhooks) actualitza contínuament el registre de serveis de Consul amb informació del dispositiu, habilitant el descobriment dinàmic des del collector.

Recollida de Dades: Telegraf usa Consul per al descobriment de serveis, fent polling SNMP automàticament als dispositius a mesura que apareixen a Nautobot. Els processadors de Telegraf normalitzen i enriqueixen les dades (convertint codis d’estat a etiquetes, reanomenament de camps a noms estàndard, i afegint informació contextual de Nautobot) i exposen les mètriques en format Prometheus en un endpoint HTTP.

Persistència i Anàlisi: Prometheus scrapa els endpoints de Telegraf usant el descobriment de serveis de Consul, emmagatzemant les mètriques a la seva base de dades de sèries temporals. Les recording rules precalculen percentatges d’utilització d’interfícies i taxes d’ample de banda per optimitzar el rendiment de les consultes.

Lògica d’Alertes: Les regles d’alerta a Prometheus defineixen condicions (per exemple, utilització d’interfície >80% durant 5 minuts, pics de trànsit >50% d’increment). Quan les condicions coincideixen, Alertmanager gestiona l’enrutament: les alertes crítiques amb etiquetes automation: enabled van al webhook de l’orquestrador, les altres s’enruten a Slack o PagerDuty en funció de la gravetat.

Visualització: Els panells de Grafana proporcionen múltiples vistes: tendències d’ample de banda del fabric, les interfícies més saturades, drill-downs per dispositiu amb mapes de calor d’interfícies. Les variables de plantilla permeten filtrar per lloc, rol o dispositiu. Els panells consulten tant Prometheus (mètriques) com Nautobot (metadades del dispositiu) per a l’enriquiment contextual.

Automatització de Bucle Tancat: Quan s’activen alertes de saturació crítiques, Alertmanager envia webhooks a la plataforma d’orquestració, que activa fluxos de treball automatitzats d’enginyeria de trànsit per redistribuir la càrrega entre els camins disponibles. Cobrim aquest component al Capítol 7.

6.3.4. Resum de la Solució#

Beneficis Operatius:

• Reducció de l’esforç de monitoratge manual gràcies a la integració amb el SoT
• Detecció proactiva de problemes amb latència inferior al minut
• Remediació de bucle tancat que redueix el MTTR d’hores a minuts
• Context ric que combina mètriques amb dades d’inventari

Consideracions d’Escalabilitat:

• L’arquitectura actual gestiona ~800 switches de campus usant 2-3 instàncies distribuïdes de Telegraf darrere de Consul; afegir més edificis o dispositius significa afegir més instàncies de collector, no rearquitecturar
• La capacitat de Prometheus és suficient amb ~307K sèries amb marge per créixer; un únic node gestiona fins a ~1M sèries abans de requerir federació o un backend distribuït

Aquest breu exercici de solució tanca el capítol que defineix els objectius i funcionalitats bàsiques de l’Observabilitat dins d’una arquitectura d’automatització de xarxes.

6.4. Resum#

L’observabilitat en l’automatització de xarxes s’estén molt més enllà del monitoratge tradicional, proporcionant la base arquitectònica per entendre el comportament de la xarxa, detectar problemes proactivament i habilitar la remediació automatitzada a escala. Construïda sobre set objectius bàsics, des del descobriment automàtic amb mínim esforç humà fins a l’anàlisi sofisticada en temps quasi real i les visualitzacions centrades en l’usuari, l’observabilitat transforma com les organitzacions responen als events de xarxa passant del diagnòstic reactiu a les operacions proactives i basades en dades.

La realització d’aquests objectius requereix set pilars i funcionalitats arquitectòniques interconnectades: integració amb el SoT per al descobriment automàtic de l’inventari, collectors multiprotocol que suporten la ingesta de dades en temps quasi real a través de telemetria en streaming i protocols moderns, processadors que normalitzen i enriqueixen dades heterogènies amb metadades contextuals, sistemes distribuïts per al moviment escalable de dades a grans volums, bases de dades específiques (per exemple, de sèries temporals, columnars i de cerca de text) optimitzades per a càrregues de treball d’observabilitat diverses, alertes intel·ligents amb detecció i enrutament millorats per IA/ML cap als orquestradors o respondedors humans, i visualitzacions adaptades que presenten la informació als nivells d’abstracció adequats per a audiències diverses.

Implementar l’observabilitat requereix decisions arquitectòniques aviat en el procés de disseny. Les organitzacions han de triar entre plataformes tradicionals on-premises, solucions SaaS cloud-native que ofereixen desplegament ràpid i anàlisi potenciada per IA, o piles open-source composables que proporcionen màxima flexibilitat. Cada enfocament implica compromisos en cost, control, sobrecàrrega operativa i capacitat. L’èxit també depèn d’entendre els requisits de processament de dades, des de la normalització i l’enriquiment fins al filtratge i l’agregació, i com les capacitats AIOps emergents poden reduir la fatiga d’alertes i habilitar les operacions predictives.

L’observabilitat no és una única eina sinó un patró arquitectònic coherent. L’èxit depèn de tractar-la com un sistema, on l’inventari impulsa la recollida, la recollida habilita el processament, el processament alimenta la distribució, la distribució es connecta a la persistència, la persistència informa les alertes, i les alertes finalment impulsen la visualització i la resposta automatitzada. Dissenyant acuradament cada component i com interactuen, les organitzacions poden construir sistemes d’observabilitat que escalen amb les seves xarxes, s’integren amb protocols moderns com OpenTelemetry i gNMI, i transformen la visibilitat operativa en intel·ligència accionable que impulsa l’automatització de bucle tancat.

Referències i Lectura Addicional#

• Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): Un enfocament pràctic usant eines open-source com Telegraf, Prometheus i Grafana

💬 Found something to improve? Send feedback for this chapter