PathruleVerificación y ciclo de vida
Cómo Pathrule Signals agrupa los eventos, qué significa cada estado de grupo y de verificación, qué evidencia necesita una corrección para considerarse verificada y cuánto tiempo conserva Local los grupos.
En esta página
Signals distingue dos preguntas: qué sigue ocurriendo y si una corrección realmente funcionó. La primera se responde con la agrupación; la segunda, con la verificación, y solo la evidencia en tiempo de ejecución puede responderla.
Grupos
Cada evento pertenece a un único grupo según su entorno, su tipo (error o event) y su huella. La huella se deriva de la etiqueta, el flujo y la ruta de código del evento. Por eso, el mismo fallo en el mismo lugar forma un solo grupo sin importar cuántas veces ocurra, y el mismo error en producción y en preview se mantiene por separado. Cada sobre lleva un id que no cambia entre reintentos, así que un sobre reintentado se almacena una sola vez.
Estado y verificación
Un grupo tiene un estado:
active: está ocurriendo, o volvió a ocurrir.declared: se anunció un punto de instrumentación, pero todavía no se ha reportado nada.resolved: la verificación demostró que la corrección funcionó.archived: dejó de ocurrir y se cerró. Archivado no significa resuelto.
Y un estado de verificación:
| Estado | Significado |
|---|---|
unobserved | No hay ninguna corrección registrada o todavía no se ha visto una versión más nueva. |
observing | Hay una versión más nueva en ejecución y se está recopilando evidencia. |
quiet | 24 horas y al menos 3 sobres de la versión más nueva sin que el problema se repita. Es lo máximo que puede alcanzar un grupo sin flujo. |
verified | La corrección funcionó: se cumplió la evidencia que se describe más abajo. El grupo pasa a resolved. |
recurred | Volvió a ocurrir en una versión más nueva. El grupo vuelve a estar active. |
Qué cuenta como evidencia
Una corrección queda verificada cuando se cumplen las tres condiciones para una versión más nueva que aquella con la que se registró la corrección:
- al menos 60 minutos de observación,
- al menos 3 sobres de esa versión más nueva,
- al menos 3 éxitos del propio flujo del grupo, reportados con
meta.outcome: "success".
Algunas cosas nunca cuentan: la versión de referencia, los eventos sin identidad de versión y todo lo observado antes de registrar la corrección. Una versión más nueva reinicia la observación. Si la versión más nueva deja de enviar datos durante 45 minutos, un estado quiet queda desactualizado. Sin identidad de versión, la verificación queda bloqueada y el SDK reporta no_release.
Registrar una corrección
Cuando tú o tu agente corrigen algo, la corrección se registra en el grupo (consulta integración con agentes). Registrarla es una afirmación, no una prueba: por sí sola no mueve nada a resolved. Solo la verificación lo hace. No existe la resolución manual, y cualquier ocurrencia en una versión más nueva, incluso después de verified, pone el grupo en recurred y lo devuelve a active.
Retención en Pathrule Local
- Hasta 5.000 grupos por espacio de trabajo.
- Un grupo sin resolver vence tras 14 días sin ocurrencias en producción, 7 días en desarrollo o preview y 30 días en el caso de una declaración.
- Los grupos resueltos y su historial se conservan durante 90 días.
- Los ids de los sobres se recuerdan durante 2 días, y eso es lo que hace seguros los reintentos.
La retención en Cloud se describe en la página de Cloud Signals.