Una API puede responder rápido mientras duplica una orden; un proceso puede estar saludable mientras deja eventos pendientes. La observabilidad permite explicar el comportamiento mediante señales. La verificación comprueba si ese comportamiento conserva un contrato.
Ambas comienzan con una pregunta concreta: ¿qué resultado debe existir, qué anomalía importa y en qué frontera se decide? Añadir logs a todos los métodos no sustituye esa definición.
Invariantes antes del dashboard
En boletaje, una invariante es que un asiento y evento no tengan dos ventas válidas. También importa que una orden conserve sus intentos de pago y que un cobro incierto tenga una ruta de recuperación. Estas reglas se hacen cumplir en la autoridad correspondiente; una alerta informa de una desviación, pero no la impide.
Para una proyección, el contrato puede exigir no retroceder la versión de una entidad y recuperar eventos que faltan. Para un worker, el resultado puede ser terminado, pendiente recuperable o fallo definitivo con causa. Medir sólo HTTP 200 mezcla aceptación y finalización.
| Contrato | Señal útil | Comprobación |
|---|---|---|
| Una venta válida por asiento | Conflictos y decisiones durables. | Consultar el estado autoritativo bajo concurrencia. |
| Intentos inciertos recuperables | Cantidad y edad de pendientes. | Perder respuestas y reconciliar por identidad. |
| Proyección dentro de su frescura | Lag, versión y eventos detenidos. | Comparar con la fuente sin asumir que el consumidor está al día. |
| Trabajo útil dentro del plazo | Latencia, rechazos y edad de cola. | Introducir carga y una dependencia lenta. |
Identidades para seguir el resultado
Un request ID identifica una petición; un operation ID identifica la operación lógica y permanece estable entre sus reintentos; un event ID identifica el evento lógico y se conserva en sus publicaciones repetidas. Una operación puede tener varias peticiones y entregas. Correlacionarlas evita interpretar cada reintento como una compra distinta o cada span como un efecto confirmado.
El trace context enlaza spans entre servicios cuando se propaga correctamente. OpenTelemetry también organiza métricas y logs, pero una traza incompleta no demuestra que no ocurrió un efecto. Sampling, procesos caídos y fallos de exportación pueden ocultar parte del recorrido.
Se valida el contexto en límites de confianza y se evita transportar secretos o datos personales en baggage. Las identidades se conservan en el registro de negocio cuando la recuperación las necesita; el sistema de telemetría no sustituye ese registro durable.
Señales de servicio y de negocio
Latencia, tráfico, errores y saturación describen el servicio, pero necesitan unidades y fronteras. Se distinguen duración en cola, ejecución, dependencia y respuesta. Un timeout del cliente puede coexistir con un commit exitoso.
Para capacidad, importan p95/p99 por operación y trabajo completado antes de su plazo. Para recuperación, importan antigüedad de pendientes, reintentos, discrepancias y tiempo hasta resolver. Un SLI especifica población, ventana y condición de éxito; un SLO fija un objetivo para ese indicador.
El presupuesto de error guía decisiones, pero no autoriza violar invariantes financieras. Un catálogo puede admitir respuestas viejas dentro de su contrato; una venta doble requiere una protección distinta de permitir cierto porcentaje de latencia alta.
Un circuito de evidencia
Las señales y los ensayos contrastan el resultado con el contrato. La reconciliación consulta la autoridad, en vez de decidir por ausencia de un log.
--- config: look: handDrawn --- flowchart TD operation["Operación<br/>Identidad estable"] --> authority["Decisión durable<br/>Invariantes"] operation --> signals["Métricas, logs y trazas<br/>Contexto controlado"] authority --> verify["Verificar resultado<br/>y reconciliar"] signals --> verify tests["Ensayos de concurrencia<br/>y fallos"] --> verify verify --> action["Corregir, recuperar<br/>o ajustar contrato"]
Un reporte debe distinguir observado, inferido y no comprobado. Un span muestra una acción instrumentada; no certifica por sí solo causalidad completa ni atomicidad entre almacenes. Las afirmaciones de consistencia y autoridad requieren evidencia de sus fronteras.
Cardinalidad, coste y acceso
Cada combinación de labels de Prometheus crea una serie. Ruta normalizada, clase de resultado y servicio son dimensiones que pueden acotarse. User ID, email o request ID por petición pueden producir crecimiento sin límite y exponer datos.
Los identificadores detallados pueden ser útiles en logs o traces controlados, con permisos, retención y redacción adecuados. No es necesario copiar payloads completos para explicar una decisión. Se diseña también el coste de exportación, almacenamiento y consulta de las señales.
El pipeline de telemetría tiene sus propios buffers y fallos. Si se detiene, la aplicación necesita un comportamiento definido: acotar memoria y evaluar qué evidencia se pierde. Bloquear una venta indefinidamente por un exportador caído puede crear otro incidente.
Ensayar las ventanas difíciles
Las pruebas de idempotencia pierden la respuesta después del commit, envían claves duplicadas concurrentes y reciben resultados tardíos. Las de outbox interrumpen entre publicación y checkpoint, duplican eventos y reconstruyen una proyección.
Las de recuperación aíslan un escritor, promueven una réplica y restauran un respaldo. Las de admisión sobrecargan una dependencia sin permitir una cola infinita. Cada ensayo declara condiciones iniciales, fallo inyectado, criterio de éxito y limpieza del entorno de prueba.
No basta comprobar que el proceso reinició. Se consulta el resultado, la unicidad, los pendientes y su recuperación. Los efectos externos usan entornos y contratos seguros, sin llamar a un cobro real sólo para probar un timeout.
Convertir evidencia en operación
Una alerta útil indica qué contrato peligra, qué población afecta y dónde investigar. Un runbook conecta señales con decisiones de recuperación verificables: consultar autoridad, pausar admisión, reconciliar un intento o restaurar una copia ensayada.
Las discrepancias se registran sin borrar la historia. Después de recuperar, se comprueba que el backlog drena y que los estados inciertos tienen un dueño y plazo. La observabilidad ofrece explicación; las restricciones, los protocolos y los ensayos sostienen la corrección.
Referencias: propagación de contexto de OpenTelemetry, señales y nombres y labels de Prometheus.