Triage automatisé des erreurs, terminé avant le standup

Zero est un agent IA DevOps qui automatise le triage quotidien des erreurs. Chaque matin, il récupère les erreurs non résolues depuis Sentry et Axiom, les déduplique entre les deux sources et ouvre des issues GitHub assignées avec les stack traces complètes avant le standup, faisant gagner aux ingénieurs 20 à 30 minutes de revue manuelle.

Zero se connecte à :SentryAxiomGitHub

Ce que Zero produit : un rapport quotidien de triage des erreurs

Explorez un exemple de rapport de triage des erreurs généré par IA, avec incidents priorisés, déduplication inter-sources, issues GitHub assignées, gravité, volume et temps gagné. Les données sont illustratives ; le format du rapport est une véritable sortie que Zero peut générer à partir de Sentry et Axiom.

Zero · Rapport d'automatisationDonnées d'exemple

Résumé de l'agent

Zero a inspecté 17 erreurs brutes provenant de Sentry et Axiom, les a dédupliquées en 13 causes racines, a créé 6 issues GitHub assignées et a acheminé 2 signaux à surveiller vers #dev.

Erreurs brutes inspectées
1712 Sentry · 5 Axiom
Causes racines uniques
13après déduplication
Issues GitHub créées
6toutes assignées
Ouvrir le rapport quotidien complet de triage des erreurs

Qu'est-ce que le triage des erreurs ?

Le triage des erreurs est le processus consistant à regrouper, prioriser et assigner les erreurs de production afin que les ingénieurs sachent quoi corriger en premier. Zero agit comme un agent IA SRE à travers Sentry, Axiom et GitHub : il déduplique les erreurs, applique des seuils, joint les stack traces et assigne les propriétaires du code. Le résultat est une automatisation quotidienne et cohérente du triage des erreurs, avec moins de fatigue liée aux alertes.

Pourquoi le triage manuel des erreurs crée une fatigue liée aux alertes

Chaque matin, un ingénieur doit ouvrir Sentry, parcourir les alertes Sentry non résolues, croiser avec Axiom, identifier ce qui est nouveau ou dupliqué, décider ce qui est sérieux, ouvrir des issues GitHub et trouver le bon responsable. Cette première passe répétitive coûte 20 à 30 minutes de temps d'ingénierie concentré et crée une fatigue liée aux alertes avant même que le vrai travail ne commence. Zero s'exécute à 8h45 et termine le même triage avant que quiconque n'ouvre son ordinateur.

Comment Zero automatise le triage quotidien des erreurs

Étape 1 : Connectez vos outils

Sentry
Sentry
Requis
L'intégration Sentry de Zero interroge les erreurs de production non résolues, les stack traces, le nombre d'événements et les étiquettes d'environnement.
Connecter
GitHub
GitHub
Requis
L'intégration Sentry-GitHub crée des issues structurées avec tous les détails de l'erreur et les assigne aux propriétaires du code.
Connecter
Axiom
Axiom
Optionnel
Zero interroge Axiom pour les logs d'erreurs afin de les recouper et de les dédupliquer par rapport aux constats Sentry. Optionnel mais recommandé.
Connecter

Étape 2 : Demandez à Zero

@Zero chaque jour de semaine à 8h45, récupère les erreurs non résolues de Sentry et Axiom pour les dernières 24 heures. Déduplique entre les sources. Pour tout ce qui compte 5 occurrences ou plus, ouvre une issue GitHub dans vm0-ai/vm0 avec la stack trace complète et assigne-la au propriétaire du code concerné.
Un exemple d'exécution du même workflow, étape par étape : récupérer et classer les issues Sentry, signaler les régressions de déploiement, générer les graphiques, publier le rapport et le poster sur Slack.
Zero récupère les erreurs non résolues de Sentry et Axiom
Zero interroge à la fois Sentry et Axiom pour les erreurs non résolues dans la fenêtre temporelle que vous définissez, puis applique votre seuil d'occurrences afin de filtrer le bruit à faible signal et de ne laisser passer que les erreurs qui se produisent à grande échelle.
Les erreurs en doublon sont fusionnées entre Sentry et Axiom
La même erreur apparaît souvent à la fois dans Sentry et Axiom avec un formatage différent. Zero les déduplique en un seul enregistrement combinant les données des deux sources, pour que vous ne triiez chaque véritable problème qu'une seule fois.
Les issues GitHub sont créées et assignées aux propriétaires du code
Pour chaque erreur unique et qualifiée, Zero ouvre une issue GitHub structurée avec la stack trace complète, le nombre d'occurrences et les horodatages de première et dernière apparition, puis l'assigne à l'ingénieur qui possède cette partie du code — le passage de Sentry à GitHub, automatisé de bout en bout.

