Tracce, misure e sessioni

Queste funzioni estendono il monitoraggio degli errori. La disponibilità dipende da versione del backend, processori configurati e profilo SDK della tua installazione. Pubblicare un pacchetto non attiva da solo OTLP o l’elaborazione dei crash nativi. Parti dalla guida alle integrazioni e verifica con il gestore quali servizi sono attivi.

Segui una richiesta tra i servizi

La vista delle tracce mostra le operazioni conservate in un diagramma temporale. Filtra per servizio, ambiente e versione, apri un’operazione e segui i collegamenti ai log e agli errori correlati, quando presenti.

Operazioni padre mancanti, dati scaduti e risultati incompleti restano visibili. La presenza di un’operazione radice non dimostra che tutti i servizi abbiano inviato dati. La durata è l’intervallo osservato, non la somma di operazioni sovrapposte.

Invia le operazioni tramite OpenTelemetry. Gli identificativi delle richieste e gli header W3C degli SDK nativi permettono la correlazione, ma da soli non creano tracce memorizzate.

Esplora le misure e configura gli avvisi

Le misure mantengono il significato di gauge, somme e istogrammi, con unità e attributi delle risorse. Filtra una serie per servizio, ambiente o attributi tipizzati prima di confrontare i valori. Questi dati sono separati dai problemi di performance delle query e dei metodi lenti.

Ogni regola collega un progetto e una serie, con una finestra da 60 a 86.400 secondi. Usa ultimo/minimo/massimo per i gauge, somma/tasso per le somme, oppure conteggio/somma/percentile per gli istogrammi. I percentili sono stime con i limiti degli intervalli, non valori esatti ricavati dai singoli eventi.

La valutazione avviene ogni minuto su finestre chiuse, con almeno 30 secondi di attesa. I dati mancanti o incompleti restano sconosciuti, mai zero o un rientro automatico. Un avviso sui percentili scatta solo quando l’intero intervallo di incertezza supera la soglia. Il rientro aggiorna lo stato della regola; questo profilo non invia una notifica esterna di rientro.

Confronta le sessioni tra versioni

La salute delle sessioni confronta gli esiti per versione e ambiente. È separata dal replay delle sessioni del browser.

La percentuale senza crash usa gli esiti conclusi e conosciuti. Le sessioni aperte e anomale restano sconosciute e sono escluse dal denominatore. Senza esiti conosciuti, la percentuale non è disponibile, anziché essere 100%.

Sessioni individuali e richieste aggregate restano separate. Gli aggiornamenti individuali con identità possono essere deduplicati; i nuovi invii degli aggregati no, perché il produttore non fornisce un’identità univoca della consegna. La percentuale delle sessioni non conta persone distinte.

Usa un produttore di sessioni Sentry compatibile: attivare un SDK nativo CloseYourIt non crea automaticamente questi dati.

Ricostruisci le posizioni originali degli errori

Gli artefatti privati della build permettono di vedere stack ricevuto e stack ricostruito separatamente nel dettaglio errore:

• Source map JavaScript: recuperano funzioni, file e righe dell’applicazione minificata.
• Mapping R8/ProGuard: ricostruiscono frame e cause Java, mantenendo visibili chiamate inline e alternative ambigue.
• Simboli nativi: risolvono gli indirizzi ricevuti quando piattaforma, architettura e identità della build corrispondono ai simboli caricati.

Carica gli artefatti con i comandi dedicati della CLI, usando la versione esatta e gli identificativi richiesti della build. La gestione richiede artifacts.manage; una chiave SDK pubblica non può caricare o leggere artefatti privati. Rimuovi il contenuto dei sorgenti dalle source map prima del caricamento, seguendo la guida CLI. Artefatti mancanti, non corrispondenti o eliminati restano espliciti; la ricostruzione non sostituisce l’errore originale.

I crash nativi richiedono un SDK compatibile e il processore configurato. Il runtime C/C++ osservato è Linux arm64: non dimostra supporto macOS, Windows, iOS o Android NDK. I minidump grezzi possono contenere memoria del processo e segreti: proteggi l’archiviazione locale e usa il percorso crash documentato, non una coda persistente generica.

Verifica la tua installazione

Genera un errore o un’operazione controllata in un’applicazione di test, poi verifica il dato memorizzato nel progetto, nella versione e nell’ambiente corretti. Per i simboli, controlla sia lo stack originale sia quello ricostruito. Caricamento riuscito, flush dell’exporter o risposta HTTP positiva non dimostrano da soli persistenza o ricostruzione.

Per scegliere i comandi di caricamento, vedi artefatti privati nella CLI.