El lado oscuro del StreamingTelemetry

Camilo CardonaNTT

¿Qué es el streaming telemetry?

• Streaming de valores definidos en un modelo YANG• Alternativa al SNMP, y, sobretodo, al polling• Varias alternativas en las tecnologías que lo soportan

Get-bulk 1.3.6.1.2.1.2.2.1.2 (IF-MIB)Data

… N minutos después

Get-bulk 1.3.6.1.2.1.2.2.1.2Data SNMP

¿Qué es el streaming telemetry?

• Streaming de valores definidos en un modelo YANG• Alternativa al SNMP, y, sobretodo, al polling• Varias alternativas en las tecnologías que lo soportan

Suscripción a ietf-interfaces:interfaces/interface/statistics

Data

… N segundos despuésData

…

¿Cuál es la desventaja de del SNMP?

• No habrá nuevo Contenido: Las métricas de nuevas tecnologías no se expondrán en MIBs (i.e. SMIv2) sino en módulos de YANG.• Escalabilidad: Recolectar mas datos de manera precisa

• Referencia: “SNMP is dead” de NANOG 73*

*Referencias en la ultima slide

¿Esto es suficiente para convencer a la industria para abandonar el SNMP?

Estado del streaming telemetry en la industria

• Se ha desarrollado en los últimos años, pero está fracturado• Openconfig / IETF / propietario

• Openconfig se ha desarrollado rápidamente, el código disponible es mas amplio, pero es básicamente controlado por Google

• La IETF ha trabajado lentamente. Definió un framework flexible, pero hay poco código

Ecosistema del streaming telemetry

• Plano de control• Cómo se

configuran/establecen los flujos de datos (streams)

• Tipos de flujos de datos:• Sample• On-change

YANG

KafkaTSDB

Grafana

ZeroMQSQLNoSQL

Kibana

GPB JSONXML

GRPC

TCPUDP

NETCONF

RESTCONF

Pivot

Transporte

Encoding

Data Model

GRPCCollectors

Msg queues/streams, almacenamiento y otros sistemas

Transporte

• Define el protocolo de comunicación entre el dispositivo y el colector• Ejemplos:• Protocolos propietarios basados en UDP, TCP• GRPC

• Definiciones propietarias• GNMI

• NETCONF (RFC 8640), RESTCONF

Transporte

• Ejemplos: UDP, TCP, GRPC (e.g. GNMI), NETCONF (RFC 8640), RESTCONF• En algunos de estos la comunicación la establece el servidor, en otras

el colector. Algunos permiten ambas.• La capa de transporte define el control de flujo (i.e. backpressure).

Los protocolos complejos no son puramente PUSH.• GNMI define como detectar y tratar los consumidores lentos

• Mirar “duplicates” en la sección 2.1 de la gnmi-specification*

Encoding

• Ejemplos: XML, JSON, Google Protocol Buffers (GPB), otros pueden venir…• GPB puede ser genérico (e.g. GPB-KV) o pueden existir esquemas para cada

modelo (e.g. GPB Compact)• Todo es un trade-off:

• Recomendado: Capitulo 4. del libro Designing Data-Intensive Applications

• Ya es relativamente sencillo decodificar/codificar en varios lenguajes• El tipo de encoding es importante cuando se desea escalar.

Muchos enrutadores solo soportan un tipo de encoding. Los colectores deben ser flexibles.

YANG modelos

• Modelos standard• Standards, pero no siempre cumplen con todas las necesidades

• Modelos nativos• Exclusivos de un vendor/modelo• Pueden cubrir muchos mas datos• Muchas veces auto-generados y con problemas en estructura (e.g.

Excesivamente jerárquicos, claves no bien definidas)

Los colectores posiblemente deban transformar los datos para ajustar modelos

Data

YANG models

¿Qué hacer con los datos que se generan?

• Surgirán herramientas para requerimientos ”standard”• Contadores de interfaces• Modelos/transporte/Encoding standard

• Cada ISP/Red tendrá que ajustar sus herramientas para requerimientos ”ad-hoc”

¿Que hacer con los datos que se generan?

Colectores Bases de datos

telegraf

Pmacct

InfluxDB

Visualización

KafkaPivot

Msg queues/streams

Conclusiones

• La industria todavía está en maduración• Sin embargo, ya es posible recolectar datos útiles de modelos básicos

• Los colectores deben ser flexibles.• Todavía se necesita trabajo en la estandarización y afinación de

modelos• Post-transformaciones pueden ser necesarias

• No es trivial, son necesarias mejores herramientas.• Probablemente el mejor recurso para aprender todo esto en un solo

lugar:• Network Programmability with YANG: The Structure of Network Automation

with YANG, NETCONF, RESTCONF, and gNMI.

Referencias

• Icons:• Router: Yudha Agung Pribadi,

https://www.iconfinder.com/icons/575175/cisco_networking_router_stencil_visio_icon

• Server: https://www.iconfinder.com/icons/298866/server_icon• Yang: https://www.iconfinder.com/icons/379381/yang_yin_icon

• Presentaciones:• https://pc.nanog.org/static/published/meetings/NANOG73/1677/20180625_Shakir_

Snmp_Is_Dead_v1.pdf• Otros

• Especificación GNMI: https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md

Back-up

Tipos de Stream

• Sampling• Los datos son enviados a una frecuencia determinada

• On-change• Los datos se envían solamente cuando hay cambios• Eficiente para unos tipos de datos, pero complica el sistema

Control plane

• YANG PUSH (en RFC8639) define una manera estándar de establecer subscripciones• Independiente de transporte

• GNMI define sus propios mecanismos de suscripción.