Skip to main content
Un problema raggruppa le occorrenze di errore che condividono un fingerprint. Leggi il riepilogo del gruppo e un’occorrenza prima di cambiare stato, priorità o assegnatario. Un cambio di stato, priorità o assegnatario registra una decisione del team. Non ripara il software e non riscrive gli eventi acquisiti. Prima di iniziare, installa la CLI di LogBrew ed esegui logbrew login.

​
Problemi e occorrenze

Un elenco di problemi restituisce un riepilogo del gruppo, non un evento completo. Leggi questi campi prima di aprire il dettaglio: Il numero di occorrenze non è un numero di utenti coinvolti. Conteggi e orari si riferiscono all’ambito restituito, non all’intera cronologia dell’errore. Un filtro --since o --until limita le occorrenze che LogBrew conta. Quando riporti un conteggio, riporta anche i filtri che lo hanno prodotto.

​
Valori di stato

archived in precedenza si chiamava ignored. I due nomi selezionano gli stessi problemi, e LogBrew li accetta entrambi in input. logbrew read, logbrew issues e le versioni 2 e 3 dell’API mostrano archived. La versione 1 dell’API (quella predefinita), il flusso dell’osservazione in tempo reale e la risposta dell’indagine sul problema mostrano ignored. La dashboard mostra gli stati come Da risolvere, Risolto e Archiviato. Lo stato vale per l’intero problema, non per una singola occorrenza. La gravità indica l’urgenza, lo stato registra la decisione. Tieni separati i due concetti. Un problema critical può diventare resolved dopo una correzione verificata. Un problema archived mantiene la gravità acquisita. LogBrew non riapre automaticamente un problema risolto. Quando arriva una nuova occorrenza dopo la risoluzione, l’indagine riporta lifecycle.effective_status come regressed. Lo status resta resolved finché una persona non riapre il problema.

​
Priorità

La priorità stabilisce l’ordine in cui il team fa il triage dei problemi: Ogni problema ha una priorità. Se nessuno la imposta, segue la gravità del problema: error e critical sono high, warning è medium e info è low. Quando una regola dei problemi cambia la gravità, la priorità segue triage.effective_severity. In questo caso priority_source è derived. Quando una persona imposta la priorità, questa resta fissa e priority_source è manual. Per elencare i problemi da esaminare per primi:

​
Assegna i problemi

Assegna un problema per indicare chi è responsabile del passo successivo. Un problema ha 0 o 1 assegnatario: un account o un team.
1

Trova chi può essere assegnatario

assignees contiene ogni account che può leggere il progetto, con user_id, name ed email. teams contiene ogni team dell’organizzazione del progetto, con team_id, slug e name. Non puoi assegnare un account che non può leggere il progetto, né un team di un’altra organizzazione.
2

Assegna il problema

Usa me al posto dell’ID utente per assegnare il problema a te. Usa logbrew issues unassign "<issue_id>" --json per rimuovere l’assegnatario. Aggiungi --project per modificare fino a 100 problemi di un progetto.
3

Leggi i tuoi problemi

Usa --assignee my_teams per i problemi dei tuoi team, --assignee "team:<team_id>" per un solo team e --assignee none per i problemi senza assegnatario.
Per assegnare problemi ti serve il permesso di gestire i problemi del progetto. Lo stesso permesso ti consente di cambiare stato, priorità, regole dei referenti e regole di problemi e log. I proprietari e gli amministratori dell’organizzazione creano i team e ne scelgono i membri. Un team non dà ai suoi membri alcun accesso ai progetti. Quando un membro perde l’accesso al progetto, i problemi assegnati a quel membro risultano senza assegnatario. Quando un team viene eliminato, i problemi assegnati al team risultano senza assegnatario. Questi problemi compaiono nelle letture con --assignee none. Se il membro riottiene l’accesso, i problemi mostrano di nuovo quel membro, a meno che nel frattempo qualcuno non abbia cambiato o rimosso l’assegnatario.

​
Trova il referente di un problema

