Observabilidad en el borde: sucursales, cajeros y dispositivos

La mayoría de las guías de observabilidad asumen que la telemetría nace cerca de donde se analiza: en un clúster, en una región de nube, en el mismo centro de datos que la plataforma de monitoreo. Pero una parte importante de la experiencia del cliente ocurre lejos de ahí. Un cajero automático que no entrega efectivo, una terminal de sucursal que no imprime el comprobante o un quiosco de autoservicio que se reinicia en bucle son incidentes reales, y suelen ser los que el cliente recuerda.

Observar el borde no es instalar el mismo agente en más equipos. Cambian las condiciones: la conectividad es intermitente, el ancho de banda es limitado y caro, los relojes se desfasan, los equipos se mueven, se reemplazan o se apagan, y a veces nadie en el sitio sabe qué hacer cuando algo falla. Este artículo propone una arquitectura y un conjunto de decisiones para que la telemetría de esos sitios llegue completa, ordenada y confiable.

Una arquitectura en capas para el borde

El patrón que recomendamos tiene cuatro capas: el dispositivo que genera la señal, un colector local en el sitio, el enlace hacia el centro y la plataforma central. La pieza clave es el colector local, porque desacopla al dispositivo de la calidad del enlace.

OpenTelemetry Collector encaja bien en este papel porque su documentación describe precisamente dos patrones de despliegue: agente, un colector junto a la aplicación o en el mismo equipo, y gateway, uno o más colectores que reciben la telemetría de muchos orígenes en un único punto OTLP. En el borde suelen combinarse: un agente en cada equipo con capacidad suficiente, o un colector por sucursal que actúa como gateway local para los dispositivos que no pueden ejecutar uno propio; y un gateway central que recibe a todos los sitios y aplica las políticas comunes antes de entregar a la plataforma.

Si tus aplicaciones ya están instrumentadas con OpenTelemetry, como describimos en observabilidad desde el código, el cambio para el borde está en la topología de recolección, no en el código. Si no lo están, el colector puede leer archivos de log locales mientras se avanza en la instrumentación.

Conectividad intermitente: búfer local y reintentos

Una sucursal puede perder el enlace minutos u horas, y un dispositivo móvil puede pasar días sin conexión estable. Si la telemetría se pierde justo cuando el enlace falla, la plataforma central queda ciega en el momento en que más importa.

El protocolo OTLP define cómo comportarse ante fallas: qué respuestas se reintentan (en HTTP, por ejemplo, 429, 502, 503 y 504), cuáles no, y cómo respetar las señales de contrapresión del servidor con espera exponencial. El colector implementa esto con dos mecanismos que conviene configurar de forma explícita:

• Reintentos (retry_on_failure), con intervalos crecientes y un tiempo máximo.
• Cola de envío (sending_queue), que por defecto vive en memoria y se pierde si el equipo se reinicia. Con la extensión file_storage la cola pasa a ser persistente en disco.

El búfer tiene que dimensionarse. Una regla de partida: estima el volumen por hora del sitio, multiplícalo por la duración de la caída más larga que quieres tolerar y compara el resultado con el disco disponible. Si no alcanza, define qué se sacrifica primero. Recomendamos conservar siempre los eventos de negocio y de seguridad, y descartar antes los logs de depuración y las métricas de alta frecuencia.

Este es un ejemplo mínimo de configuración de un colector de sucursal. Los valores de memoria, rutas y nombres son ilustrativos; ajústalos a tu equipo.

