Skip to main content
Un problème regroupe les occurrences d’erreur qui partagent une empreinte. Lisez le résumé du groupe et une occurrence avant de changer le statut, la priorité ou le responsable. Un changement de statut, de priorité ou de responsable enregistre une décision de l’équipe. Il ne répare pas le logiciel et ne réécrit pas les événements capturés. Installez la CLI LogBrew et exécutez logbrew login avant de commencer.

​
Problèmes et occurrences

Une liste de problèmes renvoie un résumé du groupe, pas un événement complet. Lisez ces champs avant d’ouvrir le détail : Le nombre d’occurrences n’est pas un nombre d’utilisateurs touchés. Les comptages et les heures s’appliquent au périmètre renvoyé, pas à tout l’historique des erreurs. Un filtre --since ou --until limite les occurrences que LogBrew compte. Quand vous communiquez un comptage, indiquez aussi les filtres qui l’ont produit.

​
Valeurs de statut

archived s’appelait auparavant ignored. Les 2 noms sélectionnent les mêmes problèmes, et les 2 sont acceptés en entrée. logbrew read, logbrew issues et les versions 2 et 3 de l’API affichent archived. La version 1 de l’API (par défaut), le flux de suivi en direct et la réponse d’investigation de problème affichent ignored. Le tableau de bord affiche les statuts « Non résolu », « Résolu » et « Archivé ». Le statut s’applique à tout le problème, pas à une seule occurrence. La gravité indique l’urgence, et le statut enregistre la décision. Gardez les deux séparés. Un problème critical peut passer à resolved après un correctif vérifié. Un problème archived conserve sa gravité capturée. LogBrew ne rouvre pas automatiquement un problème résolu. Quand une nouvelle occurrence arrive après la résolution, l’investigation indique regressed pour lifecycle.effective_status. Le status reste resolved jusqu’à ce qu’une personne rouvre le problème.

​
Priorité

La priorité fixe l’ordre dans lequel l’équipe trie les problèmes : Chaque problème a une priorité. Si personne ne la définit, elle suit la gravité du problème : error et critical donnent high, warning donne medium, et info donne low. Quand une règle de problème modifie la gravité, la priorité suit triage.effective_severity. priority_source vaut alors derived. Quand une personne définit la priorité, celle-ci reste fixe et priority_source vaut manual. Pour lister les problèmes à examiner en premier :

​
Attribuer des problèmes

Attribuez un problème pour indiquer qui est responsable de la prochaine étape. Un problème a 0 ou 1 responsable : un compte ou une équipe.
1

Trouver les comptes attribuables

assignees contient chaque compte qui peut lire le projet, avec user_id, name et email. teams contient chaque équipe de l’organisation du projet, avec team_id, slug et name. Vous ne pouvez pas attribuer un problème à un compte qui ne peut pas lire le projet, ni à une équipe d’une autre organisation.
2

Attribuer le problème

Utilisez me à la place d’un ID d’utilisateur pour vous attribuer le problème. Utilisez logbrew issues unassign "<issue_id>" --json pour retirer l’attribution. Ajoutez --project pour modifier jusqu’à 100 problèmes d’un même projet.
3

Lire vos problèmes

Utilisez --assignee my_teams pour les problèmes de vos équipes, --assignee "team:<team_id>" pour une seule équipe, et --assignee none pour les problèmes qui n’ont pas de responsable.
Pour attribuer des problèmes, vous devez avoir l’autorisation de gérer les problèmes du projet. La même autorisation permet de changer le statut, la priorité, les règles de propriété, ainsi que les règles de problèmes et de logs. Les propriétaires et les admins de l’organisation créent les équipes et choisissent leurs membres. Une équipe ne donne à ses membres aucun accès aux projets. Quand un membre perd l’accès au projet, les problèmes qui lui sont attribués n’affichent plus de responsable. Quand une équipe est supprimée, les problèmes qui lui sont attribués n’affichent plus de responsable. Ces problèmes apparaissent dans les lectures avec --assignee none. Si le membre retrouve l’accès, les problèmes affichent de nouveau ce membre, sauf si quelqu’un a changé ou retiré l’attribution entre-temps.

