Un bug, un problema, un conteggio di cui fidarsi.
Raggruppare è tutto il lavoro di un tracciatore di errori, e il conteggio che ne esce è quello che ti dice quale dei quattrocento problemi risolvere un martedì mattina. Bugtail raggruppa sulla forma del guasto, tiene la traccia fuori dal database, e non perde mai il conteggio quando la traccia viene ripulita.
Raggruppato su ciò che rende lo stesso bug
Un'eccezione viene identificata dal suo tipo e dai frame del tuo codice che l'hanno prodotta, non dal messaggio. Conta perché un messaggio di solito porta un identificatore: "Utente 8812 non trovato" e "Utente 913 non trovato" sono un bug, e un tracciatore che li mostra come due ha trasformato un problema in un elenco.
Quando il raggruppamento non va bene per la tua applicazione, puoi dirlo per collettore. Quello che non puoi è farlo dipendere dal payload, perché il payload non c'è sempre.
La traccia non entra mai nel database
Le tabelle dei problemi e degli eventi contengono titoli, livelli, conteggi, marche temporali e un puntatore. La traccia stessa, il contesto della richiesta e i breadcrumb sono JSON compresso nel tuo bucket. Non è un'ottimizzazione, è il vincolo su cui poggia tutto il progetto: tiene il database abbastanza piccolo da restare veloce, rende la conservazione due decisioni separate, e rende la cancellazione della parte sensibile una cancellazione e non una modifica di schema.
Una riga di evento deve perciò restare utile quando il suo payload non c'è più, e lo resta: il titolo, il livello, la release, la URL senza query string e il conteggio sono tutti ancora lì un anno dopo, molto tempo dopo che la traccia è stata ripulita.
Due finestre di conservazione
Quanto vive una riga di evento e quanto vive il suo payload, impostate separatamente, per collettore.
I conteggi sopravvivono ai payload
I grafici vengono dagli aggregati e non dal contare righe, quindi la pulizia non cambia mai lo storico.
Ripulito prima di essere scritto
Password, token, cookie, numeri di carta e IBAN, a qualsiasi profondità, in entrata.
Una regressione è uno stato, non un problema nuovo
Risolvi un problema e si chiude. Se arriva di nuovo la stessa impronta, il problema si riapre come regressione e dice quale release l'ha riportato, invece di comparire come qualcosa di nuovo da smistare da capo. Puoi anche rimandarlo alla prossima release, che è quello che davvero vuoi per un bug già risolto ma non ancora pubblicato.
Domande che la gente fa davvero
Posso cambiare come vengono raggruppati gli errori?
Per collettore, sì. L'impronta predefinita usa il tipo di eccezione e i tuoi frame; puoi restringerla o allargarla quando la tua applicazione ha bisogno di altro.
Cosa succede a un problema quando le sue tracce vengono ripulite?
Resta. Titolo, livello, release, conteggi e grafici sono tutti nel database e nessuno di essi viene dal payload. Aprire un vecchio problema mostra tutto tranne la traccia stessa, e dice chiaramente che è stata ripulita.
Fate pagare gli eventi che raggruppate insieme?
Ogni evento registrato conta una volta, raggruppato o no. Gli eventi rifiutati dal tuo elenco di host consentiti non ti vengono conteggiati, e nemmeno quelli scartati dal campionamento.
Quattordici giorni di Team, senza carta.
Registrati con il tuo indirizzo di lavoro, dimostra il tuo dominio con un record DNS e incolla una DSN. La prima traccia di solito arriva prima del caffè.
Nessuna carta. La prova finisce da sola e scende a Free; non si addebita nulla se non scegli un piano.