Étape 3 : Allez plus loin

Ajuster le seuil
Modifiez le filtre d'occurrences pour réduire le bruit ou capturer plus d'erreurs.
@Zero mets à jour le calendrier de triage quotidien pour ne créer d'issues que pour les erreurs comptant 10 occurrences ou plus. Pour tout ce qui est en dessous, publie simplement un résumé dans #dev.
Ajouter à votre brief du matin
Intégrez le triage des erreurs au brief de santé produit que votre équipe lit déjà.
@Zero inclus le résultat du triage des erreurs du jour dans le brief de santé produit de 9h que tu publies dans #standup.
Vérification de sécurité post-déploiement
Lancez le triage juste après un déploiement en production pour que les régressions apparaissent en quelques minutes, et non le lendemain matin.
@Zero chaque fois qu'une PR est fusionnée dans main sur vm0-ai/vm0, attends 15 minutes puis lance une vérification Sentry des nouvelles erreurs.

Intégrations Sentry, GitHub et Axiom pour le tri des erreurs

Ce workflow est une intégration Sentry-GitHub avec un agent au milieu : Zero lit dans Sentry, recoupe la même fenêtre temporelle dans Axiom et écrit dans GitHub. Chaque connecteur est autorisé séparément et limité à ce que le workflow utilise réellement, si bien qu'un accès en lecture à vos données d'erreurs n'implique jamais un accès en écriture à vos dépôts.

Sentry

Intégration Sentry : les erreurs que Zero lit

Requis

Zero interroge l'API issues de Sentry pour les erreurs non résolues des environnements que vous désignez, triées par fréquence. Pour chacune, il lit le titre et le culprit, le nombre d'événements et d'utilisateurs touchés, le niveau ainsi que les horodatages de première et de dernière occurrence, puis récupère l'événement le plus récent pour obtenir la stack trace complète et ses tags de release et d'environnement. Cela couvre ce dont la décision de tri a besoin : ce qui a cassé, à quelle fréquence, où et depuis quand. Dans ce workflow, l'intégration Sentry est en lecture seule : Zero ne résout, ne fusionne et ne réaffecte jamais vos issues Sentry, et l'enregistrement qu'il écrit part dans GitHub.

GitHub

Intégration GitHub : les issues que Zero crée

Requis

Chaque erreur qui dépasse votre seuil devient une issue GitHub dans le dépôt que vous indiquez à Zero. L'issue contient le titre de l'erreur, la stack trace, le nombre d'occurrences et d'utilisateurs touchés, les horodatages de première et de dernière occurrence, ainsi qu'un lien vers l'issue Sentry pour garder les données d'origine à un clic. Zero applique les labels que vous définissez et assigne le code owner des fichiers cités dans la stack trace. L'accès en écriture se limite aux dépôts que vous autorisez, et créer des issues est tout ce qu'il fait : aucun commit, aucune pull request, aucun réglage de dépôt.

Axiom

Intégration Axiom : les logs Axiom que Zero recoupe

Optionnel

Axiom est optionnel et se justifie par la déduplication. Zero exécute une requête APL sur les datasets de votre choix, bornée à la même fenêtre temporelle que la lecture Sentry, et compare ces logs Axiom aux signatures d'erreur déjà collectées. Cela rattrape le cas où une même panne apparaît deux fois sous des formats différents, et cela ajoute le contexte au niveau de la requête autour de la panne, que l'événement Sentry seul ne transporte pas. Sans Axiom, le workflow tourne quand même de bout en bout et la déduplication s'appuie alors sur les seules données Sentry.

Zero vs. triage manuel vs. règles d'alerte Sentry

Le triage quotidien des erreurs est la première couche de la réponse aux incidents automatisée. Les équipes automatisent le passage de Sentry à GitHub avec Zero, en réalisant la première passe répétitive avant qu'un problème ne nécessite une gestion d'incidents par IA plus large.

Triage manuel

Un ingénieur passe en revue Sentry et Axiom, identifie les doublons, décide de la gravité, ouvre les issues et trouve un responsable. C'est flexible, mais cela répète les mêmes 20 à 30 minutes de travail chaque matin.

Règles d'alerte Sentry

