https://api.logbrew.co. Gli
SDK pubblici inviano i loro batch gestiti a POST /v1/events. I client
nativi personalizzati inviano envelope nativi a POST /api/telemetry/ingest.
Entrambe le route di ingestione richiedono un token bearer di ingestione
limitato al progetto.
Le letture e le modifiche di proprietà dell’account usano un token bearer
dell’account. Non usare mai un token bearer dell’account o una sessione del
browser nella configurazione dell’SDK o dell’ingestione. Non inviare mai un
token bearer di ingestione a una route di lettura.
Invia una richiesta ben delimitata
Usa questa checklist prima che un client invii una richiesta:- Scegli la route e il metodo HTTP dalla tabella degli endpoint.
- Usa il token bearer corretto: un token bearer di ingestione per l’ingestione, un token bearer dell’account per tutto il resto.
- Seleziona l’ambito di progetto supportato dalla route. Non allargare l’ambito dopo una risposta vuota.
- Aggiungi solo le chiavi di query che la route accetta. Consulta Filtri di query dell’API di telemetria.
- Invia
Content-Type: application/jsonquando la route ha un corpo JSON. - Leggi lo stato HTTP e il corpo della risposta prima di riprovare.
- Tieni token bearer, ticket di connessione e corpi completi delle risposte fuori dai log e dai prompt degli agenti.
Endpoint
Ingestione
Lascia che sia l’SDK a costruire i batch per
/v1/events. Non costruirli a
mano. Per l’envelope nativo, consulta
Invia telemetria con l’SDK.
Letture della telemetria
Deploy
Registra un deploy dalla tua automazione delle release dopo che è riuscito o
non è riuscito. Il corpo del
PUT contiene project_id, release,
environment, service_name, status (succeeded o failed),
started_at, finished_at e un commit_sha facoltativo. Usa gli stessi
valori di release, environment e service_name che invia il tuo SDK.
L’account deve possedere il progetto.
deployment_id è un tuo ID per il deploy. Un nuovo tentativo con lo stesso ID
e lo stesso corpo restituisce il deploy salvato. Lo stesso ID con un corpo
diverso non riesce con 409 e idempotency_conflict. Usa un nuovo ID per un
deploy diverso.
Indagini
Ogni route di indagine restituisce un pacchetto limitato di prove per un singolo elemento. Il comandologbrew explain della CLI
legge queste route e convalida la risposta.
Analisi di prodotto
Le route di analisi
POST accettano un corpo JSON, non chiavi di query.
Consulta Analisi di prodotto.
Flusso in tempo reale
Account e accesso
Le route per utilizzo, quota, abbonamento e disconnessione sono nell’API dell’account.Codici di stato di successo
Una risposta
200 non dimostra che le prove siano complete. Leggi i campi di
copertura, troncamento e stato nella risposta.
Filtri di query e paginazione
Ogni route di lettura accetta le proprie chiavi di query. Gli alias comodi comeproject, trace e user non sono chiavi di query. Le route di elenco
restituiscono per impostazione predefinita un array semplice e, con
pagination=cursor, un envelope con cursore. L’elenco dei deploy restituisce
sempre un oggetto pagina. Consulta
Filtri di query dell’API di telemetria.
Risposte ed errori
- Formati delle risposte di telemetria mostra un esempio per ogni famiglia di risposte.
- Errori API elenca i codici di errore e le azioni di ripristino.
code prima del messaggio per le persone. Usa next_action per il
comportamento del programma e next per le indicazioni alle persone. Non
analizzare la formulazione di error o next.
Aggiorna i problemi
Queste richieste usano un token bearer dell’account. È volutamente diverso daLOGBREW_INGEST_BEARER. L’account deve avere il permesso di gestire i
problemi nel progetto del problema. In caso contrario, la richiesta non riesce
con 403 e forbidden. Lo stesso permesso copre le modifiche di stato,
priorità e assegnatario, e le regole per problemi e log.
Ogni richiesta imposta 1 o più di questi campi:
Una richiesta senza nessuno di questi campi non riesce con
422 e
validation_failed.
Un problema ha 0 o 1 assegnatario: un account o un team. Un account deve poter
leggere il progetto e un team deve appartenere all’organizzazione del
progetto. In caso contrario, la richiesta non riesce con 422 e
validation_failed e LogBrew non modifica nulla. Ottieni gli account che puoi
assegnare da Elenca gli assegnatari. Anche qualsiasi altro
valore di assignee non riesce con 422 e validation_failed.
Una priorità impostata da te resta fissa. Senza una priorità impostata da te,
la priorità segue la gravità del problema: error e critical corrispondono
a high, warning a medium e info a low.
Un campo che ha già il valore richiesto non cambia. Puoi inviare di nuovo la
stessa richiesta dopo un timeout. Un timeout non dimostra che la modifica non
sia avvenuta. Leggi di nuovo il problema prima di inviare una modifica
diversa.
Aggiorna un problema
Aggiungiresponse_version=4 per ricevere nella risposta archived, la
priorità e l’assegnatario. Nella versione 4, assignee vale
{ "type": "user", "user_id", "name", "email" },
{ "type": "team", "team_id", "slug", "name" } oppure null. La versione 3
mostra un team assegnatario come null.
Aggiorna più problemi insieme
Inviaproject_id e da 1 a 100 ID di problemi diversi di quel progetto:
project_id e results, con 1 risultato per ogni ID problema, nell’ordine
della richiesta. Ogni risultato contiene issue_id, outcome e issue.
issue è il problema attuale nella versione 3 della risposta, oppure null
per not_found. Aggiungi "response_version": 2 al corpo per ricevere ogni
problema nella versione 4 della risposta.
Un elenco vuoto, più di 100 ID o un ID ripetuto non riescono con
422 e
validation_failed. Dividi un insieme più grande in più richieste. Se
l’account non può leggere il progetto, la richiesta non riesce con 404 e
not_found.
Elenca gli assegnatari
Invia l’ID del progetto per ottenere tutti gli account a cui puoi assegnare problemi in quel progetto:user_id, name e email. name vale null quando l’account non ha un
nome. Aggiungi response_version=2 per ricevere anche teams: ogni team
dell’organizzazione del progetto, con team_id, slug e name. Consulta la
risposta della lista degli assegnatari.
Qualsiasi account che può leggere il progetto può ottenere questo elenco. Se
l’account non può leggere il progetto, la richiesta non riesce con 404 e
not_found.
Quando un membro perde l’accesso al progetto, i problemi assegnati a quel
membro non mostrano alcun assegnatario. Se il membro ottiene di nuovo
l’accesso, i problemi mostrano di nuovo quel membro, a meno che nel frattempo
qualcuno non abbia cambiato o rimosso l’assegnatario.
Regole dei referenti e referenti suggeriti
GET /api/telemetry/issues/ownership?project_id=<project-uuid> restituisce
rules, codeowners, updated_at e unresolved_owners. Qualsiasi account
che può leggere il progetto può leggerli. PUT con project_id e rules,
codeowners o entrambi sostituisce quel testo e richiede il permesso di
gestire i problemi. Un campo che non invii mantiene il suo testo, e una
stringa vuota lo cancella. Ogni testo è di massimo 128 KiB. Un testo non
valido non riesce con 422 e indica la riga.
GET /api/telemetry/issues/{issue_id}/owners?response_version=2 restituisce
suggested_assignee, owners e inputs. Ogni referente ha type (user
o team), source (ownership_rule, codeowners o recent_activity),
rule, line e matched. La versione 1, quella predefinita, elenca solo gli
account.
Cronologia del problema
GET /api/telemetry/issues/{issue_id}/activity?response_version=2 restituisce
activity, dalla voce più recente, e next_cursor. Ogni voce ha type
(status, priority, assigned, unassigned, severity_rule o
first_seen), value, actor_id, actor, assignee_id, assignee,
team e at. limit va da 1 a 200, 50 per impostazione predefinita. Invia
cursor_time e cursor_id presi da next_cursor per la pagina successiva.
Notifiche
GET /api/telemetry/issues/notifications restituisce notifications,
unread, read_at e next_cursor. Ogni notifica è l’assegnazione di un
problema a te o al tuo team da parte di un altro account. POST /api/telemetry/issues/notifications/read con un oggetto JSON vuoto, oppure
con read_at, sposta il tuo segno di lettura. Il segno non torna mai
indietro.
Imposta le regole per problemi e log
Una regola cambia il modo in cui LogBrew mostra i segnali corrispondenti. Non elimina dati. Laseverity acquisita resta invariata e la risposta mostra la
regola in triage.
severity vale info, warning, error, critical o source. source
rimuove la sostituzione e mostra di nuovo la gravità acquisita. Per una regola
sui log, ignored: true nasconde i log corrispondenti dall’elenco predefinito
dei log. Leggili con status=ignored o status=all. La regola si applica ai
segnali corrispondenti conservati e futuri. Un altro valore non riesce con
422 e validation_failed.