PathruleVerifica e ciclo di vita
Come Pathrule Signals raggruppa gli eventi, cosa significano lo stato di un gruppo e lo stato di verifica, quali prove servono perché una correzione sia considerata verificata e per quanto tempo Local conserva i gruppi.
In questa pagina
Signals tiene distinte due domande: cosa continua a succedere e se una correzione ha davvero funzionato. Alla prima risponde il raggruppamento, alla seconda la verifica, e solo le prove raccolte a runtime possono rispondere alla seconda.
Gruppi
Ogni evento appartiene a un gruppo, uno per ogni combinazione di ambiente, tipo (error o event) e fingerprint. Il fingerprint deriva dall'etichetta, dal flusso e dal percorso nel codice dell'evento: lo stesso errore nello stesso punto forma quindi un unico gruppo, per quanto spesso si verifichi, mentre lo stesso errore in produzione e in preview resta separato. Ogni envelope ha un id che rimane identico a ogni nuovo tentativo, quindi un envelope ritrasmesso viene salvato una sola volta.
Stato e verifica
Un gruppo ha uno stato:
active: si sta verificando, oppure si è ripresentato.declared: è stato annunciato un punto di strumentazione, ma non è ancora stato segnalato nulla.resolved: la verifica ha dimostrato che la correzione ha funzionato.archived: non si è più verificato ed è stato chiuso. Archiviato non significa risolto.
E uno stato di verifica:
| Stato | Significato |
|---|---|
unobserved | Nessuna correzione registrata, oppure nessuna release più recente ancora vista. |
observing | È in esecuzione una release più recente e si stanno raccogliendo le prove. |
quiet | 24 ore e almeno 3 envelope dalla release più recente senza che il problema si ripresenti. È il massimo che può raggiungere un gruppo senza flusso. |
verified | La correzione ha funzionato: le prove descritte sotto sono state soddisfatte. Il gruppo diventa resolved. |
recurred | Si è ripresentato in una release più recente. Il gruppo torna active. |
Cosa conta come prova
Una correzione è verificata quando, per una release più recente di quella rispetto a cui è stata registrata, valgono tutte e tre le condizioni:
- almeno 60 minuti di osservazione,
- almeno 3 envelope da quella release più recente,
- almeno 3 successi del flusso del gruppo stesso, segnalati con
meta.outcome: "success".
Alcune cose non contano mai: la release di riferimento, gli eventi senza identità di release e tutto ciò che è stato osservato prima che la correzione venisse registrata. Una release ancora più recente fa ripartire l'osservazione da capo. Se la release più recente resta silenziosa per 45 minuti, uno stato quiet diventa obsoleto. Senza identità di release la verifica è bloccata e l'SDK segnala no_release.
Registrare una correzione
Quando tu o il tuo agente correggete qualcosa, la correzione viene registrata sul gruppo (vedi integrazione con gli agenti). La registrazione è un'affermazione, non una prova: da sola non porta nulla a resolved. Ci riesce solo la verifica. Non esiste una risoluzione manuale, e qualsiasi occorrenza in una release più recente, anche dopo verified, porta il gruppo a recurred e di nuovo ad active.
Conservazione in Pathrule Local
- Fino a 5.000 gruppi per workspace.
- Un gruppo non risolto scade dopo 14 giorni senza occorrenze in produzione, dopo 7 giorni in sviluppo o preview e dopo 30 giorni nel caso di una dichiarazione.
- I gruppi risolti e la loro cronologia vengono conservati per 90 giorni.
- Gli id degli envelope vengono ricordati per 2 giorni, ed è questo che rende sicuri i nuovi tentativi.
La conservazione in Cloud è descritta nella pagina Cloud Signals.