La observabilidad empieza por el evento de negocio que falló

La observabilidad de eventos de negocio empieza con una pregunta de soporte: ¿qué ocurrió con la solicitud que envió el usuario? Las gráficas de CPU y las tasas de errores HTTP no bastan. El producto necesita una identidad persistente para el trabajo y evidencia de su avance hacia un resultado definido.

Empezá con un flujo importante. Instrumentar todo sin describir qué significa terminar puede generar muchos datos y poca claridad operativa.

Definí aceptación, finalización y falta de avance

Elegí eventos que correspondan a cambios reales de estado. Una exportación puede quedar aceptada, en cola, generada y disponible, o terminar con una falla definitiva. “La solicitud devolvió 200” es una observación técnica, no evidencia de que exista el archivo.

Asigná un identificador que sobreviva a reintentos y tareas en segundo plano. Incluí el contexto de organización cuando corresponda y esté autorizado, pero evitá guardar contenido sensible en los registros. Registrá versión del evento, hora, resultado y un código de motivo comprensible para soporte.

Separá el registro de operaciones de los logs de diagnóstico. La telemetría puede muestrearse o vencer; no debería ser la única evidencia de aceptación. Un proceso de conciliación puede comparar el estado persistido con las transiciones previstas cuando falte un evento.

Las trazas explican el recorrido

OpenTelemetry describe las trazas como el recorrido de una solicitud por la aplicación, formado por spans. Usá ese recorrido para investigar la operación de negocio y conservá su identificador entre intentos que pueden generar trazas distintas.

Propagá contexto en los mensajes de cola y vinculá correctamente el trabajo asíncrono. Si el trabajador no guarda conexión con la solicitud original, soporte termina reconstruyendo la historia con horas aproximadas. Agregá referencias externas cuando sea seguro, sin registrar credenciales ni respuestas completas del proveedor.

Los identificadores de alta cardinalidad pertenecen a logs o trazas, no a una etiqueta de serie temporal distinta por operación. Las métricas resumen tasas y antigüedad; el registro detallado identifica el trabajo afectado.

Ejemplo hipotético: una exportación aparentemente sana

Un producto acepta 100 solicitudes hipotéticas de exportación. Todos los manejadores HTTP terminan bien. El trabajador genera 98 archivos, pero dos operaciones siguen en cola porque se perdieron sus mensajes. La disponibilidad de los servidores continúa normal.

La señal útil es la antigüedad del trabajo aceptado sin resultado final. Para este ejemplo, el equipo elige una expectativa de diez minutos para exportaciones ordinarias y otra clase para las grandes. Son decisiones ilustrativas, no umbrales recomendados para toda industria.

Señal	Pregunta que responde
Operaciones aceptadas	¿El producto reconoció el trabajo?
Resultados finales por grupo de aceptación	¿Cuánto de ese trabajo terminó?
Operación pendiente más antigua	¿Qué podría estar detenido?
Motivos de reintento y falla	¿Dónde conviene investigar?

No restés simplemente las finalizaciones de hoy de las solicitudes de hoy si una tarea puede cruzar ese límite temporal. Usá grupos de aceptación o estados pendientes para no confundir trabajo lento pero válido con trabajo perdido.

Cada alerta debe llevar a una decisión

La alerta necesita flujo, alcance afectado, enlace a evidencia y responsable. Su procedimiento debe distinguir reintento seguro de conciliación. De lo contrario, alguien puede duplicar una acción al intentar limpiar la cola.

Elegí una consulta reciente de soporte y verificá si el equipo puede responderla con un identificador de operación, sin búsquedas manuales entre sistemas. Es una mejora acotada para software a la medida y permite comprobar si la nueva telemetría realmente ayuda.