GM
ES/EN
Volver a proyectos

Plataforma de diagnóstico / Producto propio

Speed.Logging

Plataforma de logging distribuido con API, cliente, contratos compartidos y dashboard, nacida de un problema real de diagnóstico en campo.

Rol: Arquitectura, backend, cliente y dashboard Duración: Proyecto propio, en evolución 2026

El problema

Diagnosticar una aplicación que corre en un dispositivo en campo es difícil: no hay depurador conectado, el problema no se reproduce en el escritorio y los registros locales solo se leen después de que alguien viaja al sitio. Necesitaba ver lo que la aplicación estaba haciendo, mientras lo hacía, sin instalar nada nuevo en el dispositivo.

Del punto de llamada al visor El código de negocio escribe contra la abstracción estándar; el destino se resuelve por configuración. Servicio ILOGGER<T> Abstracción SIN ACOPLE Buffer ASÍNCRONO Destinos RED · REMOTO · CONSOLA Visor DASHBOARD Los consumidores no saben a dónde van sus registros. Por eso el patrón se puede llevar a otra aplicación.
Del punto de llamada al visor

Restricciones

  • El envío de registros no puede bloquear el hilo de interfaz
  • Debe poder activarse y desactivarse sin reiniciar la aplicación
  • El consumidor de la librería no debería acoplarse a un backend de logging concreto
  • Red local poco fiable — perder un registro es aceptable, congelar la aplicación no

Decisiones

Decidí Exponer la abstracción estándar de logging del framework y resolver el backend por configuración
En lugar de Exponer directamente el cliente de la librería de logging elegida
Porque Quien consume la librería escribe contra una interfaz que ya conoce. El backend se puede cambiar sin tocar una sola línea de los consumidores.
Decidí Envolver el destino de red en un buffer asíncrono
En lugar de Escribir al socket de forma síncrona desde el punto de llamada
Porque Un registro nunca debe hacer esperar a la interfaz. Perder mensajes bajo presión es preferible a bloquear la aplicación.
Decidí Un proyecto de contratos separado, compartido entre API, cliente y dashboard
En lugar de Definir los modelos en cada extremo
Porque El formato del registro es el punto de acuerdo del sistema. Tenerlo en un sitio hace que un cambio rompa la compilación, no la producción.
Decidí Transmisión sobre un protocolo sin conexión, compatible con visores existentes
En lugar de Un protocolo propio con confirmación de entrega
Porque La compatibilidad con herramientas que ya existen valía más que la garantía de entrega, para un canal de diagnóstico.

Resultado

  • API de ingesta, cliente instrumentable, contratos compartidos y dashboard de consulta
  • Activación del diagnóstico en tiempo de ejecución, sin reiniciar la aplicación
  • Destinos intercambiables — red, remoto y consola — configurados por reglas
  • Patrón documentado y reutilizable como plugin en otras aplicaciones

De un problema puntual a una plataforma

Esto empezó como una necesidad concreta: entender qué hacía una aplicación Android industrial mientras corría en el sitio del cliente. La primera versión fue un destino de red conectado a la abstracción de logging estándar. Funcionó lo bastante bien como para preguntarme qué más faltaba.

Lo que faltaba era el otro extremo: un servicio que recibiera, un contrato explícito de qué es un registro, y una interfaz para leerlos. De ahí salieron los cuatro componentes.

La decisión que sostiene el diseño

Los consumidores escriben contra la abstracción de logging del framework, no contra la librería concreta que hay debajo. Esa indirección es la razón de que el mismo patrón se pueda llevar a otra aplicación como plugin: nada en el código de negocio sabe a dónde van sus registros.

El destino de red va envuelto en un buffer asíncrono. Es una decisión con un coste explícito —bajo presión se pierden mensajes— tomada porque la alternativa, hacer esperar al hilo de interfaz por un socket, es inaceptable en una aplicación que alguien está usando de pie frente a una máquina.

Por qué está aquí

Porque muestra el ciclo completo sobre un problema propio: detectar la necesidad, resolverla de forma acotada, reconocer que el patrón era reutilizable, documentarlo y construir el resto del sistema alrededor.