PathruleVerificação e ciclo de vida
Como o Pathrule Signals agrupa eventos, o que significa cada status de grupo e cada estado de verificação, a evidência de que uma correção precisa para contar como verificada e por quanto tempo o Local mantém os grupos.
Nesta página
O Signals separa duas perguntas: o que continua acontecendo e se uma correção realmente funcionou. A primeira é respondida pelo agrupamento, a segunda pela verificação, e só evidências de runtime conseguem responder a segunda.
Grupos
Cada evento pertence a um grupo por ambiente, tipo (error ou event) e fingerprint. O fingerprint é derivado do rótulo, do fluxo e do caminho de código do evento. Assim, a mesma falha no mesmo lugar forma um único grupo, não importa quantas vezes aconteça, e o mesmo erro em produção e em preview fica em grupos separados. Cada envelope carrega um id que se mantém igual em todas as tentativas, então um envelope reenviado é armazenado uma única vez.
Status e verificação
Um grupo tem um status:
active: está acontecendo, ou voltou a acontecer.declared: um ponto de instrumentação foi anunciado, mas nada foi reportado ainda.resolved: a verificação provou que a correção funcionou.archived: ficou em silêncio e foi encerrado. Arquivado não é o mesmo que resolvido.
E um estado de verificação:
| Estado | Significado |
|---|---|
unobserved | Nenhuma correção registrada, ou nenhuma release mais nova vista até agora. |
observing | Uma release mais nova está rodando e as evidências estão sendo coletadas. |
quiet | 24 horas e pelo menos 3 envelopes da release mais nova sem recorrência. É o máximo que um grupo sem fluxo consegue alcançar. |
verified | A correção funcionou: a evidência descrita abaixo foi atingida. O grupo passa a resolved. |
recurred | Aconteceu de novo em uma release mais nova. O grupo volta a ser active. |
O que conta como evidência
Uma correção é verificada quando as três condições valem para uma release mais nova do que aquela em que a correção foi registrada:
- pelo menos 60 minutos de observação,
- pelo menos 3 envelopes dessa release mais nova,
- pelo menos 3 sucessos do próprio fluxo do grupo, reportados com
meta.outcome: "success".
Algumas coisas nunca contam: a release de referência, eventos sem identificação de release e qualquer coisa observada antes do registro da correção. Uma release mais nova reinicia a observação. Se a release mais nova ficar 45 minutos em silêncio, um estado quiet fica desatualizado. Sem identificação de release, a verificação fica bloqueada e o SDK reporta no_release.
Registrar uma correção
Quando você ou o seu agente corrigem algo, a correção é registrada no grupo (veja integração com agentes). Registrar é uma afirmação, não uma prova: por si só, isso não leva nada a resolved. Só a verificação faz isso. Não existe resolução manual, e qualquer ocorrência em uma release mais nova, mesmo depois de verified, coloca o grupo em recurred e de volta a active.
Retenção no Pathrule Local
- Até 5.000 grupos por espaço de trabalho.
- Um grupo não resolvido expira após 14 dias sem ocorrência em produção, 7 dias em desenvolvimento ou preview e 30 dias no caso de uma declaração.
- Grupos resolvidos e o histórico deles são mantidos por 90 dias.
- Os ids de envelope ficam guardados por 2 dias, e é isso que torna as novas tentativas seguras.
A retenção no Cloud está descrita na página Cloud Signals.