Il risultato elenca i referenti suggeriti, dal più probabile, e un suggested_assignee. Ogni referente ha un source: inputs conta i percorsi degli stack frame, i moduli, il modello di route, i tag e le regole che LogBrew ha controllato. Se l’elenco è vuoto e inputs non mostra percorsi, al problema mancano le prove da confrontare: non significa che non abbia un referente. Scrivi le regole dei referenti in un file di testo, una regola per riga:
Un pattern path corrisponde alla parte finale del percorso di uno stack frame, quindi src/payments/** trova i frame sotto qualsiasi directory di deploy. * corrisponde a qualsiasi testo. I referenti sono email di account o #team-slug. L’ultima regola che corrisponde viene prima. Poi invia le regole, un file CODEOWNERS di GitHub o entrambi:
In CODEOWNERS, un’email indica un account e @org/team-slug indica il team con quello slug. Le regole che indicano un account senza accesso al progetto o un team sconosciuto non riescono con 422. I referenti di CODEOWNERS che non corrispondono a nessuno compaiono in unresolved_owners. Un file vuoto cancella il testo corrispondente.

​
Leggi la cronologia del problema

La cronologia elenca ogni modifica di stato, priorità, assegnatario e regola di gravità, dalla più recente, con l’account che l’ha fatta. Termina con first_seen. Un account che ha perso l’accesso al progetto conserva solo il suo ID. Usa --limit e i valori di next_cursor per leggere altre voci.

​
Leggi la tua inbox

L’inbox elenca i problemi che altre persone hanno assegnato a te o ai tuoi team, dal più recente. unread conta le assegnazioni successive al tuo segno di lettura. logbrew inbox read sposta il segno di lettura ad adesso. LogBrew non invia email per queste assegnazioni. L’inbox mostra solo i progetti che puoi leggere in questo momento.

​
Flusso di lavoro consigliato

1

Elenca i problemi da risolvere in un ambito

Mantieni gli stessi filtri nelle letture successive dell’elenco. Un risultato vuoto significa che nessun problema corrisponde a questo ambito. Non dimostra che il progetto non abbia errori. Copia l’ID esatto del problema, non il titolo.
2

Leggi il dettaglio del problema

Prima di continuare, verifica che il progetto restituito sia quello giusto. Le letture restituiscono un’istantanea. Rileggi il problema prima di cambiarne lo stato.
3

Indaga su un'occorrenza

Le letture del dettaglio e dell’indagine non usano i filtri dell’elenco. Confronta subject.project_id, event.occurred_at, release e ambiente con il tuo ambito. L’occorrenza consigliata può essere meno recente dell’ultima. Per l’esame completo delle prove, segui Indaga su un problema.
4

Segui le prove di traccia solo se disponibili

Leggi la traccia solo quando correlations.trace.status è available. Usa l’ID traccia della risposta. Non inventarne mai uno.
La lettura della traccia non ha un filtro temporale. Se lo stato è not_linked, continua con le prove del problema.
5

Verifica il deploy candidato

Usa l’occorrenza esaminata come riferimento. Ricava l’ID del deploy dalle prove del deploy o dal tuo processo di release.
L’assenza di ricorrenze nell’intervallo di osservazione non dimostra una correzione definitiva. Se status è insufficient_traffic o unavailable, lascia il problema unresolved. Segui la prossima azione restituita.
6

Cambia stato, priorità o assegnatario

Esegui un solo comando. Questi comandi non chiedono conferma, quindi controlla prima l’ID del problema.
Senza --project, ogni comando accetta 1 ID di problema. Controlla il codice di uscita e i valori restituiti di status, priority e assignee. Se il risultato manca, rileggi il problema prima della modifica successiva.Gli script meno recenti possono usare logbrew set issue "<issue_id>" resolved e le scorciatoie resolve, ignore e reopen. ignore imposta archived.

​
Modifica molti problemi insieme

Aggiungi --project per modificare fino a 100 problemi di un progetto con un solo comando:
Il comando applica la stessa modifica a ogni problema. Ogni ID di problema può comparire una sola volta. La CLI rifiuta più di 100 ID o un ID ripetuto prima di inviare una richiesta. Il risultato ha 1 voce per ogni problema, nell’ordine del comando: Ogni voce ha issue_id, outcome e issue. issue è il problema attuale, oppure null per not_found. Dopo un errore di rete puoi eseguire di nuovo lo stesso comando. I problemi già modificati mostrano unchanged. Per più di 100 problemi, esegui più comandi. Per un risultato not_found, copia di nuovo l’ID da un elenco di problemi di quel progetto. Per la richiesta API, consulta Aggiorna più problemi insieme.

​
Scegli lo stato successivo

  • Lascialo unresolved quando l’errore è attivo o la correzione non è verificata. Una traccia mancante non è un motivo per archiviare un problema.
  • Imposta resolved dopo che il team ha accettato le prove della correzione. Una correzione proposta non è una prova.
  • Imposta archived per una condizione accettata o per un segnale solo di test. La decisione vale per ogni occorrenza del problema. Il comando non ha un campo per il motivo, quindi annota il motivo nel registro di lavoro del tuo team.
  • Riapri con unresolved quando arriva una nuova occorrenza dopo la risoluzione. lifecycle.regression.first_reappeared_occurrence la identifica. Confrontala con l’occorrenza usata per la risoluzione. Non creare un problema diverso.

​
Passa l’indagine a un’altra persona

Dai alla persona successiva dei riferimenti, non un dump grezzo dell’evento:
  • ID, stato, priorità, assegnatario e gravità del problema.
  • Progetto, servizio, ambiente e release.
  • Ora della prima occorrenza, ora dell’ultima occorrenza e numero di occorrenze.
  • ID dell’occorrenza selezionata e occurrence_selection.reason.
  • fix.status, cause.status e la loro provenance.
  • Stato e ID della traccia, se disponibili.
  • Stato della riproduzione e prove mancanti.
  • Risultato della verifica del deploy candidato.
  • La prossima azione restituita dalla risposta.
Contrassegna come «proposta» ogni causa o correzione proposta.

​
Risolvi gli errori della CLI

Controlla il codice di uscita del processo prima di analizzare l’output. In caso di successo, il JSON va sullo standard output. Un errore di parsing termina con il codice 2. Un errore di runtime termina con il codice 1. Gli errori JSON vanno sullo standard error e contengono ok: false, error, message e next. Mostra next come indicazione. Non eseguirlo automaticamente. Ad esempio, logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json non ha --project. Termina con il codice 2 prima di inviare una richiesta, con l’errore invalid_issue_command. Quando l’API rifiuta una richiesta, error è api_error. Leggi status per lo stato HTTP e api_code per il codice di errore dell’API. Una risposta di errore non dimostra che il cambio di stato, priorità o assegnatario non abbia avuto effetto. Rileggi il problema prima di riprovare.

​
Cosa rende utile un problema

  • Un titolo chiaro e un messaggio leggibile.
  • Un fingerprint stabile.
  • Frame dello stack, quando disponibili.
  • Contesto di release, ambiente e servizio.
  • Contesto di traccia, quando acquisito con l’occorrenza.
  • Attributi brevi e pertinenti, non dump completi del payload.
Per i filtri degli elenchi e i contratti delle risposte, consulta il riferimento dell’API di telemetria.