Les règles notifient l'équipe lorsqu'un seuil est franchi. Elles sont utiles pour la détection, mais l'équipe doit encore corréler les logs, dédupliquer les erreurs, créer les issues GitHub et assigner les responsables.

L'automatisation du workflow Sentry par Zero

Zero exécute l'automatisation Sentry de bout en bout : requête, déduplication inter-sources, application de seuils, création d'issues, ajout des stack traces et assignation des propriétaires du code. Les exécutions à la demande et post-déploiement utilisent le même workflow.

Conseils pour de meilleurs résultats

Définissez un seuil d'occurrences pour garder le nombre d'issues gérable. 5 et plus est un bon point de départ ; ajustez selon votre volume.
Restreignez la requête de Zero à la production à l'aide des environnements ou des étiquettes de projet Sentry, pour que les erreurs de staging n'atteignent jamais la file de triage.
Enchaînez le triage quotidien avec des vérifications post-déploiement pour transformer une routine en réponse aux incidents automatisée et légère, et associez-le au brief de santé produit de 9h00 pour que l'équipe voie les erreurs et l'état du système au même endroit.

Questions fréquentes

Comment trier les erreurs Sentry et les transformer en issues GitHub ?

Pour créer automatiquement des issues GitHub à partir de Sentry, connectez Sentry et GitHub à Zero, puis donnez-lui un calendrier ou un prompt à la demande. Zero interroge les erreurs non résolues, applique des filtres d'occurrences et d'environnement, crée une issue par erreur qualifiée, joint la stack trace et les horodatages, et assigne un propriétaire du code.

Comment dédupliquer les erreurs entre Sentry et Axiom ?

Oui. Zero compare les signatures d'erreurs, les stack traces, les messages et la temporalité entre Sentry et Axiom, puis fusionne les événements correspondants en un seul enregistrement de triage. Chaque source sous-jacente reste liée pour l'investigation.

Comment réduire la fatigue liée aux alertes de la surveillance des erreurs ?

Limitez le triage à la production, définissez un seuil d'occurrences, dédupliquez la même erreur entre les outils et acheminez les erreurs à faible volume vers un résumé plutôt que de créer une issue. Cela permet de garder la file concentrée sur les erreurs qui nécessitent une action.

Zero peut-il lancer le triage des erreurs après chaque déploiement ?

Oui. Créez une automatisation qui démarre le workflow de triage des erreurs après un déploiement ou une fusion dans main, attend éventuellement une courte fenêtre d'observation, puis vérifie Sentry pour les nouvelles erreurs de production et crée les issues qualifiées.

De quels outils l'automatisation du triage des erreurs a-t-elle besoin ?

Sentry et GitHub sont requis : Sentry fournit les données d'erreurs et GitHub reçoit les issues assignées. Axiom est optionnel, mais il ajoute du contexte de logs et améliore la déduplication inter-sources.

Quelles permissions l'intégration Sentry-GitHub demande-t-elle ?

Sentry demande un accès en lecture aux issues et aux événements des projets que vous triez. GitHub demande un droit d'écriture sur les issues des dépôts qui doivent les recevoir. Axiom, si vous l'utilisez, demande un accès en requête aux datasets que vous désignez. Chaque connecteur s'autorise séparément dans Zero, et en révoquer un laisse les autres intacts.

Zero peut-il créer des issues dans plusieurs dépôts GitHub ?

Oui. Indiquez quel service ou projet correspond à quel dépôt et Zero achemine chaque issue en conséquence : les erreurs frontend vers votre dépôt web, les erreurs d'API vers celui du backend. Cette correspondance vit dans le prompt, vous pouvez donc la modifier sans reconfigurer le connecteur GitHub.

Zero modifie-t-il quelque chose dans Sentry ?

Non. Ici, l'intégration Sentry est en lecture seule : Zero interroge les issues et les événements et n'écrit rien en retour. Les statuts de vos issues, les affectations et l'historique des résolutions restent exactement comme votre équipe les a laissés. La seule chose que Zero crée, c'est l'issue GitHub.

Lancez votre premier triage Sentry

Connectez Sentry, GitHub et éventuellement Axiom. Utilisez le même prompt de triage quotidien pour voir le workflow en action sans le reconstruire à la main.

@Zero chaque jour de semaine à 8h45, récupère les erreurs non résolues de Sentry et Axiom pour les dernières 24 heures. Déduplique entre les sources. Pour tout ce qui compte 5 occurrences ou plus, ouvre une issue GitHub dans vm0-ai/vm0 avec la stack trace complète et assigne-la au propriétaire du code concerné.