# Colector local de una sucursal (ejemplo ilustrativo).
# filelog y file_storage vienen en la distribución contrib del Collector.
extensions:
  file_storage:
    directory: /var/lib/otelcol/buffer   # el directorio debe existir

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: localhost:4317         # solo aplicaciones del mismo equipo
  filelog:
    include: [ /var/log/terminal/*.log ]
    storage: file_storage                # recuerda hasta dónde leyó cada archivo

processors:
  memory_limiter:                        # siempre el primer procesador
    check_interval: 1s
    limit_mib: 200
    spike_limit_mib: 50
  resource:
    attributes:
      - key: site.id                     # identidad del sitio en cada dato
        value: sucursal-0001
        action: upsert
  batch:

exporters:
  otlp:
    endpoint: gateway.ejemplo.internal:4317
    tls:
      ca_file: /etc/otelcol/ca.pem       # TLS mutuo: valida al gateway...
      cert_file: /etc/otelcol/sitio.pem  # ...y el gateway valida al sitio
      key_file: /etc/otelcol/sitio.key
    retry_on_failure:
      enabled: true
      max_elapsed_time: 0                # reintenta sin límite de tiempo
    sending_queue:
      storage: file_storage              # cola persistente en disco

service:
  extensions: [file_storage]
  pipelines:
    logs:
      receivers: [otlp, filelog]
      processors: [memory_limiter, resource, batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch]
      exporters: [otlp]

Dos detalles importan. El procesador memory_limiter va primero en la cadena, como recomienda su documentación, para que el colector aplique contrapresión antes de quedarse sin memoria en un equipo modesto. Y el reintento sin límite de tiempo solo tiene sentido con una cola persistente de tamaño acotado: cuando la cola se llena, el colector descarta lo nuevo en lugar de crecer sin control.

Menos datos en origen: filtrado y muestreo

En el borde, cada byte cuesta: ancho de banda compartido con la operación del negocio, enlaces de respaldo por datos móviles y almacenamiento central. Reducir en origen es más barato que reducir en destino.

• Filtrar lo que no se va a usar, con el procesador filter: logs de depuración en producción, métricas que nadie consulta, chequeos de salud repetitivos.
• Agregar antes de enviar: muchas preguntas se responden con un conteo por minuto en lugar de cada evento individual.
• Muestrear trazas con criterio. El muestreo probabilístico en el colector local (probabilistic_sampler) es simple y predecible. El muestreo por cola (tail_sampling), que decide después de ver la traza completa y permite conservar todas las trazas con error, conviene hacerlo en el gateway central, donde llegan todos los tramos de una misma transacción.

Una advertencia: nunca muestrees los eventos que alimentan indicadores de negocio o de seguridad. Si un tablero cuenta retiros fallidos, esos eventos tienen que llegar todos. Las señales de negocio son las que conectan el borde con lo que describimos en observabilidad de negocio en banca.

Tiempo, identidad y seguridad de la transmisión

Sincronización de reloj

Correlacionar un error en un cajero con una falla en el autorizador central exige que ambos relojes digan la verdad. La guía NIST SP 800-92 sobre gestión de logs de seguridad identifica las marcas de tiempo inconsistentes entre fuentes como uno de los retos de la gestión de logs: cada equipo registra según su propio reloj, y sin una referencia común la reconstrucción de eventos pierde valor. En la práctica: NTP configurado y monitoreado en cada dispositivo, y una alerta cuando el desfase supera un umbral que tu equipo defina. El modelo de datos de logs de OpenTelemetry ayuda, porque distingue la marca de tiempo del evento en origen de la marca de tiempo en que el colector lo observó; conservar ambas permite detectar relojes desfasados y datos que llegaron tarde por una caída del enlace.

Identidad del dispositivo y del sitio

Cada dato debe decir de dónde viene sin depender de una dirección IP, que en el borde cambia con frecuencia. Recomendamos atributos de recurso estables: identificador del equipo, sitio, región, tipo de dispositivo y versión de software, siguiendo las convenciones semánticas de OpenTelemetry donde existan (por ejemplo, host.id o service.instance.id) y atributos propios documentados donde no.

Seguridad de la transmisión

La telemetría del borde viaja por redes que no controlas del todo y puede contener datos sensibles. Tres prácticas mínimas: TLS mutuo con un certificado por sitio o por dispositivo, que se pueda revocar de forma individual; enmascarar en el colector local los datos personales o de tarjeta antes de que salgan del sitio; y proteger el búfer en disco con los mismos controles que cualquier otro almacenamiento local del equipo. NIST SP 800-92 trata la integridad y la confidencialidad de los registros, tanto en tránsito como almacenados, como parte de la infraestructura de gestión de logs.

Inventario: saber qué debería estar reportando

En la nube, un recurso que deja de enviar datos suele haber sido eliminado. En el borde, un equipo que deja de enviar datos puede estar apagado, sin red, robado o con el colector caído. Y si nadie sabía que ese equipo existía, su silencio no genera ninguna alerta.

Por eso la observabilidad del borde empieza por un inventario confiable:

1. Lista de lo esperado. Cada sitio y cada dispositivo, con su identificador, dueño, criticidad y horario de operación, en la CMDB o en la fuente de verdad que uses.
2. Latido. Cada colector envía una señal periódica propia, independiente de la actividad del negocio. El colector expone además sus propias métricas internas, útiles para ver colas que crecen o datos rechazados.
3. Alerta por ausencia. Compara lo esperado con lo recibido y alerta cuando un dispositivo crítico no reporta dentro de su horario, con un umbral que tolere caídas cortas del enlace.
4. Versiones y configuración. Registra qué versión de colector y qué configuración tiene cada sitio. Una flota con decenas de configuraciones distintas es imposible de operar.

Ese inventario es también lo que permite al centro de comando pasar de "el equipo X no responde" a "la sucursal Y opera sin dos de sus tres cajeros desde hace una hora", que es la información que el negocio necesita.

Cómo empezar

Recomendamos empezar con un piloto acotado: un tipo de dispositivo y pocos sitios representativos, incluidos los de peor conectividad. Define antes qué preguntas debe responder la telemetría (disponibilidad del servicio en el sitio, tasa de transacciones fallidas, salud del equipo) y elige las señales con ese criterio, apoyándote en lo que cada una responde mejor, como explicamos en logs, métricas y trazas. Después prueba lo que importa: corta el enlace de un sitio piloto durante el tiempo que quieres tolerar, restablécelo y verifica que la telemetría llegó completa, en orden y sin duplicados relevantes. Con eso medido, la expansión a toda la red es un problema de despliegue, no de diseño.

Si la telemetría incluye datos de clientes, valida con Seguridad y con la función de protección de datos qué se enmascara en origen y cuánto tiempo se conserva el búfer.