Investigar un problema
Del síntoma a la causa — el panel de una API, la línea de tiempo de una sesión, la cadena de un error y el estado de los problemas.
Investigar es ir del síntoma a la causa sin adivinar por el camino. El Radar está diseñado para ese recorrido: se elige lo que falló, se ve cada ejecución una a una, y se sigue hacia atrás hasta el paso que la originó.
Esta página recorre ese camino en cuatro etapas — la API, la sesión, el problema, y el registro de auditoría que explica por qué ahora.
Una API que falla
- Abre la app y ve a Radar.
- En la sección APIs y scripts, haz clic en la fila de la API — por
ejemplo
oportunidades. - Se abre una pestaña con su nombre, y arriba tres etiquetas: el nombre interno, 116 llamadas y media 4ms. Cuando hay fallos, aparece también «N fallos (X%)».
La tabla tiene una fila por llamada — nunca agrupada — con cinco columnas:
| Columna | Qué muestra |
|---|---|
| Cuándo | El momento de la llamada. |
| Estado | El estado HTTP devuelto. |
| Operación | La operación pedida, cuando la llamada la identifica. |
| Resultado | sin error, o el tipo de error que reventó. |
| Tiempo | Cuánto tardó. |
La barra Filtrar… sobre la tabla reduce la lista por cualquiera de
estos campos: solo los fallos, solo las de más de 500 ms, solo las de hoy.
La paginación de abajo dice dónde estás — 1–50 de 116.
El detalle de una llamada
Haz clic en una fila y se abre el panel de detalle, abajo, con tres pestañas:
| Pestaña | Qué trae |
|---|---|
| General | Cuándo, Tiempo, Estado, Origen, Quién hizo la llamada y el Trace que la identifica. |
| Enviado | Lo que la llamada llevó. Cuando hay dudas de tipos, muestra campo a campo lo Enviado y el Tipo esperado, con el sospechoso en rojo. |
| Respuesta | Lo que volvió. Una llamada que no devolvió nada dice «No volvió nada.»; una que no llevó nada dice «Esta llamada no llevó nada.» |
Consejo
El Trace es el hilo que lo une todo. La misma referencia aparece en los eventos de la Observabilidad y en el detalle del error — cópiala y tienes el recorrido entero de una petición, incluso cuando pasó por varias piezas.
Los scripts tienen un panel gemelo: una fila por ejecución, con el Código de salida, el Origen del disparo y la Consola — la salida que el script escribió. Un script sin ejecuciones en el periodo dice «Sin ejecuciones registradas.»
La línea de tiempo de una sesión
Una llamada aislada raramente explica un error. La pregunta siguiente es siempre «¿qué estaba haciendo la persona?» — y para eso sirven las sesiones.
- En Radar, expande la sección Sesiones.
- Haz clic en la visita que te interesa —
23:11 · demo. - El panel abre con quién entró, cuándo, y un resumen: 15 pasos en 5 páginas.
La tabla es la línea de tiempo de la visita, un paso por fila:
| Columna | Qué muestra |
|---|---|
| Nombre | El paso: una página, una pantalla, un evento, una llamada a una API, una lectura de datos. |
| Estado | Si salió bien o mal. |
| Origen | De dónde vino el paso — Páginas, Pantallas, Acciones, Datos. |
| Tiempo | Cuánto tardó. |
| Cascada | La barra que muestra cuándo ocurrió dentro de la sesión y cuánto ocupó. |
La cascada es lo que hace la lectura inmediata: las barras se alinean en el
tiempo, y un paso que tardó se ve sin leer ningún número. Haz clic en una
fila para el detalle — con Página, Cuándo, Tiempo y Desde el
inicio de la sesión (+0.0s, +2.4s, …). Un paso que no llamó al
servidor lo dice: «Este paso no llamó al servidor.»
Nota
Una sesión vacía — «Sin pasos en esta sesión.» — normalmente es una visita que abrió la app y salió antes de que pasara nada. No es un error.
Un error de código
Los errores que nacieron en el código de los eventos aparecen en la sección Pantallas, agrupados por la causa: un problema por error distinto, con el número de ocurrencias al lado.
Haz clic en uno para abrir el panel del problema, que junta todo lo que se sabe sobre él:
| Zona | Qué responde |
|---|---|
| Código | El fragmento de tu código, con la línea culpable destacada, y la Posición exacta. |
| Camino hasta aquí | Lo que la persona hizo antes de reventar — página, pantalla, lecturas de datos, el clic final. |
| Rastro del error | El rastro técnico, cuando fue guardado. |
| Flujo | El recorrido del error por las piezas de la app. |
| Abrir en el designer | Te lleva directo al evento donde el error nació. |
El botón Abrir en el designer es el final natural de la investigación: encontraste la línea, ahora vas a corregirla.
Un error que la plataforma clasificó como De la plataforma muestra otra cosa: «Este error nació en el runtime de Keplin, no en el código de tu app. No hay nada que corregir de tu lado — vale la pena reportarlo.» — con una Referencia para copiar.
Los problemas, en todas las apps
El menú Observabilidad → Problemas es la misma materia, junta y con estado. Cada fila es un problema agrupado, con Ocurrencias, Usuarios afectados, Visto por primera vez y Visto por última vez.
Una instalación sana tiene esta página vacía — «Ningún problema coincide con los filtros», con Limpiar filtros para ampliar la búsqueda. Antes de concluir que no hay problemas, confirma el periodo de arriba: con 1h elegido, un error de ayer no aparece.
Cada problema tiene tres estados, y se cambian en el propio panel:
| Acción | Qué hace |
|---|---|
| Resolver | Lo marca como tratado — «Problema marcado como resuelto.» Si vuelve a ocurrir, se reabre solo. |
| Ignorar | Lo quita del camino sin resolverlo — «Problema ignorado.» Para el ruido que se conoce. |
| Reabrir | Lo devuelve a abierto — «Problema reabierto.» |
Dentro de un problema, la Cadena del problema dibuja el recorrido: el contexto en el navegador, las ejecuciones correlacionadas, el error y el impacto observado. Cuando no hay forma de conectar las piezas, lo dice en vez de inventar — «Las conexiones discontinuas representan solo contexto confirmado, no una relación causal inferida.»
Los eventos, uno a uno
Observabilidad → Eventos es la lista cruda: una fila por ejecución de API, script o sistema, incluidas las que salieron bien.
Columnas: Cuándo, Tipo, App, Qué, Duración y Resultado. Los filtros de arriba cortan por App, Tipo, Estado, Severidad y periodo; Limpiar filtros lo repone todo.
Haz clic en una fila y el detalle se abre al lado, con Resumen y Datos — y Abrir la página completa cuando necesitas más espacio. Los mensajes de error aparecen en el idioma original del servidor, a propósito: traducirlos los alejaría del texto que se busca en la documentación.
¿Y por qué ahora? La auditoría
Un error que empezó hoy casi siempre tiene un cambio detrás. Observabilidad → Auditoría guarda los cambios administrativos y de configuración — crear, modificar, borrar, ejecutar, importar, exportar, revocar, restablecer contraseña, cambiar role — con quién los hizo, en qué app y cuándo.
Haz clic en una fila y el detalle muestra el Antes y el Después del cambio. Es la respuesta directa a la pregunta que cierra la mayoría de las investigaciones: «¿qué cambió ayer por la tarde?»
El camino, resumido
- Vista general — qué app está ardiendo.
- Radar de la app — qué API, script o pantalla.
- Su panel — qué llamada, con qué datos, en qué momento.
- La sesión — lo que la persona hizo antes.
- El problema — la línea de código y el botón Abrir en el designer.
- La Auditoría — qué cambió para que esto empezara.
¿Por qué no veo…?
- …el detalle de una llamada? Ninguna fila está seleccionada. La tabla dice «Elige una fila para ver el detalle.»
- …las ocurrencias de un problema antiguo? Pueden haber sido llevadas por la rotación de registros — el panel avisa cuando eso ocurre.
- …el Camino hasta aquí relleno? No todas las ocurrencias traen el recorrido; cuando no lo traen, el panel dice «Sin camino registrado para esta ocurrencia.» en vez de mostrar pasos inventados.
- …el botón Abrir en el designer? Solo aparece en errores con origen en el código de la app. Los errores de la plataforma no tienen nada que abrir.