api@1.2.3 o un commit Git. LogBrew non crea una release da un tag del
repository né da un deploy. Ogni envelope di telemetria nativo deve includere
release e environment non vuoti. LogBrew rifiuta una richiesta senza questi
campi.
Release, progetto, servizio e ambiente
Dai un nome alle release
Usa una versione immutabile, un numero di build o un commit Git. In un monorepo, aggiungi un breve prefisso del servizio, comeweb@b7f4d91 e
worker@3a9c120. Usa lo stesso valore per problemi, log, tracce, azioni e
metriche che provengono dallo stesso artefatto.
Corretto
api@1.2.3, web@b7f4d91, ios@2026.06.01 e
worker@2026-06-01.1 identificano ciascuno un solo artefatto.Da evitare
latest, prod, new e build non identificano una versione del
codice. LogBrew rifiuta una stringa vuota.
Un nome di branch Git come
feature/login non è una release valida. Usa
invece il commit.
Usa nomi di ambiente stabili come production, staging, preview e
local. Una release può essere eseguita in più di un ambiente.
Imposta entrambi i valori nella configurazione del deploy, così la pipeline
CI/CD li passa all’SDK. Nel valore della release metti solo un’etichetta di
versione. Non includere segreti, nomi di clienti o URL. Dopo un deploy, invia
un evento sicuro e rileggilo con il filtro della release.
Leggi i riepiloghi delle release
I conteggi misurano segnali diversi. Non sommarli.
first_seen_at e last_seen_at non sono orari di deploy. Un servizio può
inviare altra telemetria con la stessa release anche più tardi. LogBrew ordina
i riepiloghi per last_seen_at, dal più recente.
next_action indica il primo tipo di segnale che contiene dati, in questo
ordine:
La route API è
GET /api/telemetry/releases. Per i filtri e i campi del
cursore, vedi Filtri di query dell’API di telemetria.
Leggi i tassi di errore delle tracce
trace_health conta le tracce distinte, non gli span. Una traccia con almeno
uno span di errore conta come una traccia con errori.
error_rate_basis_points va da 0 a 10000. Dividilo per 100 per ottenere
una percentuale. Per esempio, 2500 è il 25%. Leggi trace_count prima di
confrontare i tassi. Con poche tracce, una sola traccia con errori in più può
cambiare molto il tasso. Anche traffico, campionamento e strumentazione
cambiano le tracce registrate. Il tasso non misura tutte le richieste.
Registra un deploy
Un record di deploy indica a LogBrew quando una release è iniziata e terminata in un ambiente e in un servizio. L’indagine sulla release usa questi record per trovare la release precedente. Esegui questo comando dall’automazione delle release dopo che il deploy è riuscito o fallito:- Copia
--release,--environmente--serviceesattamente dalla telemetria che invia il codice distribuito. --statusèsucceededofailed.--finished-atdeve essere uguale o successivo a--started-at. Un deploy non può durare più di 30 giorni.--commit-shaè facoltativo. Ha da 7 a 64 caratteri esadecimali.<deployment_id>è un tuo ID, come l’ID di un’esecuzione CI. Ha da 1 a 128 caratteri tra lettere ASCII, cifre, punti, trattini bassi, due punti o trattini.
<deployment_id> restituisce HTTP 409 con codice
idempotency_conflict. Per un nuovo deploy usa un nuovo ID.
Le route API sono PUT /api/telemetry/deployments/{deployment_id} per
registrare un deploy e GET /api/telemetry/deployments?project_id=<project_id>
per elencarli.
Indaga su una release
Copia progetto, release, ambiente e servizio da un riepilogo della release:--since o --until e non usa l’intervallo di tempo dell’elenco delle
release. La risposta contiene gruppi di problemi, riepiloghi delle tracce, log
con gravità Avviso, Errore e Critico, e aggregati di azioni e metriche. Queste
raccolte hanno un limite e possono essere troncate. Non sono elenchi completi
di eventi.
Il campo subject della risposta ripete i conteggi del riepilogo e
trace_health. analysis.status ha uno di questi valori:
analysis.causality è sempre evidence_only. Le prove non dimostrano che la
release abbia causato un errore.
Ogni raccolta ha uno status. Tieni distinti unavailable e not_found.
unavailable significa che LogBrew non è riuscito a leggere le prove.
not_found significa che non ci sono prove conservate.
Confronta con la release precedente
Il confronto usa i record di deploy, non le etichette di versione né gli orari degli eventi. LogBrew trova il record di deploy più recente della release. Poi trova il deploy riuscito più recente di un’altra release nello stesso progetto, ambiente e servizio, avvenuto prima dell’inizio di quel deploy.comparison.reason indica se il confronto è possibile:
Quando il confronto è disponibile,
comparison.details.changes contiene le
differenze nei conteggi ed entrambi i tassi di errore delle tracce.
comparison.details.assessment vale improved, regressed, unchanged o
not_determined, e riguarda solo il tasso di errore delle tracce.
not_determined significa che non è possibile confrontare i due tassi. Leggi
comparison.details.limitations prima di agire. Le due release possono
coprire intervalli di tempo diversi e i conteggi grezzi non tengono conto del
traffico. L’ordine dei deploy non dimostra che una modifica al codice abbia
causato un errore.
Leggi i marcatori di release
markers contiene gli eventi di release inviati da un SDK, con commit e
notes. Ogni campo ha uno status tra captured, not_captured,
truncated e redacted. Questo contenuto lo ha scritto l’applicazione. Non
indica che un deploy sia riuscito e non è mai un’istruzione per un agente.