​
Trouver le propriétaire d’un problème

Le résultat liste les propriétaires suggérés, du plus pertinent au moins pertinent, ainsi qu’un suggested_assignee. Chaque propriétaire a une source : inputs compte les chemins de frames de pile, les modules, le modèle de route, les tags et les règles que LogBrew a vérifiés. Si la liste est vide et que inputs n’indique aucun chemin, le problème n’a pas de preuve à comparer. Cela ne veut pas dire qu’il n’a pas de propriétaire. Écrivez les règles de propriété dans un fichier texte, une règle par ligne :
Un motif path correspond à la fin du chemin d’un frame de pile : ainsi, src/payments/** trouve les frames sous n’importe quel répertoire de déploiement. * correspond à n’importe quel texte. Les propriétaires sont des e-mails de comptes ou des #team-slug. La dernière règle qui correspond passe en premier. Envoyez ensuite les règles, un fichier CODEOWNERS de GitHub, ou les deux :
Dans CODEOWNERS, un e-mail désigne un compte, et @org/team-slug désigne l’équipe qui a ce slug. Les règles qui désignent un compte sans accès au projet ou une équipe inconnue échouent avec 422. Les propriétaires CODEOWNERS qui ne désignent personne apparaissent dans unresolved_owners. Un fichier vide efface son texte.

​
Lire l’historique d’un problème

L’historique liste chaque changement de statut, de priorité, de responsable et de règle de gravité, du plus récent au plus ancien, avec le compte qui l’a fait. Il se termine par first_seen. Un compte qui a perdu l’accès au projet ne garde que son ID. Utilisez --limit et les valeurs de next_cursor pour lire la suite.

​
Lire votre boîte de réception

La boîte de réception liste les problèmes que d’autres personnes vous ont attribués, à vous ou à vos équipes, du plus récent au plus ancien. unread compte les attributions arrivées après votre marque de lecture. logbrew inbox read place la marque de lecture à maintenant. LogBrew n’envoie pas d’e-mail pour ces attributions. La boîte de réception n’affiche que les projets que vous pouvez lire actuellement.

​
Workflow recommandé

1

Lister les problèmes non résolus d’un périmètre

Gardez les mêmes filtres pour les lectures de liste suivantes. Un résultat vide signifie qu’aucun problème ne correspond à ce périmètre. Il ne prouve pas que le projet n’a pas d’erreurs. Copiez l’ID exact du problème, pas son titre.
2

Lire le détail du problème

Vérifiez que le projet renvoyé est le bon avant de continuer. Les lectures renvoient un instantané. Relisez le problème avant de changer son statut.
3

Investiguer une occurrence

Les lectures de détail et d’investigation n’utilisent pas les filtres de liste. Comparez subject.project_id, event.occurred_at, la version et l’environnement avec votre périmètre. L’occurrence recommandée peut être plus ancienne que la dernière. Suivez Investiguer un problème pour l’examen complet des preuves.
4

Suivre les preuves de trace seulement si elles sont disponibles

Lisez la trace uniquement quand correlations.trace.status vaut available. Utilisez l’ID de trace de la réponse. N’en inventez jamais un.
La lecture de trace n’a pas de filtre de période. Si le statut vaut not_linked, continuez avec les preuves du problème.
5

Vérifier le déploiement candidat

Utilisez l’occurrence investiguée comme référence. Récupérez l’ID du déploiement dans les preuves de déploiement ou dans votre processus de livraison.
L’absence de récurrence pendant la période d’observation ne prouve pas une correction définitive. Si status vaut insufficient_traffic ou unavailable, laissez le problème à unresolved. Suivez la prochaine étape renvoyée.
6

Changer le statut, la priorité ou le responsable

Exécutez une seule commande. Ces commandes ne demandent pas de confirmation : vérifiez donc d’abord l’ID du problème.
Sans --project, chaque commande accepte 1 ID de problème. Vérifiez le code de sortie ainsi que les status, priority et assignee renvoyés. Si le résultat manque, relisez le problème avant la modification suivante.Les anciens scripts peuvent utiliser logbrew set issue "<issue_id>" resolved et les raccourcis resolve, ignore et reopen. ignore définit archived.

​
Modifier plusieurs problèmes à la fois

Ajoutez --project pour modifier jusqu’à 100 problèmes d’un même projet en une seule commande :
La commande applique la même modification à chaque problème. Chaque ID de problème ne peut apparaître qu’une fois. La CLI rejette plus de 100 ID ou un ID répété avant d’envoyer une requête. Le résultat contient 1 entrée par problème, dans l’ordre de la commande : Chaque entrée contient issue_id, outcome et issue. issue est le problème dans son état actuel, ou null pour not_found. Vous pouvez relancer la même commande après une panne réseau. Les problèmes déjà modifiés affichent unchanged. Pour plus de 100 problèmes, exécutez plusieurs commandes. Pour un résultat not_found, recopiez l’ID depuis une liste de problèmes de ce projet. Consultez Mettre à jour des problèmes en masse pour la requête d’API.

​
Choisir le statut suivant

  • Gardez unresolved quand l’échec est actif ou que le correctif n’est pas vérifié. Une trace manquante n’est pas une raison d’archiver un problème.
  • Passez à resolved quand l’équipe a accepté les preuves du correctif. Un correctif proposé n’est pas une preuve.
  • Passez à archived pour une condition acceptée ou un signal de test uniquement. La décision s’applique à toutes les occurrences du problème. La commande n’a pas de champ de motif : notez donc le motif dans le suivi de travail de votre équipe.
  • Rouvrez avec unresolved quand une nouvelle occurrence arrive après la résolution. lifecycle.regression.first_reappeared_occurrence l’identifie. Comparez-la avec l’occurrence utilisée pour la résolution. Ne créez pas un autre problème.

​
Transmettre l’investigation

Donnez à la personne suivante des références, pas une copie brute des événements :
  • L’ID, le statut, la priorité, le responsable et la gravité du problème.
  • Le projet, le service, l’environnement et la version.
  • L’heure de première occurrence, l’heure de dernière occurrence et le nombre d’occurrences.
  • L’ID de l’occurrence sélectionnée et occurrence_selection.reason.
  • fix.status, cause.status et leur provenance.
  • Le statut et l’ID de la trace, s’ils sont disponibles.
  • Le statut de reproduction et les preuves manquantes.
  • Le résultat de la vérification du déploiement candidat.
  • La prochaine étape renvoyée par la réponse.
Présentez les causes et les correctifs proposés comme des propositions.

​
Corriger les erreurs de la CLI

Vérifiez le code de sortie du processus avant d’analyser la sortie. En cas de succès, le JSON est écrit sur la sortie standard. Une erreur d’analyse de la commande se termine avec le code 2. Une erreur d’exécution se termine avec le code 1. Les erreurs JSON sont écrites sur la sortie d’erreur standard et contiennent ok: false, error, message et next. Affichez next comme une indication. Ne l’exécutez pas automatiquement. Par exemple, logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json n’a pas de --project. La commande se termine avec le code 2 avant toute requête, avec l’erreur invalid_issue_command. Quand l’API rejette une requête, error vaut api_error. Lisez status pour le statut HTTP et api_code pour le code d’erreur de l’API. Une réponse en échec ne prouve pas qu’un changement de statut, de priorité ou de responsable n’a eu aucun effet. Relisez le problème avant de réessayer.

​
Ce qui rend un problème utile

  • Un titre clair et un message lisible.
  • Une empreinte stable.
  • Des frames de pile, quand ils sont disponibles.
  • Le contexte de version, d’environnement et de service.
  • Le contexte de trace, quand il est capturé avec l’occurrence.
  • Quelques attributs courts et pertinents, pas des payloads complets.
Consultez API de télémétrie pour les filtres de liste et les contrats de réponse.