Observabilidad API: conectar señales con decisiones

Conectar la telemetría a una tarea de usuario

Las métricas, los registros y los rastreos responden a diferentes preguntas. Un alto tiempo de actividad puede ocultar un fallo en el proceso de compra o inicio de sesión. Defina el resultado que esperan los usuarios y, a continuación, instrumente las llamadas que lo proporcionan.

• Elija un indicador de recorrido para el éxito, la latencia y el fallo visible para el usuario.
• Propaga la correlación entre servicios, limitando al mismo tiempo los datos confidenciales en los rastreos.
• Simule un fallo de dependencia para comprobar si las alertas dan lugar a acciones y a un modo degradado comprensible.

Fuente primaria: OpenTelemetry — Observability primer. Método relacionado: consultar la guía práctica.

Fallo de recogida: conciliar registros y eventos ausentes

Distinguir eventos producidos, recibidos y utilizables sin interpretar el silencio como ausencia de incidentes.

• Relaciona aplicación, colector y almacenamiento con responsables. Prepara una secuencia finita de eventos ficticios con identificadores estables, sin secretos ni datos de clientes. Conserva tiempos de evento y observación: el retraso no equivale automáticamente a pérdida.
• En pruebas, interrumpe el destino y restablécelo. Observa llenado de cola, reintentos, rechazos y reinicio. Una cola persistente puede limitar pérdidas, pero tiene capacidad y depende del almacenamiento; define qué ocurre al llenarse. Verifica que la recogida no bloquee silenciosamente el servicio.
• Concilia la referencia con eventos realmente legibles al mismo corte. Cuenta repeticiones, retrasos y ausencias por separado; un acuse de red no prueba utilidad final. Sin referencia fiable declara cobertura desconocida, no cero pérdidas ni cero incidentes.

{
    "expected_ids": [
        "E1",
        "E2",
        "E3"
    ],
    "received_ids": [
        "E1",
        "E1",
        "E3"
    ],
    "received_rows": 3,
    "unique_received": 2,
    "missing_ids": [
        "E2"
    ],
    "observation_cutoff": "same_for_both_sets"
}

Fuente primaria: OpenTelemetry — Collector resiliency. Método relacionado: consultar la guía práctica.

Subdominios abandonados: retirar un CNAME con control

Vincular cada nombre DNS a un recurso controlado y cerrar sus dependencias antes de liberar el servicio.

• Registra nombre público, cadena CNAME, recurso y responsable. Compara DNS con el inventario de la cuenta autorizada. Un error HTTP, NXDOMAIN o recurso ausente exige revisión; no demuestra que un tercero pueda reclamarlo. Las protecciones varían por proveedor.
• Elimina el enlace o dirígelo a un destino controlado antes de borrar el recurso. Considera los TTL anteriores y las cachés; comprueba DNS autoritativo y varios resolutores. Conserva las validaciones de propiedad aún necesarias, sin borrar todos los TXT.
• Revisa enlaces, redirecciones, callbacks OAuth, webhooks y dominios de cookies. Si el recurso ya fue liberado, corrige DNS e investiga posibles exposiciones según el proceso de incidentes. Reconcilia DNS e inventario tras cada eliminación.

{
    "name": "portal.example",
    "cname_present": true,
    "resource_deleted": true,
    "provider_claimability": "not_verified",
    "takeover_observed": false,
    "expected": "remove_or_replace_mapping_and_review_exposure"
}

Fuente primaria: Microsoft — Prevent dangling DNS entries. Método relacionado: consultar la guía práctica.

Reintentos API: calcular el presupuesto completo

Separe tiempo por llamada, esperas y recorrido completo.

Método relacionado: consultar la guía práctica.