OpenTelemetry en internet rural: trazas, métricas y reclamos

Un caso anonimizado muestra cómo unir cortes, tickets y latencia con OpenTelemetry Collector, PostgreSQL y roles claros para soporte rural.

ULTIMA MILLA · Proyectos · 6 de jun de 2026 · 4 min de lectura

Antes, soporte buscaba un corte rural por ping y llamadas; después, cada reclamo tuvo traza, métrica y log con el mismo identificador. En una cooperativa eléctrica con internet rural, OpenTelemetry Collector ordenó eventos de routers, API de tickets y monitoreo sin cambiar todas las aplicaciones. Este caso explica qué dato viaja, dónde se guarda, quién lo consulta y cómo se prueba la restauración.

Dónde aparece el reclamo sin recorrido

La documentación de OpenTelemetry Collector lo presenta como un componente que recibe, procesa y exporta telemetría. La página de señales separa trazas, métricas, logs y baggage. CNCF anunció la graduación de OpenTelemetry en mayo de 2026 y registró más de 12.000 contribuyentes desde su formación, una cifra que ubica el estándar fuera del laboratorio. El problema cuyano era más chico y más áspero: un abonado llamaba por microcortes, soporte veía pings correctos y campo encontraba un enlace saturado dos horas después. El gabinete de chapa marcado W-14 tenía una etiqueta comida por el sol. Ese objeto resumía el caso: la red tenía eventos, pero cada sistema los nombraba de otra forma. El ticket sin recorrido era el antagonista. Tenía número, cliente y hora, pero no unía latencia, reinicio de equipo, cambio de firmware y respuesta del operador. La cooperativa necesitaba una línea de tiempo que soporte, campo y gerencia pudieran leer sin abrir cinco herramientas.

Cómo funciona por dentro

El flujo empieza con routers, API de tickets, aplicaciones de cobranza y servicios web que emiten métricas, logs o trazas. OpenTelemetry Collector recibe datos por OTLP, Prometheus o archivos; los procesadores agregan atributos, filtran campos y agrupan por zona, equipo o cliente. Los exportadores mandan telemetría a Prometheus, Loki, Jaeger, Tempo u otro backend. PostgreSQL guarda clientes, tickets, equipos, zonas, cuadrillas y auditoría de atención. El backend de observabilidad guarda series, eventos y trazas. Keycloak o el directorio interno entrega grupos: soporte consulta reclamos y equipos, campo ve zona y orden de trabajo, gerencia mira tendencias, IT administra pipelines y credenciales. La especificación OTLP define cómo viajan los datos entre componentes. La configuración del Collector ordena receivers, processors, exporters y pipelines. El backup copia PostgreSQL, configuración del Collector y retención del backend; la prueba restaura un día de reclamos y reconstruye un incidente de punta a punta. La primera regla operativa fue asignar un identificador común. El ticket, la traza, el log del router y la métrica de latencia comparten zona, equipo y ventana horaria. Si un dato llega sin esos atributos, el Collector lo conserva, pero el tablero lo marca como incompleto.

Qué se instala o configura primero

La pila mínima usa OpenTelemetry Collector 0.153.0, Prometheus o VictoriaMetrics para métricas, Loki o OpenSearch para logs, Jaeger o Tempo para trazas, PostgreSQL para inventario operativo, Keycloak para roles y backup con Restic. Un despliegue rural chico queda entre USD 130 y USD 280 mensuales. Con dólar vendedor oficial de ARS 1.462, el rango va de ARS 190.060 a ARS 409.360 por mes. La implementación inicial lleva 35 a 65 horas: inventario de fuentes, configuración de Collector, atributos comunes, tablero, roles, retención y prueba de restauración. El primer entregable verificable es un reclamo simulado que muestre ticket, equipo, zona, latencia, reinicio y acción tomada. UMSA puede tomar el piloto sobre una zona, no sobre toda la red. Se eligen diez routers, una API de tickets, un servicio de autenticación y un tablero. La cooperativa conserva su mesa de ayuda; OpenTelemetry une los eventos técnicos con la operación. La política de privacidad se define antes de recolectar. Los logs no deben guardar contraseñas, tokens, documentos ni mensajes completos de clientes. La guía de seguridad de OpenTelemetry ayuda a revisar credenciales, transporte TLS y exposición de endpoints. El dato útil es técnico y operativo: equipo, zona, hora, evento, duración y responsable.

Dónde se rompe y cómo probarlo

El primer riesgo es el atributo faltante. La señal aparece cuando una traza llega sin zona o equipo. La prueba envía eventos válidos e incompletos; el tablero debe separar ambos y mostrar qué fuente necesita corrección. El segundo riesgo es guardar datos sensibles en logs. La señal aparece cuando aparecen tokens, contraseñas o documentos. La prueba inyecta valores señuelo y verifica que el Collector los filtre antes de exportar. El tercer riesgo es la retención despareja. La señal aparece cuando el ticket vive un año y las métricas sólo una semana. La prueba reconstruye un reclamo de hace 30 días y confirma que conserve ticket, evento técnico y acción. El cuarto riesgo es el permiso excesivo. La señal aparece cuando soporte puede editar pipelines o gerencia puede ver datos técnicos sensibles. La prueba crea grupos de soporte, campo, gerencia e IT; cada uno intenta consultar, exportar y editar. El quinto riesgo es la restauración sin configuración. La señal aparece cuando vuelve PostgreSQL, pero el Collector perdió receivers y exporters. La prueba restaura configuración, reinicia el pipeline y reenvía un incidente simulado. Un reclamo rural queda cerrado cuando otra persona puede reconstruir minuto, equipo, zona y decisión.